Hacker News Reader

Comment by pgt | Hacker News Reader

Any discussion about incremental UI should include Yaron Minsky's talk about Jane Street's OCaml framework, incr_dom from 2016: https://www.youtube.com/watch?v=R3xX37RGJKE

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

View on HN

Don't forget Windows 1.0 in that list:

https://www.bitquabit.com/post/the-more-things-change/

interesting insight! Do you by chance know what's the current model used by windows right now with WPF or UWP or whatever they call it today ?

Modern UI frameworks mostly try to offload the rendering to the gpu where just every pixel is rendered for every frame into texture buffers.

But of course that can be combined with diff&patch as well...

Yes I am especially curious to know how they manage state in desktop GUIs - if it's events and callback based or some other kind of functional architecture

In what concerns WPF, UWP (you can do this with forms as well although support is more primitive), via data bindings.

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.

It's usually event callbacks for actions, although these are often wrapped in a first-class "action" or "command" abstractions, to allow routing different events to the same handler - e.g. both the menu item and the toolbar button.

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.

> 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_...

Not every pixel! Mozilla posted recently about how they have gone to great lengths to not redraw every pixel every frame because it saves battery. Apparently Chrome and Safari already do that.

Win32 is still alive and kicking, so any desktop Windows app has at least one "traditional" window (HWND) - that being the top-level one - and it still runs a WndProc, that periodically receives WM_PAINT, telling it which chunks to redraw. There's a compositor sitting above all that, so the complexities of the model are largely redundant, because it no longer needs to handle partial refreshes - it doesn't render directly to the screen.

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.

To be fair, this is also the rendering model of Swing and the Amiga.

Pretty much all windowing toolkits (X11 included) worked that way prior to the mid-90s because while there was at least enough RAM for a framebuffer (unlike say the Atari 2600), it would have been wasteful to have a backing-store for every window.

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.

Windows was still doing it that way into 00s in XP and 2003, and you could observe it when apps would get a hang in their windows loop, and couldn't process WM_PAINT anymore - you'd get ghosting artifacts moving other windows over the one hanging, because it wouldn't repaint the invalidated areas. It wasn't until Vista that such windows would be rendered using the ghosted version of the last known good state (cached by the compositor).

> Two sleeper startups in this space that are going to make a lot of money ...

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.

You are right about developer tools, but these companies are not selling developer tools. Plus, the technical implementations are non-trivial.

It seems like Materialize has some interesting approaches in mind:

https://www.youtube.com/watch?v=zWSdkGq1XWk

> but these companies are not selling developer tools

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.

Firebase is a hosted database. Where does a dev tool begin and end? Is Slack a dev tool? Is HN? Where do you draw the line?

I've thought this since Borland fell apart. The ship sailed a long time ago. Unless you're a unicorn like Slack with cross organization appeal you have no chance!

JetBrains, OutSystems, Embarcadero (nee Borland),....

It is a matter of getting a target audience willing to pay for their tools.

JetBrains in particular has done a great job, and the Community Edition of Idea provides a ton of value for free.

What's the relationship between React and Vue? I've tried searching for it, but all I could get was code samples comparing the two.

They're both libraries for building user interfaces. They're related because they both solve the same problems. They also share a lot of core ideas (one way data flow, reusable components, declarative UIs, etc). I'm pretty sure React came first and heavily influenced Vue. They aren't commonly used together because most projects only need a single UI library.

Thanks, but the parent seemed to imply one was a commercial offering and copied by the other as an open source project. That's the part I was looking to get clarification on.

No, they've both always been 100% open source (ignoring the complaints about React's previous BSD+PATENTS license). React is built by Facebook, while Vue is primarily built by Evan You (+ a team of core contributors).

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.

> Selling developer tools these days is just a losing game.

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

Could be true, but personally I steer clear of these so-called "ecosystems" because of the lock-in effect, and especially if they are monetized using a SaaS scheme. For me, such tools are (in a way) broken by design, and therefore I wouldn't want to sell such tools myself.

> 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.

But that's a very indirect and uncertain way of making money. I think that people who do honest work deserve a better way of getting paid.

Also oftentimes not all that lucrative for the founders. The reason Big Tech will aquihire for a million or two per employee is because it costs that much to get a good employee. When companies have managed to assemble such a team and build a product to showcase it it's usually because they took a lot of capital before they had a product, which means that VCs own the lion's share of the company.

Which is why I totally dislike the FOSS culture of wanting to be paid for their work, while unwilling to pay for the tooling.

Git PR don't pay supermarket bills.

To developers on the street, kind of.

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.

There's also Aardworx[0], who are doing something similar with F#. Their extracted incremental computation library is here[1], and the platform overall is here[2]. There's also a bunch of cool talks on YouTube[3].

[0] https://aardworx.com/index.en.html

[1] https://github.com/fsprojects/FSharp.Data.Adaptive/

[2] https://github.com/aardvark-platform/aardvark.base

[3] https://www.youtube.com/watch?v=mZ3o6TqNR6U

And here's some other interesting related content:

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

Heartily agreed re: Materialize, and I've also been nerd-sniped by Adapton, although less literally than incr_dom.

Whatever you do, do not read the META II paper, especially not Figure 5, which is the META II compiler written in itself. You may lose two months of your life: http://www.ibm-1401.info/Meta-II-schorre.pdf :)

Those are some big words when it's literally a more obtuse, less production ready variant of what WPF has been doing forever (and WPF wasn't the first on desktop UX to do it!).

I mean, here is Qt shipping Qml interfaces in a ton of cars, and you're talking up rust2html.

Also maybe the Purescript experiments in incremental updates?

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)

I might be remembering wrong, but I think Jane Street's incremental is based on self adjusting computation by acar vs adapton by hammer?

Yeah it’s not inspired by adapton. Plus, they work differently. Their data flow in opposite directions.

Good to know! I was incorrect to take GPs claim at face value, perhaps.

(BTW I’m not sure if you remember our conversation at React EU in 2017, really enjoyed chatting!)

> 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.

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, git actually stores diffs when its reasonable to do so. You can check the files for the objects in the repository yourself. Git can compress these files into packs, but that's a separate step on top.

> No, git actually stores diffs when its reasonable to do so.

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).

https://gist.github.com/matthewmccullough/2695758

https://git-scm.com/book/en/v2/Git-Internals-Packfiles

Merging requires diffing, and hashing enables efficient diffing. It's a reconciliation process just like checking balances in accounting, and you could think of version control as accounting for code.

The predecessor of all these diff and patch systems/UIs is the ancient character terminal based curses library. [1]

[1] https://en.m.wikipedia.org/wiki/Curses_(programming_library)

Reply on news.ycombinator.com