[hantusk]

When reading through the comments here, I really feel like the article was misunderstood. My summary of the article is:

Point 1: React solved all the right things, but its current trajectory, does not prioritize developing the fundamental tooling we need. React does not allow us to build a new Figma (consistent undo/redo in collaborative settings, immediate low-latency mutation of app state to reflect user changes and building fundamentals to SaaS interoperability)

Point 2: People are overwhelmed by the work, and too timid to target the fundamental architecture we need to solve these things. We're just going with the flow.

He is leading https://usegpu.live/ to build the fundamentals right, an encourage people to either:

- help out there, if it fits your use case, or

- start working on targeting these fundamentals, where most needed for your own use cases, don't just go with the flow.

[makeitdouble]

On building the next Figma, my first reaction was that Figma should probably have been a compiled GUI application in a ideal world.

Figma is a work tool where a designers are supposed to spend a decent amount of time, and when working on a specific project there is little navigation or moving to other pages. It being in the browser is a technical artifact to help the business model, but inherently there would be nothing lost if it was a local application synching data and changes with a central server.

If time had to be spent making react closer to desktop apps, can’t that time be spent instead on making desktop apps as sandboxed, OS compatible, easy to download and execute as web pages ?

This is something Apple doesn’t care much about, but react core devs also don’t care about desktop likeness, so it seems a to me to be a suitable alternative solution.

[pas]

The big take away from software eating the world and everything is in the cloud now, is that making things that can scale down and up wins over specialists' specialized custom hyper optimized tools.

was Word 3.1 better than TeX or Quark Xpress or whatever? No, but it allowed people to do stuff quickly. To get things done. It was bad at scaling up, though.

Then online/cloud tools enlarged the pool even more. And finally it was possible to compete with the curse of the default, the shit forced on the world by OS vendors, corporate office suites.

Figma-like tools are the endpoint that can serve 99% of possible users. Both professionals and clueless casuals (and they don't even need to download and setup anything).

[jasonjmcghee]

It being in the web means I can work on any computer without having to install anything, embed a Figma in a doc or wiki, and it’s super easy to write plugins (html/css/js).

[makeitdouble]

The thing to me is...you are already dowloading the whole figma's client code base and running it in your browser. If it was a PWA it would even stay there.

Your point on installation is accurate in our current ecosystem, and I wonder how we could change that so "installing" isn't a hurdle. That's clearly not a simple problem to solve, but making the web "native" probably isn't either.

[zarzavat]

Installing is a backwards step compared to accessing a URL and loading a cached resource. It’s nostalgia. What you want is guaranteed “cache”. i.e. the resources are guaranteed to stick around and not get evicted randomly, but can still be evicted if the application is updated and that resource expires.

[makeitdouble]

I'm looking at mike_hearn's response in the thread, and it's going in a good direction I think (https://hydraulic.software), albeit platform owners would need to do a lot more to help that kind of approach to succeed.

Looking at the current situation from a high level view, we already have URLs for applications (you'll need to declare a unique identifier for your bundle), and Apple and Google are already toying with the idea of immediately executable apps with App Clips and Instant Apps, so it feels like we're actually pretty close from that alternate reality where "installing" can be seamless to the user.

(+ iOS also handles removing unused apps from the device, so that part should also be ok)

[mike_hearn]

"can’t that time be spent instead on making desktop apps as sandboxed, OS compatible, easy to download and execute as web pages"

It can! This is (sort of) the vision of my current company [1]. Its founding belief is that web tech is reaching end of life and it's time for our industry to start looking at what comes next. The long term goal is to create a new competitor to the web, but not all at once. Instead we're doing it via incremental iteration on current desktop development. Starting with better distribution tools we want to work up to sandboxed, streamed, cached, crawl-able, embeddable app/document hybrids just like the web has but with very different architectures that benefit from what we've learned from 30 years of the web.

The starting point is to make it as easy for people writing desktop software to distribute their work cross-platform as it is for people making static websites. The resulting UX is that of a normal desktop app as far as the user is concerned but from the developers perspective they just grab the tool we've made and run "conveyor make site". Out pops a set of files you can upload to any static HTTP server, which are fully signed, notarized and self updating for every desktop OS. It can do this because all the packaging and signing code is implemented by the tool itself, so there are no native dependencies and it can thus be very convenient to use.

For people who like the React model an interesting way to use this is to write an app using Jetpack Compose [2] for Desktop [3]. You get a fully functional/reactive UI toolkit but without needing a mishmash of HTML/CSS/JS - it's all just Kotlin. Your Android code can be shared directly with the desktop version (with layouts for larger screens of course), and you can then go ahead and start integrating with native OS capabilities as you see fit by directly invoking their APIs. For "mobile first" companies that develop a web version primarily for desktop users, this can eliminate the need to build a web app entirely (or you can use a minimal one for search engines). Next week we'll be releasing an update that improves support for Compose Desktop apps, in fact.

There's more work to do on making distribution trivial for everyone, and of course you can use Conveyor with Electron apps if you want to - the goal here is to be layered so the lower levels are usable by everyone including web developers, and the platform gets incrementally more opinionated as you go up the layers. Once the core product has matured further we'll be exploring an experimental architecture in which RDBMS' fully replace the web server, and what advantages you get from doing so.

[1] https://hydraulic.software/

[2] https://developer.android.com/jetpack/compose

[3] https://www.jetbrains.com/lp/compose-desktop/

[h0l0cube]

> React does not allow us to build a new Figma (consistent undo/redo in collaborative settings, immediate low-latency mutation of app state to reflect user changes and building fundamentals to SaaS interoperability)

If I wanted to write the next Figma, the first thing I’d reach for is Phoenix Liveview + Channels with Vaxine/AntidoteDB or some other eventually consistent CRDT store for collaborative editing and host it on fly.io - I’d forgo the ‘front end’ completely

[ch_sm]

> I’d forgo the ‘front end’ completely

Not to dismiss your argument/stack preference, but forgoing the front end for a graphic design tool might prove difficult. EDIT: But yes, CRDT-backed stores are definitely the way to go for a requirement like this.

[h0l0cube]

> but forgoing the front end for a graphic design tool might prove difficult

How so?

Offline support? Collaborative tools don't really have a good offline story by nature.

Ping times? If you use fly.io you're going to have great availability and low latency. It's like a CDN for live apps.

I'm not biased against a 'client-side front end', it's just that a collaborative tool that is 'always online' might as well use a 'live app' style where the server drives the DOM. It solves all the problems that the OP raised in the quote, and it's less about where React should go next, because client-side front end literally can't solve those problems due to their nature.

[adigau31]

> React does not allow us to build a new Figma Did you take a look at Liveblocks? They have an example of an advanced whiteboarding experience: https://liveblocks.io/examples/collaborative-whiteboard-adva... And they recently released a set of APIs so thast you can build a Figma-like dashboard to seewho's in which board and set permissions: https://liveblocks.io/docs/guides/managing-rooms-users-permi...