And coldfusion shudder

It's funny because it reminds me of Angular in that it's very markdown heavy with the code behind in another file. So they wrapped React to make angular.

angular was dead on arrival - to me - because it seems nuts to bolt on full programming language constructs into html attributes. In the same way React easily won because it chose the exact opposite: put the UI constructs inside the full programming language.

Both have their worts, but I'm perpetually puzzled by how angular ever made sense as ergonomic. I suppose people like Vue so there's still some insistence on augmenting templates with programming constructs. Seems inevitable that templates will want more and more powerful constructs... and boom.

I think Angular "won" a lot of users because it confused a lot of people by calling its templates .html files that designers could work in them without needing to know how to program. Then once they were in those HTML files they were trapped by all the nonstandard attributes. It was a fascinating bait-and-switch to watch middle management get trapped in, I saw it play out a couple times in slightly different but ultimately the same way.

With React those sorts of "I'm only comfortable with HTML" (or "I'm only comfortable with Figma but it gives me HTML") designers often know that they don't like JS and don't want to work in JSX files directly. If middle managers are looking for "efficiency and synergy" the "my designers won't work directly in React" problem looks a lot like a "let's use Angular for everything because I'm told it is 'just' HTML" solution, with the trap being set that Angular's template language is complex and confusing and still a template language despite being in files labeled .html. Then once trapped the sunk cost fallacy strikes hard because "everyone already knows Angular" (despite no one actually "knowing" Angular, they know HTML and fight the template language to get something that sort of works some of the time).

At least Vue tends to prefer .vue for its single-file components. It's not directly the same bait-and-switch.

Adobe Flex was really nice. I shipped some good desktop apps with it, I recall it being a much better experience than Electron

Sadly you had to know the underlying structure of the components to work around the performance issues. Main pain point I had to work around was the fact that most containers where scrollable by default and brought a huge update cost. For a time my job was to convert components written by a visual developer in mxml into custom components written in AS3. I knew the runtime model pretty well and was able to layout complex components in code. These had the benefits of not being nested into multiple UIComponent containers/component layers which all hooked into the UI update loop. Ah good times :)

Also Mozilla did their app in real XML UI with XUL. But even they themself stopped using it after 20 years.

AFAIK Mozilla still uses XUL to draw their browser UI.

It's used for things like pop-up menus, (i.e. things that can't be done with HTML) and was recently used in some obscure parts of the UI e.g. certificate viewer (however I'm not even sure that's still XUL any more)

I think it's safer to say: It's almost all HTML these days. XUL is very much deprecated.

As we killed XBL, our XUL components because web components. https://briangrinstead.com/blog/firefox-webcomponents/

It’s a mixture of XUL and HTML nowadays. The reason is, most of the things that were only available in XUL are now possible in HTML, and it’s eaaier to find developers who know HTML.

> and it’s eaaier to find developers who know HTML

Rather: find developers who have a shallow knowledge of HTML.

I do claim that it takes much less time as a developer to get to a decent level of XUL knowledge than to get to a decent devel of HTML knowledge.

I agree, but also it’s the fact that there’s a steady supply of devs who already know decent HTML, while not many who know XUL. It would be easy to apply your HTML knowledge to XUL, but since we already support interleaving HTML and XUL, why not let people just use what they’re used to?

That said, I didn’t really look into it all that much! I just happen to know about it because I was doing some userChrome.css stuff back in the day.

Just came across this Firefox.html announcement in another thread and it might have some more context: https://web.archive.org/web/20230402033035/https://mail.mozi...

At my last job, when I first started there (this was circa around 2006), we actually used a Firefox browser plugin with a custom XUL interface to enable our writers to write content faster. It has a very complex UI, as complex as anything that could be found in the browser itself. Thousands of lines of XML and JS.

XUL was deeply unpleasant to use and maintain, and I do not miss it at all. We eventually ended up rewriting it as a standard webapp. It made the writers a bit slower, but they adapted eventually.

At my first job, our most senior developer and my mentor was huge on Flex and instant it was going to be the next big thing.

At the time I thought it was inflexible to style and felt very non-native.

To be fair, it had its moment, moreso in desktop applications than on the web. I seem to remember a lot of installers being developed in Flex. The iPhone showed up just in time to kill it before it ever got its footing on the web.

XAML is still very much a thing on Microsoft platforms, and contrary to your assertion, it still works very well. I would even go so far as to say that WPF (the original XAML-based framework) is still the best UI framework around if cross-platform is not a requirement.