Seems like we keep reinventing the wheel - the previous version of of HTML, XHTML (eXtensible HyperText Markup Language) is a direct subset of XML. Also, related - Mozilla Firefox used to have something called XUL (XML User Interface Language - https://en.wikipedia.org/wiki/XUL - using which you could build complete desktop web applications with the Firefox / Gecko web engine (something that is now popular with the Chromium Embedded Framework). (After Mozilla abandoned the XUL codebase, it has been forked and is now maintained as the Unified XUL Platform (UXP) implementation - https://forum.palemoon.org/viewtopic.php?f=46&t=30840 ).
I don’t think this is a reinvention of XHTML. It’s definitely closer in spirit to XUL, but seems different enough still that I wouldn’t call it reinvention.
What seems particularly novel about this is that it’s taken the compositional approach of modern UI component libraries, and distilled it down to units of composition that can express a lot of behavior and logic declaratively. At least at a glance, that’s an impressive feat. Not necessarily in terms its technical capabilities (though that seems impressive too), but in terms of how it simplifies modeling interactive and data-driven UI.
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 [email protected] 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.
I'm curious, not talking down: would you be interested in sharing your age and/or years of experience coding, and if you're feeling very generous, the languages youve written code in for more than 2+ years?
I'm 37, 17 years full-time-ish, VB6, ObjC, Java, Dart.
I'm asking, I guess, because I feel like I've seen these concepts before in pre-iOS ObjC, and Java, and IIRC a good chunk of the late 90s and early 00s was obsessed with doing this stuff in XML.
I barely remember, in my hobbled, probably incorrect, perception the ideas are old enough to that I am a bit flummoxed at how to interlocute with the idea that they're novel breakthroughs.
I'm ashamed to admit I thought the page was parodying this concept from back then of anything + XML = awesome. Im admitting it to give a concrete sense of how my subconscious processed this as settled territory.
In order: 42 years old; 17 years (at least? starting to lose count!); PHP -> JavaScript -> Clojure/ClojureScript -> TypeScript.
Perhaps more pertinent to the topic, in my last job I implemented the bulk of an XForms implementation. Pertinent because XForms has a lot of conceptual overlap with what I’ve seen in XMLUI so far.
I think it’s worth clarifying my point above with that context: it isn’t the concept that I find novel, at all. It’s the sheer depth and breadth of declarative expressiveness that I see in the examples. Maybe the best way I can put it is that what seems novel to me is how much novelty it appears to enable, before breaking through the abstraction to give it more capabilities.
What we've been seeing for a while is that the rate of wheel reinvention has skyrocketed. Just look at the PostgreSQL ecosystem and you'll see many libraries for each feature you might be interested in.
I am not sure about prior art but the ability to mix built-in and user-defined components, and fluidly refactor the mixture, feels very powerful to me.
I read this article originally as being a look back at some tech that somebody had made 20 years ago, that had a lot of interesting ideas, rather than someone suggesting yet another XML based UI mechanism.
I think it was a big missed opportunity. The frustrating thing about web UIs is that they don't obey my system-level display preferences (for stuff like fonts and colors). XUL was an approach that did that. Whether it's XML or something else is not the big issue, it's more a question of how to use a declarative style to specify a UI in a way that blends with the user's display preferences.
If memory serves, the system style stuff was a bolt on that Dave Hyatt did a bit later than the core work, and mostly for Windows.
The one theme for all platforms that was initially envisioned by Netscape kinda sucked ("Blue" for anyone that might remember.) And when Ben Goodger began his native-looking theme for Windows (pretty sure he started with preferences, maybe even before he got hired,) Dave got to work on Windows OS style queries and hooking OS style into XUL so the Mozilla suite's emerging new default theme could reflect those in its widgets. That work was ongoing even after most of the rest of XUL had been settled and I think Dave was still working on that even at Apple, right up until Mozilla decided Firefox would also ship on Mac and Linux and not just Windows* (as the several of us working on it has envisioned.) Once Firefox was running on Mac, Dave was precluded from continuing because of his Safari work. (He'd gotten permission to keep at when it was not directly competing with his Apple work.)
* Firefox was, for about its first year, meant to be Windows only. Ben Goodger had recently built a .Net wrapper for Gecko called Manticore, and there was Hyatt's Chimera for Mac, and Marco's Galeon for Linux, so the thinking was the major platforms would be covered with great standalone Gecko based browsers (no mail, HTML authoring, chat, etc.) But then Ben abandoned Manticore. Dave was convinced that XUL could actually kick ass on Windows (though also certain it could not on Mac) and so Ben started mozilla/browser to be the standalone Gecko browser for Windows. Ben also quickly abandoned that project and Blake Ross, an intern I'd recruited to Mozilla the year before, picked it up. He and I conspired on it with several others joining the effort during the end times at Netscape. Bryan Ryner stepped up to make it work on Linux, for example. [email protected], well 5 of us I think, were sitting at a picnic table outside of Netscape's Bldg 21 when we decided that after Netscape wound down, we'd transition from the Suite to standalone browser and email (then called Phoenix and Minotaur). Cross platform would thus become a requirement. We weren't going to drop Seamonkey without replacements for it on Mac, Windows, and Linux. It took a while to get the Mac version up and running and as soon as that happened, Hyatt had to bail. About a year later, we released Firefox 1.0.
XHTML was not a previous version of HTML; it was a failed successor.
HTML was originally conceived as a subset of SGML, but browsers tried to be as forgiving as possible of malformed markup and HTML-in-practice drove standards folks nuts. XHTML was intended to fix this by making a pure-XML representation of HTML, which would be unambiguous and fast to parse, but its very strict error handling made it extremely difficult to adopt. It turns out people would generally rather have a slightly wrong page than one that just said "XML Parsing Error".
WHATWG broke with W3C in 2005 to standardize HTML-in-practice into HTML5, giving up on XML compatibility and strict parsing.
I'm 90% certain that the origin of WHATWG was in late 2003 or early 2004 when Dave Hyatt (Ex-Mozilla, then with Apple) Ian Hickson (ex-Opera, ex-Mozilla, then at Google) Start Parmenter (ex-Mozilla, then at OSAF or Oracle, I think,) Brendan Eich (still with Mozilla,) and a couple other folks were at Mozilla's brand new closet of an office, talking about XHTML's shortcomings, advanced we'd made with XUL, and how the web could best move forward given the XHTML failure and challenges from new platforms. I was a fly on the wall for that conversation and then a fly in IRC for more conversations, but it has been ages and my memory's not what it was then, (and I'm too lazy to dig through 30 years of archived emails to verify) so take it with a grain of salt.
> It’s not failed: it’s the only language used in the ePub standard.
"XHTML" can refer to both a failed series of standards intended to replace HTML (XHTML 1.0, XHMTL 1.1, and XHMTL 2.0) and the XML syntax of HTML that is part of the HTML living standard, which itself resulted from the failure of the XHMTL series of standards. EPUB 3's "XHTML" is the latter, not the former.
I remember trying to write a cross-platform interface for some software in XUL, around 2003. I even bought two (physical!) books on the subject. It was totally impossible! The libraries were ever-changing and you needed the entire Mozilla CVS tree checked out to compile anything and just getting that to compile was endless complexity. I gave up and used an early port of Gtk to Windows.
Such a "could have been great" technology if it wasn't for Mozilla ...
One of the big reasons VB died, people will tell you, was the language. And that's true. But what they don't mention is that the other reason was the components. I'm not sure this is replicating a success story but rather failing to learn from what was not a success story.
I ran a very successful company (successful for a time) that sold Visual Basic developer tools via a printed mail-order catalog named VBxtras.
Two things killed Visual Basic:
1. The web. Visual Basic was first and foremost a Windows desktop app development tool, and their UI-first model of app development did not translate well to the web, or at least the attempts to translate to the web did not resonate.
2. Microsoft. Rather than continue the simplicity Visual Basic offered, Microsoft "improved" it by releasing VB.NET which abandoned the core simplicity that made Visual Basic so wildly popular among "Occupational Programmers," as Kathleen Dollard[1] and I lamented back in the day. The upshot was that former Visual Basic programmers fell into two (2) camps; they either:
A.) Abandoned VB for something else, or nothing at all, because they did not want to have to become a professional programmer, OR
B.) Switched to C# because if they were going to learn how to be a "real" programmer they might as learn C# and not C#'s disfavored sibling VB.NET.
BTW, the company that has developed XMLUI was one of our better vendors of VBX components for Visual Basic. They have since renamed to /n software, but at first they were named IP*Works (I think I stylized that name correctly per how they did at the time.)
I am not sure whether calling WPF a huge failure is justified. It works extremely well when everything is adaptable to its MVC-adjcent MVVM design pattern. In this case it's almost child's play to build rich and conplex GUIs that keep in sync with internal state.
Microsoft dropped the ball when they rewrote WPF in incompatible forms for the web (Silverlight) and Windows Phone (WinUI) shortly after releasing WPF itself. That ruined developer trust for their GUI library longevity.
The irony is that WPF itself never went away, and receives support and even occasional minor new features even to this day on .NET Core.
Much like WinForms, there are still many internal line-of-business apps written in it decades ago that are just happily chugging along, ignoring all the post-Silverlight churn in Microsoft dev story.
I really liked WPF for Windows Phone back then. The tooling was great.
I bought a massive 1000+ page book, "Pro WPF in C# 2010," one day. I also had to buy "Home Maintenance For Dummies" the same day. The bookstore cashier laughed at me.
I spent an unhealthy number of hours working in XUL in 2000-2001 working on the Komodo editor, which, bizarrely, used Firefox as its GUI platform. XUL was neat, but oh god so complicated. XML was the new hotness around the peak of the DotCOM era and Mozilla’s use of XML for a GUI framework fit the zeitgeist.
Firefox is still XUL. Some parts, like "content pages" for Settings and other bits, have been replaced with more modern web stuff, but the core of Firefox, and all of its primary UI has always been and continues to be XUL.
Don't forget XSLT. Worked directly in the browser. I only found out because the battle.net StarCraft page was made using it and I just happened to find it while poking around.
