Architecture of a desktop-like SPA
blog.uidrafter.com
blog.uidrafter.com
Could you run Photoshop or Blender in a browser? I mean, yeah, sure (especially now with Wasm), but why would you?
I have an app with a full Windows/OSX like GUI and presents full file system controls in the browser like Explorer or Finder. This app also saves state on each interaction and allows state sharing across different browsers in real time of the same device. The fastest I have gotten this to load with full state restoration and content rendering and page paint is 0.32 seconds as measured using the Firefox performance tab from the developer tools. The largest part of that load time is rendering a 3mb background image.
People really want to believe JavaScript is slow. I have been writing JavaScript long enough to reason this down to two major concerns:
1. Developers do really ridiculously slow things in JavaScript either for convenience or insecurity and more than half the time will fight you to the death to qualify bad practices.
2. Developers are too reliant upon dependencies. It’s like going camping but taking everything plus the kitchen sink with you. Remember that scene at the beginning of Saving Private Ryan when Private Upham wants to bring his typewriter on an infantry mission deep into the front lines?
Not exactly something users want.
Not quite.
Users want to get bugfixes and the latest and greatest without being bothered by updates and upgrades and popups and progress bars. Even with automated processes, app update fatigue is a problem.
If your use pattern already involves reloading/redeploying the app at start, that fatigue goes away.
What users do not want is losing features they care about, or see breaking changes in their workflow.
The question we should be asking is: why would anyone want a traditional desktop app? Why are we investing in traditional apps? Who in the next few generations is going to even be familiar with much less want to use desktop apps!?
...after being exposed to a constant barrage of web marketing hype and related propaganda from those who stand to profit the most from it.
There's plenty of anti-Electron sentiment here too, and if you've ever used one and an equivalent native app, you'd certainly experience the astonishing difference in efficiency and functionality.
But from the customer point of view, instant installation, transparently receiving all upgrades, zero work for your IT department in a business environment, and running in a sandboxed runtime that's already on your machine is a massive massive win.
> and if you've ever used one and an equivalent native app
Of course, I've built an Electron app and a native app as well. And, of course, the native app ran faster. But the electron app took 3 weeks to build and the native app took nearly a year. Both apps are now defunct, but if I had to pick one to keep supporting it would most definitely be the Electron one because that had the preferable simplicity in codebase and toolchain.
I will add that Notion is so incredibly slow to load that it convinced me to pursue native options only, but my non-technical girlfriend and her friends use it every day for planning and have no complaints about it. Would a native version be faster? Duh, but would the Notion team have been able to get their work out to the world this quick if they had pursed native over web? Highly unlikely.
Now you'd say, well Notion's lead is just temporary until a native app matches the feature set and loads instantly. And indeed, Notion would lose out until the next wave of features come and suddenly the native app is struggling to support 3 different OSs while the Notion app continues to innovate at the cost of speed. Developer velocity is a critical metric that we, as developers, seem to discount heavily for some reason, probably because we all suck at estimating the time things take us.
I went through this same cat and mouse game with Sublime Text and VSCode. Sublime was great, but VSC kept getting better and better, with performance improvements along the way, to the point where it didn't make sense to use Sublime Text anymore. I should add that, as a web developer, making VSCode plugins (which is just JS + HTML + CSS) seems like a far more approachable task than doing anything substantial with Sublime's plugin framework. That isn't just important to me, that also means other plugin developers can jump in head first to improve the ecosystem.
> efficiency
Efficiency in what? RAM usage? CPU cycles? If I'm using an application for work I'm going to be using it on a machine with the specs to match the workload. Nobody can seriously claim to be doing professional work on a computer with 2GB of RAM in 2021. So who is this inefficient for? Maybe it sucks for personal computing, if you can't afford to buy a better computer, but that's not the market these applications are targeting; obviously you want to target professionals if you want them to buy into your monthly subscriptions.
One of the biggest Electron apps, Discord, is actually in a very clever position due to its target market of gamers, as those are the people who are most likely to have top-end PCs with high end graphics cards. Rendering Chrome and its three billion helper processes is a probably a breeze on those monsters, but even on my middle ground MBP, it doesn't have any noticeable impact on my workflow. Whatever inefficiency it has is more than justified by the value I gain from using it. And that's really the trade: it may be inefficient, but it has features, which is much better than an efficient native program that doesn't have the features my friends are using.
I used to prefer using an old, used laptop like that for development because it helped force me to optimize. That paid off when I built an edtech project that had to run on old machines in a poor district. Non-US markets too benefit from less memory hungry apps.
All that said I agree that the developer experience is slower and more painful. So VMs can help simulate more restricted or very different platforms on more modern hardware.
Your problem space is much different than most people starting out, because you already know what hardware your software is running on, and could probably physically go there to test it out in person. In that case, a web or native app makes sense because you have already identified your market and it is not likely to change, nor are you likely to issue frequent updates. This is opposed to someone like Notion who does not know who their customers are or where they are coming from; they essentially offer a free service to anyone who can make it to their website. A bored user might click off the page and never encounter it again, while the district you worked for probably had a contract and bidding process that solidified the entire process ("we are going to budget money for this" vs "oh this looks cool, I might try it").
> Non-US markets too benefit from less memory hungry apps.
Agreed. I send my grandparents in Eastern Europe a laptop every few years, and their current one is from 2014. They probably don't have as much RAM or CPU power as me. However, it's been quite a few years since 8GB became the standard, and I think you need a really inefficient web app to start seeing the machine struggling there. Most of the time when we complain about slow web pages, it's really because of all the ads, not the app itself. If you shoved that much adware garbage into a native app, it would use just as much memory and be just as slow.
> VMs can help simulate more restricted or very different platforms
Definitely! In Chrome and Firefox's devtools, you can also simulate a 3G or GPRS cell connection, in order to measure page load times and see what you could do to optimize them.
I’m just going to say that market inefficiencies leave room for competition.
If you make a well liked app and build a new market, but it’s slow and missing features, then you leave a giant gap for someone to make a better version and steal your market
I really do not understand this blend of jabs. To me it seems like the people complaining about React and React-like frameworks are completely oblivious to the fact that well-designed desktop apps, where UI is decoupled from business logic and driven by state machines, are already pretty much React without hand-written widgets.
If you wanted to say Angular or Ember apps are more like traditional desktop apps, then sure.
Is it, really? I don't think so, at all. I mean, no one ever complained about webview-type apps because of the virtual dom. Ever. It has been known for ages that the myth about the virtual dom's so-called ineficciency barely fits in the realm of microoptimization.
https://auth0.com/blog/face-off-virtual-dom-vs-incremental-d...
There's an awful lot of irrational hatred towards webview-type apps for no good reason at all. That's it.
Sure, it is a good app, and it is popular, but it doesn't feel like a good example of a complex app that should be in the browser.
Can edit a quick photo without downloading anything and it is astoundingly well put together
As others have said: extreme portability and zero install hassle.
Gmail took off because of these reasons, offering an acceptably desktop-like GUI over the web.
One of them, yes, it's an insane one, the File System related things. When I started the project I was hoping the FileSystem Web API was going to be better and adopted faster.
The other one is React-specific, but using React is an implementation detail.
Other than that, what do you see as a significant difference between implementing UI Drafter as a browser app vs. a traditional one?