Are they? Most 'web apps' I use have a preferable browser size; if you use them at a smaller size they still work (they are responsive) but are just unusable for anything sane. So superior... I made those layouts with Delphi too early 90s and the same consistent behavior was true then as it is now; 99% (to not get 'source?' questions; I have been writing consumer software for almost 30 years and in my experience + the experience of peers I talk to) of consumer users of software click on maximize the first instance they open anything; browser or non browser. So sure, I use tiling window managers and like different windows, but most people don't, hence the success of tablets; they are simple because 1 app, maximized at a time. And those apps sure are responsive but they don't need to be; they look the same on all tablets for the resolution they were designed to be used at. Just simply scaling them would've worked fine for most people and usecases. You would have to write things twice; one for small screens (phones) and one for big screens (desktops) but that's not really that uncommon now either.

Delphi was better in that regard, because you could anchor sides and corners of widgets to their containers. In many cases, it was sufficient to allow for a resizable layout.

But it doesn't solve the problem with high DPI, changing fonts, and localized strings being sometimes significantly longer, requiring widgets to be resized to accommodate them.

Agreed. And yes, that needs some attention, but most people doing responsive web do not account for most of that either. What does changing fonts mean? You design something for a font and then change it afterwards or?

When I click on some languages (I am not native English and my native language, Dutch, is not very high on the list of priorities for most companies) in some of the biggest companies in the world, you notice it just wasn't designed for that. From just making it wrap and enlarge to break the design to simple sticking outside the box.

For some localizations (Chinese for one) you will have to redesign anyway because 'our' (not sure how to describe) designs simply do not work/sell over there.

Most global companies have a local presence doing their local sites; I know some, even inside the EU, very big companies that have a site per country and have the html/css look 'the same-ish' for the user but completely different when you check the source to accomodate for local taste / language.

I like the dream of this working, as I am a programmer, but I don't see it in real life and I find html/css just painful to work with; not difficult but painful compared to most desktop GUI tech. Flexbox etc is changing that a bit but still it looks like people are shoehorning everything in this html5 stuff just because they desperately not want to use/learn other things instead of using the best tool for the job.

Disclaimer: I am old and have seen this before. I do create webapps and use React (new license makes it workable outside hobby projects), but I will gripe about it like the author of the blog post.

> And yes, that needs some attention, but most people doing responsive web do not account for most of that either. What does changing fonts mean? You design something for a font and then change it afterwards or?

Think about user changing the default UI font. OS X and Windows both make it difficult to impossible, and for this exact reason. On Linux, though, it's common and expected (which is probably why all UI frameworks that target it do have some decent dynamic layout support).

But aside from font family, there's also the issue of font size. That one can be cranked up on high-DPI displays, or for accessibility purposes.

> I find html/css just painful to work with

Don't get me wrong, I'm certainly not praising HTML5 and CSS here. They're vastly overcomplicated for what they do, for app development. And layouts are a long solved problem in desktop UI frameworks - Qt, Tk, Swing, WPF are just a few examples. WPF in particular is a good example of an XML-based markup language specifically for UI, and it's light years ahead of HTML5 in terms of how easy it is to achieve common things, and how flexible things are overall.

If even half the time and energy invested into building "web apps" (including all the Electron-based stuff) went into an existing UI framework - let's say Qt and QML - we'd all be much better off; developers with far more convenient tools, and users with apps that look and feel native, work fast, and with smaller download sizes (because you aren't effectively shipping the whole damn browser with them).

> WPF in particular is a good example of an XML-based markup language specifically for UI, and it's light years ahead of HTML5 in terms of how easy it is to achieve common things, and how flexible things are overall.

This is why I had big hopes in XHTML and the XML components, but then we got HTML5 instead, yet another pile of hacks.

I used to write Petzold-style Win32 apps. I've also written native Cocoa apps as recently as last month, and I've used Qt and GTK+. Having experience with all of these, my preference is still for Web apps, because of the ease of portability and the fact that TypeScript beats C++ for ergonomics, safety, and ecosystem (just having a package manager is huge, even if NPM leaves something to be desired).

I find it fun to write Cocoa apps too, and I do on occasion for throwaway stuff that only I am going to use. But too many people (including me, at home!) simply don't use Macs. When I have to write a portable app, the choices basically come down to GTK+ (doesn't look native anywhere but GNOME on Linux), Qt (requires C++ plus moc and doesn't always look native either, for example on GNOME), or writing everything from scratch for every platform. While the last choice may be the "right" one from a purist's point of view, the extreme amount of work necessary to make duplicate Windows/Mac/Linux (often plus Android and iOS) versions makes it all but out of reach for anyone but big companies.

When I started coding for Win16, my first option was Turbo Pascal with OWL, eventually I started to use Turbo C++ with OWL.

With the switch to Win32, the tools became VB, Delphi, Smalltalk and Visual C++ with MFC.

Like every Windows developer I also own the Petzold book, bought for Window 3.0 development, and other good one from Sybex, probalby the one book that ever explained how to properly use STRICT and Message Crackers introduced with WIndows 3.1 SDK.

However I might have written about five applications in pure Win32 API instead of using one of the former language/frameworks, as requirement for university projects.

In general, I think many developers only have the bare bones native experience without making use of proper RAD tooling, or the UNIX way, which has always been pretty bad in tooling for native GUIs versus Mac and Windows or even OS/2.

Qt also isn't very good for accessibility. https://blind.guru/qta11y.html

When the VB/MFC layout was replaced it was with WPF. WPF is declarative, flexible, handles high resolutions well etc.

It's what I imagine a reasonable HTML/CSS would look like.