[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/