> ... for small gains in developer productivity

I think this is an underestimation, to be honest. What I struggled with native code to be able to do when I was younger is now stuff that literally anyone can do using any number of off the shelf libraries and tools targeting web browsers. This is an amazing achievement and not a bad thing in and of itself; if anything, what I lament the most is that the browser is killing native apps by being a "better" overall option.

Most software companies nowadays take it for granted that they need to ship some kind of web access to their network service, so that's the first thing they work on. Next they probably want to support iPhone and Windows, and probably Android, macOS, maybe even Linux... There are some options that cover each of these platforms to some degree, but by this point they probably already have at least a proof of concept in a web browser, and with a single NPM install, they can have that show up in a separate window, ready to ship with an installer and deployment system (not a great one mind you, but still.)

This wouldn't be as much of a problem if there were good, production-quality, efficient native code GUI frameworks that could efficiently target the DOM and native UIs across Windows, macOS, Android and iPhone, have first-class support for native text input with IME and platform-native semantics as well as accessibility support with screen reader integration, deal with responsive UI changes when dealing with different scree sizes, and have robust but performant DPI-independent visuals that handle fractional scale correctly. (Easy stuff, right?)

But there's not. And although I love Delphi VCL, or even just raw Win32, it's just not most of that either. Supporting all of these platforms is very hard. Browsers do a very good job and are often some of the best sources of example code for writing deep platform-specific code you can find. And best of all, since you're targeting web anyway most of the time, and browser engines are "native code", it's a hell of a lot easier to just ship the browser or at least JS engine to platforms that already run native code than it is to try to create an isomorphic native code solution that can also run in a browser environment.

I think that things will get better, eventually. But, they'll probably get worse before they get better.

Can you elaborate on "arguably much more productive"?

Let me give a more recent example.

A few years back I was building a B2B website for companies to manage event listings[1], fully modern React stack.

I wanted to get the backend API up and running first so I threw together a prototype in WinForms and C#. I had been writing React all day every day for a couple years at that point, and I hadn't used C# or WinForms for quite a few years (3 or 4 at least).

Also none of the GCP APIs I was using had official C# WinForms libraries (hah!) but of course everything had nice React integrations.

So anyway, within a day and a half or so I have a C# desktop app up and running that has about 80% of the site's planned functionality implemented. It is ugly, but it works.

Over 3 months later I have the React site up and running.

The React site supported Mobile and Desktop browsers, and it looked nicer, but the productivity to create the React site was literal orders of magnitude less.

FWIW I had a similar experience going from React to Svelte, I got done in 3 days what would have taken me weeks in React.

(For those paying attention, Svelte was still slower than C#!)

Part of the difference is that we expect web apps to be all shiny and work at any screen size with fancy CSS, vs a desktop app which can just do its thing.

The other part is that, IMHO, HTML+CSS are crap for laying out application UIs. Better than what they used to be, but still absurdly complicated.

[1] Create their business profile, list and manage events on a timeline/calendar, view attendees, send announcements to attendees, real time view of people as they show up to the event by hooking into Geo-locating on the phone, manage photos, and so on and so forth.

> The other part is that, IMHO, HTML+CSS are crap for laying out application UIs. Better than what they used to be, but still absurdly complicated.

Not just absurdly complicated, but also absurdly inconsistent. If you write an app in JS+HTML+CSS and use Electron to deploy it, the UI could literally be anything, as can the controls, etc. Nothing matches the OS UI neither, and standards have gone out of the window :(

> If you write an app in JS+HTML+CSS and use Electron to deploy it, the UI could literally be anything, as can the controls, etc. Nothing matches the OS UI neither

This may be seen by some people as an advantage though. For example my work computer is a Mac and my personal laptop runs Windows & Linux and I specifically like when application's UX is consistent across the different operating systems...

Very true. In some cases, it can be a force for good; a force for innovation.

What's wrong with the OS styled inputs?

Productivity has to incorporate some notion of deployment. As was standard for that era, Delphi/VB ignored this question completely. Time to deploy your app? If you made a simple zip utility, no problem, copy a single EXE onto a network mount somewhere inside your firewalled LAN. Windows has a pseudo-filesystem embedded into the binary which just about services for loading icons and strings, that'll do. Something more complicated, with DLLs and registry entries perhaps? Buy a copy of InstallShield for hundreds of dollars and learn InstallScript. Not only was there nothing in between until MSI and WiX came along but right up until the mid 1990s Microsoft saw the internet as this exotic fad, and using networks for software distribution was considered unworkable due to low bandwidth. Software was for CD-ROMs and shipping meant physically putting it on a ship.

Problem is, iteration speed mattered more to people than almost anything else including raw productivity. The world changed faster than Delphi did. Borland could have recognized the trend of hacking browsers into making apps was representing some fundamentally unarticulated need and come up with e.g. an Object Pascal interpreter. They could have done some sort of "Delphi Browser", for instance, and it would have gained adoption, but their codebase was fundamentally oriented around producing native Windows apps so it would have been difficult to make that move. Plus, Borland were basically guests on the Windows platform and tended to follow Microsoft's lead. Microsoft were pushing ActiveX as the way to bridge the web and the Windows world; Borland realized too late that ActiveX wasn't going to meet people's needs. They saw the web first as not a competitor, and then later as a mere carrier for Delphi apps, and then later still pushed using Delphi for writing web servers but its strengths didn't apply there.

So the lessons I took away from this were really about unarticulated preferences that you have to learn about by watching what people do, not what they say, and also the overwhelming importance of deployment - still a blind spot for most web competitors today. Up until last year if you wanted to use a Delphi-like platform with web-like deployment where apps are always refreshed on launch there just wasn't much out there. Even Electron only offers fully asynchronous desktop-style updates. I have a little company that makes products for fixing deployment of desktop apps (within the constraints of the native platforms), which adds a web-like deployment mode called aggressive updates (https://hydraulic.dev/). With that an update check is done on every launch, so you can iterate very fast as long as your users restart the app from the time to time or of course you can force it when the time is right, no different to requiring users to close and reload tabs for a SPA.

Anyway, I disagree that the main thing they lacked was mobile + DPI. Delphi, VB, GTK, Cocoa etc had lost the desktop before smartphones mattered at all because they lacked a good deployment and update system, and the ability to push out fixes and changes instantly mattered more than all the other features combined.

> and the ability to push out fixes and changes instantly mattered more than all the other features combined.

It mattered for developers. Users couldn’t care less.

While I do agree that back in the day, we missed standardized update systems, we do have them now (Flatpack, Winget, the stores …) and they could have appeared sooner if the industry did not plunge entirely in this web thing.

Sure the old days were not perfect but we are now in such an extreme opposite that your computer doesn’t even compute anything except a browser engine.

I agree that it's gone from one extreme to the other and this isn't really healthy, hence our work on Conveyor, trying to find a nice middle ground for non-web apps.

I think users do appreciate fast iteration. If they report a bug in the morning and it's fixed by the afternoon, that feels very different to reporting a bug and being told it'll get fixed in the next version which ships in 2 months. Even very basic and subtle differences between web and non-web apps matter here, for example, the lack of version numbers, the precise control over caching policy, the refresh button all make big differences to the overall feel of things.