Speaking of expressing a UI declaratively, and composition with web components... as a former Qt/QML dev, I always felt like Web innovations of the last decade are just rehashes of the inspirations and ideas behind what Qt's QML started offering already since 2010.
Things like CSS Grid, which was a great and celebrated new toy in 2017, but as foreigner from the Web world, I still remember how I read those news and didn't know if they were kidding.
To the standards body that may concern: just copy QML and standardize it already! :-)
Ivan Sutherland's Sketchpad (aka Robot Draftsman) was created in 1963, and inspired the Visual Geometry Project in the mid 1980's and The Geometer's Sketchpad in 1995
Laszlo... I remember this one, dipped my toes in it, like many, many other GUI tools. I've been using the same backend framework for 20 years with no need to change but I can't decide which frontend GUI library I should invest my time for the future. It all looks like constant rehashing of the same ideas but with limited lifespan.
XUL applications outside of Mozilla existed well before XULRunner (itself barely a product.) Of course Mozilla was the main client at XUL's birth in 1999, but when I joined staff@mozilla.org 25 years ago I worked with OEOne, an ISV delivering a full Linux front-end using XUL. That was late 2000, maybe early 2001. A year or so before them, our parent company, AOL, began working with OEMs on XUL-based thin clients and AOL even re-built Prodigy (the low tier trial run for the AOL main client) with Gecko and XUL in 2001-2002. And of course, Mozilla itself shipped on a nearly a dozen platforms in 2002, and entirely XUL.
XUL was born in 1998 and the spec was finalized in 2001.
I worked on the cross platform TomTom Home content management app in 2007-2008, which used XULRunner and XP/COM extensively.
But XULRunner only really existed to serve Mozilla's Firefox web browser, and anyone using it for their own applications, like TomTom Home or Songbird, was on their own without any support.
Mozilla didn't take our XULRunner PRs seriously, or put much more than promises and lip service into XULRunner supporting other applications than Firefox.
If Mozilla was actually serious about supporting XULRunner for anything but Firefox, then it might have taken the place of Electron a lot earlier that Electron's release in 2013. That was a huge missed opportunity and tragedy of broken promises and wasted effort.
>I first looked at Red Swoosh and its Firefox extension, FoxTorrent. It would have been ideal, since we using the xulrunner platform for TomTom Home, but Akamai acquired Red Swoosh, and it vanished without a trace. [...]
>One way to get Akamai to unilaterally lower their bandwidth prices is to threaten to use BitTorrent instead. [...]
>TomTom had an "iTunes-like" desktop content management and device control desktop app called TomTom Home, which was implemented in xulrunner (the underlying framework of Firefox and Thunderbird, kind of a predecessor to Electron for writing cross platform desktop apps in JavaScript with C++ XP/COM plugins).
>The first thing I tried was to make an XP/COM plugin out of the LibTorrent library. That worked ok, but the idea of increasing the size and complexity of what was already essentially a web browser with a whole bunch more complex code that does lots of memory allocation and networking all the time, didn't seem like a good design. This was long before Firefox supported multiple processes, so the same app handing bittorrent would bloat the app and degrade the user interface responsiveness.
>However RedSwoosh, FoxTorrent and BitTorrent DNA all ran in separate processes that just handled all the BitTorrent stuff, and that you could talk to via https (to stream the file with a special url, and retrieve progress telemetry on another url). And it's incredibly easy to integrate xulrunner or any web browser with those servers via http, so no C++ XP/COM plugin required.
>Another issue is that you don't want every application to have its own BitTorrent client built in, or you will trash the network and disk, since otherwise they would compete for resources. It needs to be a centralized a system service, shared by any app that needs it.
>BitTorrent DNA worked nicely that way. And it could fall back to the CDN to download at full speed if there weren't enough seeders.
Also unfortunately, XULRunner was in no shape to run on mobile or embedded devices, so we ended up running WebKit on the TomTom embedded Linux devices, instead of trying to shoehorn Mozilla into small mobile devices.
>Both Chrome and Safari were based on WebKit (which itself started as a fork of KDE's KHTML and KJS libraries), which a lot of other vendors use too.
>Although Chrome eventually diverged years later with the development of Blink, Chrome was the result of a multi-company, industry-wide unification strategy on WebKit, the core of Safari. [...]
>Mozilla was in no shape to run on mobile or embedded devices (and still isn't afaik), while WebKit ran quite nicely on mobile and embedded devices, thank you.
And as we all know, Android is as important to Google as iOS is to Apple.
>So there was really no chance of either of them (or any other of the many companies interested in mobile and embedded devices, like TomTom for example) ever building on top of Mozilla/xulrunner.
QML copies many core ideas from JavaFX (released 2008) and Microsoft's WPF (released 2006).
Microsoft's XAML for declarative UIs is the most reused/reimplemted approach among this bunch. Its variants are in WPF, Silverlight, WinUI, Avalon and Uno.
Things like CSS Grid, which was a great and celebrated new toy in 2017, but as foreigner from the Web world, I still remember how I read those news and didn't know if they were kidding.
To the standards body that may concern: just copy QML and standardize it already! :-)