I work for about 2k users, they do not give a shit about reactivity... build a monolith, make it comfy, embrace page refresh (nobody gives a fuck about that in the real world), and get shit done.
As a counterpoint, many systems that were originally implemented as native desktop applications have since been migrated to the web. The motivation for this shift is not particularly strong from a technical standpoint, but it is a practical one: deploying native applications is simply too costly.
The web finally provides a widespread standard for deploying applications inexpensively. Unfortunately, the technology used to build user interfaces for the web remains somewhat mediocre.
It’s unfortunate that history took some wrong turns with X11, Java, Flash, Silverlight, .NET, and countless other alternatives that I haven’t personally lived through.
Hopefully, someone will eventually find a way to make developing web applications comfortable and the broader community will embrace it.
I think that using browser as the way to, essentially, deliver desktop LOB apps to the users seamlessly, updates and all, makes perfect sense. Writing those apps in HTML/CSS/JS, not so much - it's forced on us because that's the only stack that browsers have historically supported, but even with all the app-centric additions to HTML over the past two decades, it's clearly not designed for them first and it shows.
I hope that, in the long term, wasm and canvas (or something similar) will gradually take over this niche. Frameworks like Avalonia already let you write a desktop app and then surface it in the browser, today. This stuff is still rough around the edges, particularly wrt accessibility, but there's nothing unsolvable there in principle, it just needs time and effort (and money).
Nothing wrong with Flash and Silverlight except each being controlled by a single company. I liked those technologies. Adobe Flex was very nice to program in and use for it's time.
Nothing got my old iMac G5 whipped into a frenzy like loading a page that had Flash on it somewhere. I’m not kidding when I say that there were many areas in World of Warcraft, a full-fat seamless open world 3D MMORPG, that didn’t make its fans as angry as Flash could manage to.
I was so happy when it finally started to disappear. That kind of sheer disregard for my system resources is inexcusable.
It probably could’ve been great, but unfortunately such a thing would’ve been unlikely at best with Flash being solely controlled by Adobe. Not only does that company have a disinclination towards optimization that persists to this day, but with there having been no alternative implementations of Flash, there was no possibility of other organizations taking up that torch or for there to be competition between implementations driving things forward.
Flash was a lot of things, but also, at the same time, neither of these things. (You could come across poorly coded and thus poorly performing apps, but that wasn’t the standard).
Modern day SPAs are far, far worse offenders when it comes to smothering resources.
My experience circa. 2008/9 was it was fine (used it on a commercial app in lieu of good enough web standards for the featureset). It was fast and reactive for an app-like experience.
Games were made in flash so it can't be that slow.
Maybe slow for time to load. I think we got that down a bit and this wasn't to render content but a utility for a signed up user.
They were resource intensive (though probably less so than yr average React based site these days) but Flash, especially post AS3, was an order of magnitude or two faster than JS + html/svg/canvas at the time. It was years after the death of Flash that standards based tech finally caught up.
The flash player leaked memory. The longer-running the app, the more noticeable it was. I believe this is why Adobe Air (flash player packaged as deliverable) failed.
As for the speed of the flash player itself it was quite good.
I’m making a web game and using html, css and vanilla javascript for the UI is fine. I have transitions, sounds and everything is very fast without any of the bloat. The actual game itself is in canvas but everything else is standard web stuff.
> deploying native applications is simply too costly.
I do not understand why people hold this impression, especially in corporate environments.
Windows supports both system and per-user deployments; the latter so you don't even need administrator rights. And with Intune, deployments can be pulled or pushed.
Many desktop applications are written in .Net so you don't even need to install the runtime because it's preinstalled on the operating system.
Even ClickOnce deployments -- which you can deploy on the web or on a file share -- pretty much make deployments painless.
EDIT: For the naysayers: please then explain to me why Steam is so successful at deploying large games on multiple platforms?
We have 2 main products: a SaaS and a desktop app (1mln+ users combined). It's a pain in the ass to support the desktop app:
- many people refuse to upgrade for various reasons so we have to support ancient versions (especially for important clients), for stuff like license activations etc.
- various misconfigurations (or OS updates) on Windows can make the app suddenly crash and burn
- and you waste time investigating the problem. My favorite recent bug: the app works OK everywhere except on some Japanese systems where it just crashes with access violation (see the next bullet point)
- debugging is hard, because you don't have immediate access to the machine where the bug triggered
- originally it was built 100% for Windows but now we have people asking for a MacOS port and it's a lot of work
- people crack our protection 1 day after release and can use it without paying
SaaS has none of those problems:
- people are used to the fact that SaaS applications are regularly updated and can't refuse to upgrade
- modern browsers are already cross-platform
- browser incompatibilities are easier to resolve
- you debug your own, well-known environment
- if someone doesn't play by the rules, you just restrict access with 1 button
You could of course also make your desktop app auto update without offering a way to refuse. Or you could make it display an error, if the user accesses it without being at the newest version, and block all further interaction. Those are considered impolite, but it seems you are doing it anyway in your web app already.
Even the most friction-free ClickOnce deployment is going to be more of a deployment hassle than "hey, users, you know how you go to https://subdomain.local-intranet/place to add or subtract items from the inventory database? Well, continue doing that".
The webapp doesn't care if someone's machine was down overnight or if the paranoid lady in design managed to install some local "antivirus" which blocked the updated rollout or if the manager of sales has some unique setting on his machine which for some inscrutable reason does silly things to the new version. If their web browser works, the inventory database works for them, and they're on the latest version. If their web browser doesn't work, well, your support teams would have had to eventually take care of that anyway.
Some people should probably only be given thin clients, because they are too inept to be allowed to handle anything else.
Not sure yet how to solve this problem on the Internet yet though. How can we prevent uninformed masses from creating incentives for businesses, that turn the web into a dystopia?
The web browser is not some magic tool that is always guaranteed to work. Group policy alone can wreck total havoc on web apps on all the major browsers.
That sounds nice and it probably works fine if you're targeting a single business running Windows, but targeting Mac, Windows and Linux remains more difficult, no?
And is there even a guarantee that your deploy will be rolled out in X minutes?
Version skew remains one of the biggest sources of catastrophic bugs at the company I work for, and that's not even taking into client app ver, just skew between the several services we have. Once you add client app ver, we have to support things for 3 years.
At my one-person company I just do a Kubernetes deploy, it goes out in a couple minutes and everyone has the latest ver whether they like it or not. I don't have the resources to maintain a dozen versions simultaneously.
There’s a hidden cost in web applications as well: you lose the value of the operating systems application language. Every website and thus electron app suffers from this. There’s no standard place for settings, buttons and windows don’t behave normally. There’s a lot of value in native apps in usability just in it sharing the same UX language as the operating system. Sadly this is mostly dead for new applications.
Building a game for multiple platforms for steam is way more work than building a single web app. Builting the game often requires unique settings for each platform, machines for each target platform, testing on each target platform, dealing with bugs on each target platform. Getting noterized/certified on each
> EDIT: For the naysayers: please then explain to me why Steam is so successful at deploying large games on multiple platforms?
How many games are multi-platform on steam? Checking the top 20 current most played games, 14 of them are windows only. If it's so easy to be multi-platform, why would 14 of the top 20 games not be multi-platform? Oh, it's because it's NOT EASY. Conversely, web apps are cross platform by default.
Only 2 of the top 20 games supported 3 platforms (windows, mac, steam-deck). 1 was windows+steam-deck, 3 were windows+mac
Here's a good example: I used Weylus which turns any touch device (phone, tablet etc) into a drawing tablet + screen mirror. It can be used to turn your iPad into a second monitor or as a touch device for your laptop.
Weylus gives you a URL that you can visit on the device and instantly use it. Try doing that with native apps. They'd need native apps for Windows, Linux, Mac, iOS, Android... get them on the app stores too, support all the different Linux distros... or just a single URL that works instantly anywhere.
Steam works for the same reason the App Store works, it targets mostly a single platform (Windows) and all dependencies are bundled in. The Steam client itself is a web app running on the chrome engine, though.
In large corporate environments I agree but small companies still mostly don’t have central management of end user computers. They order a computer from Dell and use it as delivered. Much easier to just access everything via a browser that way.
Of course. I was strictly refering to .NET preinstalled in Windows as per the comment I replied to, which I believe only applies to Framework 4.8.
Although, on re-read, maybe they meant there's a good chance another application already installed it? This I wouldn't agree with, as applications often insist on installing different versions of the system-wide runtime, even for the same major version.
> please then explain to me why Steam is so successful at deploying large games on multiple platforms?
if you look into the support forums on steam for any random game you'll find lots of complaints about stability and crashes, many of which are likely to be esoteric system-specific problems.
I get the impression this is said by people who observe large enterprises or don't have good device management. I work for a big company that deploys proper MDM to our Macs and PCs, and as long as the application is packaged correctly, they sure can push stuff out fast and without user intervention, including killing a running process if they so choose. Making an app that packages well is also hard, but that's not on those who push them to environments.
I love ClickOnce and am amazed that it never got that popular. Installs and updates are seamless.
I wrote an inventory management program for my father's hazardous waste company. Used .net mvc as the backend, WPF as the frontend. WPF sucks in many ways, but I got it working and have had zero complaints.
I built that program almost 20 years ago. Until last year I spend maybe 5-6 hours total in maintenance, mostly ssl cert updates. Let that sink in.
I have seen more broken SPAs than MPAs, by far. Ironic, considering SPAs are supposed to improve conversion rates and user experience. Even from big companies with no excuse - Reddit is almost unusable on phones, X was straight up broken for a month straight with image loading on mobile.
If you’re writing an SPA, and it isn’t Twitter or a content consumption platform, and it isn’t necessary to be API-driven, seriously just stop. You’re not clever, you’re not improving the experience, you’re only appealing to the tastes of other programmers. If billion-dollar companies can’t get them working perfectly, you certainly won’t.
We created a generation of developers that AIM to over-engineer requirements... and we also came up with extremely pervasive frameworks to go with it... My firm cannot hire people with no React experience... people REALLY only know how to build cruft these days...
As a Rails developer with no desire to work in a React codebase, I'm not qualified for about 50-60% of the Rails jobs postings. My lastest full time was at Shopify where I said over an over that I was Ruby only and not interested in a React position only to be told a few months in I needed to know React to get promoted. It is exhausting.
I have given up on doing frontend work for the time being, because of this crap. I used to do full stack with modern JS, TS, CSS, HTML and whatnot, but then someone made it all go to shit by advertising for NextJS and React, while there was zero interactivity on the whole platform, except for a couple of checkboxes. A few years later, there still isn't much. Some page transitions for when things happen in the backend. I told them in the beginning, that there is not much interactive stuff, but they all got flashed by some one minute low effort Material Design shit, and the idea of the whole thing being "modern" and hiring more React devs. So I stepped away from that while frontend part and let them dig their own hole.
Moving a navigation/menu from one app to another takes 3 people 2-3 weeks by now. Changing the "router" to update the TS version is just as time consuming. Things that would have taken 1 day max. take now 2-3 weeks. That is 1/14th of the productivity and people get paid for that, more than I did. Oh and did I mention the menu responsiveness was broken for months at a certain viewport width? I did report it, but apparently it was so hard to fix, that it could not be done in a quiet hour, so it took months laying around in the queue of things to fix.
I have no React, Vue, or Angular experience. My websites were built with Livewire, some HTMX (basically Hotwire in the Rails world, server rendered HTML partials; or maybe Blazor SSR in the .NET world). I use Tailwind and a Laravel backend, but have some experience with C#.
If you think that’s interesting, send me your firm’s URL, I’ll consider applying. (Edit: or really anyone reading this who is interested - government of a foreign nation outside the US is not viable, unfortunately.)
Might be a bit of a selection bias though. I certainly remember a lot of crappy MPAs before SPAs got big. The crappines just moved to SPAs as they became mainstream. Overall I agree that MPAs are better default, though, good SPAs are hard to build.
Part of the complaints about MPAs originally was that navigating all the different pages was slow, because loading new pages was slow. But plenty of today's SPAs deliver content even slower and the user is staring at a spinner for lengthy stretches. The key is quick, efficient server responses, whether using SPA or MPA approaches.
Yeah. In theory SPAs should be faster, but in practice rendering/sending the whole template is not as bad. And as you mention, both can be slow, due to the non-cached API/DB call, so...
Even in theory, producing json is just typically slower than producing HTML.
It seems unintuitive, but traversing an object tree using reflection to generate json is just slower than using an HTML template, which is probably a rope data structure.
That reminds me of when I first benchmarked a Rails app and noticed that JSON rendering was significantly slower than the remote database call. No lie, jbuilder was taking about 80% of the request time for about 90% of all endpoints.
I guess the rendering itself is pretty much the same for both SPAs and MPAs, since in the end it can be pretty much the same markup, but the SPA is also at a disadvantage here because it has to combine template/components + JSON to generate the HTML :/
Not going to lie, that's a pretty out of touch opinion in the current decade, where most software feels an order of magnitude slower and less reactive than a mechanical device made 120 years ago.
Most of that software are bloated SPAs that somehow manage to be slower than a complete page reload of any website or app, that is rendered server side using any traditional web framework statically rendering HTML templates.
And adTech. I’ve been a happy user or the local gumtree [0] that always worked fine with my 9yo iPhone… until last year: the business model seems to have changed as they added in-list advertisement and I can only scroll the products list until the first ad wrapper shows up. Then the UI freeze and never gets back to life. I don’t even see the advertisements itself.
Edit: just tried it again and seems they fixed it! The ads stays in loading state forever but the site is usable again. Wonder if they did something on their side or if they changed ad provider.
This feels like bringing the annoying transitions people used to use between slides in PowerPoint to the web. There's nothing smooth about the transition in the linked demo, it's quite jarring.
I believe it’s finally enabled by default in nightly builds, so it should be standard soon. I may be wrong and it may have been scoped css enabled, but both are available by feature flags on nightly and plan to be enabled by default by the end of the year.
This just means that user doesn't get the animation tho, right? The actual page transition still happens, so you get graceful fallback without the need to do anything special.
I have a few sites that aren’t that complex, and I use JS to run a PHP file and populate the results in a div. It appears reactive, but it’s dead simple.
I get that huge apps probably need a lot more than that, but so many people these days reach for heavy frameworks for everything, because it’s all they know.
Sure, but the runtime is not exactly designed to guide you to the best way to do this. Hence the prevalence of frameworks to paper over the runtime.
I openly admit that I'd rather learn a new framework than touch anything to do with figuring out how the browser is intended to behave in practice. What an abomination and insult to humanity.
Edit: holy shit y'all do not like the earnest approach to technology
"Nobody knows how to do anything and shit is inefficient and slow and why does all of this software suck" - customers of things built using frameworks but no understanding of the system being abstracted
I guess openly admitting that you refuse to learn how your platform actually works is an "earnest approach", of a sort, but so is admitting that you routinely leave grocery carts in the parking lot and don't see a problem with it.
Theres even an insane amount of documentation on the web about the web. MDN is very well maintained to boot. Im not as versed as some on front end web, but I recognize that I can slice through a lot of front end stuff by just referring to MDN.
Something like that. Doesn't get much easier. Gone are the days of browser inconsistencies, at least of you stick to "Baseline Widely available" APIs which is now prominently displayed on MDN.
No-framework web tinkerer here. If I had a nickel for every second of my life I've spent typing document.getElementById, I'd be able to afford new fingers. Should've been renamed to getId() and put in global scope two decades ago, if not three. At least querySelector() is a few characters shorter, but I always feel bad using such an alarmingly overdesigned tool for anything trivial.
If I'm just adding sprinkles of interactivity to a statically-rendered page for something that vanilla is good enough for (i.e. minimal-to-no display logic), I use the expando giving an element an `id` adds to `window`:
You don’t have to call getElementById or querySelector on document. You can narrow the search by starting at a specific node, just most people default into document as it’s already a global.
That's a code smell. If you're creating the element you ought to already know about it. If you're not creating the element you should inventory them all at once as the page (or component) loads.
Also, it’s a mess separating stuff between react and the server, especially when building with express/node as the backend and the whole codebase together
It’s such a pain having clear separation in development where everything runs off of the react server by default, but then it won’t when deploying, so either you end up doing all sorts of weird stuff or you need to be building and running production locally constantly, thus defeating the whole convenience of having a dev server that can hot reload the changes
The nice thing about the plain "vanilla" approach is it can be used to enhance a more traditional SSR-rendered site. And it doesn't need a complete rewrite in React or whatever.
The author of this article blog is describing some more advanced SPA-like scenarios, but those are completely optional
Still the case in most Asian countries where UIs are all Craigslist alike and UX is just shit. People just got use to it. Apparently westerns willing to pay a premium for better UX. It's a culture gap.
Side note but as a buyer looking to buy used tools from locals, Craigslist's UX could not be better. I just started using it recently (after forgetting about it for a decade). Absolutely the opposite of shit.
Though I think maybe if one is using it for a different purpose, like looking for apartments or roommates then that's probably shit.
People looking to get shit done don't really care but, when they're just mindlessly clicking, they'll hit the back button to the main feed way before the time it takes to fetch a modern framework if your site happens to be the first they hit with that particular version from the CDN.
Page refresh between pages is ok. Lag when updating a form based on your inputs isn't. Frontend UI is like a bigger monitor or faster PC - you may not have known what you were missing, but once you've experienced it it's very frustrating to go back to the clunky old thing.
It's really irritating for your users. They might not consciously be able to point it out as the cause of their irritation, but they'll like your app a lot less.
