Don't forget Windows 1.0 in that list:
X11 added the ability to have a backing-store for each window, and the compositor would render them to the display, and Wayland is compositor only.
On another topic, the constraint based GUI systems going back at least to the 80s are similar to react et al., though usually the widget graph was fixed, and only the properties of the widgets were reactive.
Most modern GUI frameworks don't use the tree-of-HWNDs anymore, though. Which is to say, the entire visual element tree is handled internally by the framework's own compositor, and the top-level WM_PAINT just renders the resulting bitmap. WPF and Qt do it that way. That said, there's still no shortage of apps that are implemented in terms of native Win32 widgets - pretty much all the non-UWP apps that come with Windows are like that. So when you are looking at, say, Notepad or Explorer, they still fundamentally work the way the article linked to above describes.
But of course that can be combined with diff&patch as well...
Which they are, through extensions such as https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_...
For views, you either get some form of MVP, with explicitly implemented model interfaces that provide the glue between the views and the object tree they are representing, or data binding that effectively creates that same glue for you. Here's an example from UWP:
https://docs.microsoft.com/en-us/windows/uwp/data-binding/da...
So no, it's not really functional. Quite the opposite - the state is global and mutable, and UX actions that purport change things really change them. That also makes it all very intuitive, though.
The concept is somehow complex to master, I compare it to getting monads to click, but when you understand it, you are able to envision how to build the full UI architecture as having a Lego box at your disposal.
For everything, views, stylesheets, event handlers, data models.
How are they going to make money if open source enthusiasts copy the ideas and spread them for free? See e.g. React -> Vue.
Selling developer tools these days is just a losing game.
Selling a company that holds some patents or serious implementations of useful software is not. We live in an era where Big Tech will acquire companies for tens of millions, then dismantle their product, just to hire a proven engineering team (or keep them out of the hands of competitors for a brief period). So companies with actual, useful products do fetch quite a bit.
Git PR don't pay supermarket bills.
It is a matter of getting a target audience willing to pay for their tools.
I agree this is true for _trivial_ dev tools, but for dev tools that are more complex or provide an entire ecosystem I think this is not strictly true. Where I work (Sourcegraph) we are able to sell a good cohesive bundle of dev tools (code search, jump-to-definition/find-references, etc.) and through that have been able to easily fund REALLY cool tooling like https://comby.dev
I imagine the same is true for e.g. GitLab
The "copying" comments are largely due to things like Vue's new proposed hooks API being very much inspired by React coming up with hooks in the first place.
Hence why everyone that want to make a living selling developer tools, turns to enterprise customers, B2B, or finds a way to package them as SaaS.
Welll ... from their website:
> Red Planet Labs is pioneering a radically new kind of software tool.
Also, the Materialize "reactive SQL" solution sounds a lot like Firebase.
[0] https://aardworx.com/index.en.html
[1] https://github.com/fsprojects/FSharp.Data.Adaptive/
1. Deriving a Domain Specific Language for purely functional 3D Graphics - https://rawgit.com/wiki/aardvark-platform/aardvark.docs/docs...
2. Fable.Elmish.Adaptive (another instance of applying incremental computation to the Elm model) - https://github.com/krauthaufen/Fable.Elmish.Adaptive
I mean, here is Qt shipping Qml interfaces in a ton of cars, and you're talking up rust2html.
Original idea: https://github.com/paf31/purescript-incremental-functions
More recent Proof of Concept: https://github.com/jlavelle/purescript-snap
(I just posted the latter to HN here: https://news.ycombinator.com/item?id=21690382)
(BTW I’m not sure if you remember our conversation at React EU in 2017, really enjoyed chatting!)
I thought git (as opposed to, say, RCS) did _not_ do the diff thing, and each object is just the full thing, relying on gzip to do the compression?
No it doesn't. It does delta compression – which ultimately accomplishes the same goal – but this is not what people mean when they say that a version control system stores diffs (like SVN does).
[1] https://en.m.wikipedia.org/wiki/Curses_(programming_library)
Incremental is essentially an implementation of Adapton from 2014: https://www.cs.umd.edu/~hammer/adapton/
There is a big upset coming in the UX world as we converge toward a generalized implementation of the "diff & patch" pattern which underlies Git, React, compiler optimization, scene rendering, and query optimization.
Two sleeper startups in this space that are going to make a lot of money are Frank McSherry's Materialize Inc. and Nathan Marz's Red Planet Labs.
incr_dom source: https://github.com/janestreet/incr_dom
Differential Dataflow: https://github.com/TimelyDataflow/differential-dataflow
Declarative Dataflow Client: https://github.com/sixthnormal/clj-3df
Crux adapter for Declarative Dataflow: https://github.com/sixthnormal/clj-3df