I just know the web is very hard for my kids to use, and the more app-like the page the harder it is. Watch them use a page for a minute and they’ll remind you of two or three janky, shitty, or counter-intuitive things about web interfaces that you’ve become blind to, through familiarity.
Native’s much more likely to be ok.
Chief problems are: web interface design tends to be much worse than native (even if they look nice on a screenshot), UI latency is bad and gets worse the more JS you throw at it, there’s more likely to be unhelpful functionality the developer’s accidentally created (selecting the text on a “button” rather then clicking it), and they’re more likely to have weird state-related fragility.
This author seems to think the only competitor to react is other js frameworks, when in fact most of the web's largest sites work just fine with small amounts of what he calls 'artisanal js'.
You probably don't need your js framework, your 10k npm dependencies, or your complex mix of server and client side rendering. Not every website needs an api and clients to consume it, and not everything needs to be an app.
The web is a success because it is simple, accessible, fast, and nobody cares how the server makes the html they are reading. Let's keep it that way.
I keep hearing this, but I think it's too broad of a statement.
There are definitely functionalities that are impractical to implement with server-side rendering and forms alone. Map widgets and drag-and-drop come to mind.
The issue I have though, is that the overwelming majority of web functionality can be implemented as server-side rendering.
But you don't need javascript frameworks to add a small amount of state changes without page reloads, it's very easy to do without using something like react.
The comparison is between server-side with a bit of js where required, and the proposed 'modern web' where js frameworks attempt to take over the entire experience server and client side so that they can remodel the world in their image.
Most websites simply don't need react and friends, even if they are more app-like than doc-based they still don't need it, and they certainly don't need to be a single page application (the best modern example of throwing out almost everything that is good about the web - urls, links, docs, stateless).
We can make those with JS/React so I wonder if users can tell.
Of course the hugely popular, cross-platform apps are probably going to be "really native" forever..
Apps only work for very specific use cases. The difficulty in getting people to download your app shows that. That study doesn’t seem to break down what apps are being used. I’m going to guess games, as they dominate the charts, or specific websites that have created mobile apps. Facebook, Twitter or maps, which are used for multiple hours straight when driving.
If there is a site you use often enough it graduates to living in your phone. But the majority of what apps can do is never even touched.
I’d be much more interested in a breakdown of app usage, as I bet active time shifts more towards web
I'm not sure it really needs to be explained that if you're trying to introduce a service to someone for the first time, asking them to access a web page (available on whatever device they're with at the moment and up, running and ready to interact with in seconds) is less likely to lose their attention than asking them to download and install yet another app.
I personally don’t have much problem with the 100+ apps on my phone, but really it’s an app graveyard. I use maybe 10 regularly. I’ve also cut social media apps from my phone due to battery usage and privacy violations.
Downloading an app is more personal, phone storage space is still a premium for many people. App devs don’t seem to care at all how big there app is. We yell at at web devs when their page is >1mb. I’ve tried downloading simple apps whose size are 400mb, what the hell are they doing? If I can visit their site that’s 1mb or download their app that’s 400x, maybe I’ll just visit the site and be on with my day.
You’re on a web page. You can either do what you need or tap the install link, approve the install, wait for a huge download, find and open it, wait for it to initialize, authenticate in the app, and then find whatever you were doing. If you use this all the time it’s amortized over heavy usage but the vast majority of business apps are not, and every study I’ve seen shows people falling off at each of those stages.
How much of this is a consequence of companies intentionally crippling their websites, though? I can name countless companies that either don't have a website beyond what is essentially a link to the app store or have removed a significant number of features from their website.
Well, I think this is really hyperbolic. I think it depends on the application, and the consumer. And the web is a tremendous success. You should take a step back and look at how your entire life is affected by the web. It seems really, really off the mark to say that the web is not a success.
You can criticize it, sure. But - you are using a computer 100% because of the web, not because of spreadsheet software.
Now, back to web vs. native. You just have people who prefer either. I exclusively use apps. I think the experience is better in every way, and I've never seen a web application deliver comparable experience to a native app. But, almost every native app is backed by a web server. And, some things I do want to remain web apps, like Wikipedia.
I think the web community overall looks at native apps like they are some weird, alien technology because they're completely blinded by what they build and what tools they use. Like always, if we understood why users enjoy native apps, we could learn a lot of things. I'd argue that we are learning that, which is why there are lots of SPAs. That doesn't mean that's the only way to build software, it just means that people do actually enjoy that experience.
> I think the web community overall looks at native apps like they are some weird, alien technology because they're completely blinded by what they build and what tools they use.
There is some everything-looks-like-a-nail but that's not all. I'm making a native desktop app now which is slow going. Every platform I want to support is so different, and cross-platform tooling often requires branching and learning each ones quirks anyway.
Just making an Electron/ReactNative app is often the best of both worlds should a website not suffice. (Excluding concerns like battery life, app size, or memory footprint.)
There's a distinction to make between "the web is successful" and "the web has made humans successful". We've paid a tremendous privacy and security cost, and a loss of control over our online lives.
If they dived deeper into the usage patterns and broke down app usage by specific apps, I'd suspect a vast majority of that time is spent in a tiny handful of popular apps, since there are also countless studies pointing to the fact that consumers don't install more than a handful of native apps.
If you remove time spent in those popular apps and their respective websites from the stats, the data would likely paint a vastly different story (that might not be in the best interest for a site that relies on pushing "Launching mobile apps for your WordPress site" to highlight ofc).
Well, "90% of user time on devices is in native apps, 10% web" does paint a rather different picture than "70% of user time is in social media and messaging apps, 10% media apps like Netflix or Spotify, 5% mobile games, 5% all other apps including all the built-in ones other than the browser, 10% web" if you're not in social media, media, or games and trying to decide whether to go web or native.
Alternately, “If you don’t assume that all usage is fungible, the data tells a different story”. There are a few apps - music/movies/ebooks and Facebook - which get a disproportionately large amount of activity. If you’re not competing with them, the global numbers are going to be skewed.
This is especially true when you think about tasks rather than screen time. If I’m Facebook or Spotify selling ads, I want people glued to the app for a long time. If I’m selling things, giving information or customer service, etc. the story is completely different: someone placing an order faster is actually a win.
EDIT: My experience is colored by being in the cultural heritage space where the flurry of “we’re in the App Store!!!” entries met the hard reality of every engagement metric being much lower than web sites. There is huge variation hidden in global averages.
Wait, are you saying that "90% of mobile time is spent in apps vs 10% in browsers" tells the story that "consumers vastly prefer native apps"? I don't think the connection is that strong.
Taking myself as an example, I may spend 90% of my time on my cell phone using the Messages app, the Phone app and a handful of apps that I installed a long time ago, but I'm much more likely to try out a new web app than I am to try out a new native app. Looking at my phone now, I see exactly one native app that I installed in 2020.
Based on my and my friend's preferences, we prefer mobile app for apps they will be using a lot and trust, like Facebook/Slack/Twitter/Email, and want to use the web for apps we rarely use or don't trust as much.
Op is arguing that based on our intuition the data aggregated at that level doesn't distinguish between this more complex story and the simple one of "people prefer apps".
I also wonder how much the current epidemic and increased migration towards WFH will affect native mobile app usage, particularly among non-driving commuters. People will be using desktops more for casual browsing, and thus likely to be using web browsers outside of a small number of desktop apps (office suites, games and so on).
Yeah, we let the web become Cable TV. It's dying the same slow death as Cable TV while executives scratch their heads about why the perpetual growth stopped.
The advertising is so pervasive, so annoying, so invasive and so awful it just makes the medium unusable. The same trends are starting to creep into podcasting and video games and I just wish people would realize they are slowly destroying their own businesses with this garbage.
Does that really mean anything other than you can do more things with mobile devices than just browse the web? I might use WhatsApp on my phone, draw with Procreate on my iPad or play games. I don't see why any of those things should involve the web browser, but that doesn't mean the web is somehow dying.
I mean, to draw an analogy, it doesn't mean Netflix is dying if I use 90% of my time at home not watching Netflix.
Why do any of those things need to be native apps, rather than instantly-accessible, no-install-required URLs that come with all the protections of the web's security model?
The first thing that comes to mind is that I can use them offline. I don't need the internet to draw or play most games.
EDIT: I do understand you can make web apps that work offline by jumping through enough hoops. But then again, why would you? Why try to unnecessarily shoehorn everything into the web paradigm?
Let's take an iPad drawing app that is super well integrated with Apple Pencil. What benefit would forcing it onto the web bring, considering the performance hit and usage of specialized hardware?
Or a recording app that I might use to take voice notes or record other audio. Why does that need to be a web application?
* The trade-off is that they're alien to the platform either behave entirely different or at worst poorly emulate platform semantics.
* this is true-ish. It's not that they can't it's that they aren't. If Apple or Google just up and blocked a site in Safari or Chrome it's basically dead. "Technically accessible in Firefox" isn't exactly a selling point. You're also gate-kept by your ability to get a public cert.
* True but download size only really matters on first install. It's absolutely friction but not really something that I've ever seen people care about anymore. Pictures take up almost all of the storage on people's phones now.
* True but the trade-off there is that you have to download it every time. Native apps win in the long run if you use it often.
* Users have never cared about this. This is only a benefit to the very techy.
They don't have to be. But also it isn't clear the web is the right tool for that job just because there are some pros.
I'd rather see better cross-platform native tools than more web tools. The web is bloated, overloaded, and has a lot of historical baggage. That isn't to say it can't still be used well, but I still like seeing alternatives with innovation.
>Does that really mean anything other than you can do more things with mobile devices than just browse the web?
That depends, what is the usage pattern of browsers vs. everything else on the desktop computer? Because you can use the desktop computer for more things than browsing the web.
That's a very weird assumption to make considering that the web was intended for sharing information, not running applications. The fact that customers prefer native apps does not mean that the web is dead. The web is good for somethings. And native is good for others.
For ex., I read your article on a mobile webpage. Downloading an app for that would be madness. But trying to use a big webapp like jira on the mobile would be a study in madness. Hell, It doesn't work on the desktop well enough.
The bottom line is that the web is good for some things, native apps are good for some things. Instead of trying to shoehorn web everywhere, it would be better to use the correct tool for the job
Even the word "prefer" is questionable. The typical consumer gets an Android phone which comes with pre installed apps. Should they somehow still by choice end up at a web property, they are aggressively pulled towards the native app.
What do you mean "prefer"? The correct word is pushed.
The web is the most successful document publishing platform in history. It's what enabled this conversation.
Many of the most popular apps are reliant on the web or web servers for their content (social media for example), and it's ok if some content is not on the web. Games for example are a special case which are better served by native code.
A marketer like the one doing those surveys is understandably going to be concerned with where the captive eyeballs are, and platforms do have a tendency to try to herd users into their walled garden, but in the long run I think the open web will win over corporate walled gardens.
Web apps are dying because the web isn't a good application platform. Google made a real good argument with Gmail and Maps, but unless you have their resources (even if you do, looking at Facebook here), it's very hard to create a great application experience on the web--for many of the reasons you write about in your post.
But I think that's fine. The web isn't a good application platform, but it is a good information platform. There's also other protocols beyond HTTP. Imagine if getting the most out of the internet didn't require millions of lines of C++, hyper-complicated JS JITs, layer upon layer on HTTP, and opening the door to the surveillance state.
Even gmail and Google Maps aren’t what they used to be. On a machine that isn’t top of the line, Gmail takes ten+ seconds to load to interactivity, and then going to each email takes five or so seconds. It’s basically unusable.
On a machine that isn’t top of the line, Gmail takes ten+ seconds to load to interactivity, and then going to each email takes five or so seconds
For giggles, I just loaded HN on a 2011 MacBook Air. It took just under 2 seconds for the front page.
Then I loaded GMail on the same machine. 15 seconds to the front page. Plus, it came in with 21 errors ranging from invalid headers to invalid sources to cross-origin issues.
I'm still struggling to understand why my small react app which has 7 dependencies (4 of which are react, react-dom, react-router, react-router-dom) needs 615 node modules.
While the percentage of time that I use in apps vs. the web is definitely heavily skewed, it is just two apps: Facebook and YouTube... occasionally Instagram or TikTok. Now ask the question "what percentage of products do you use are you using via an app or via the web" and the answer is going to be ridiculously dominated by the web: I might use 20 different products over the course of 10 minutes on the web while researching some topic, flipping between hacker news, stack overflow, medium, smaller personal blogs, documentation from microsoft or mozilla, major and minor news sites... this list is absolutely endless. Even for sites I might use that have an app, I am not going to open that app for just the one page I want from it as that's slower and pointless as I probably only want to use that site for five seconds.
Essentially, you have purposefully asked the wrong question in order to lie to us using statistics.
Just about every major website will continually prod you to install their app when viewed on a phone. I have given in myself a few times just to make the nagging go away. That muddies the “web is a failure” argument imo.
If the sites in the genres I care about remain, I am unaffected (except for, perhaps, economically in a bigger picture).
For example, I don't care if ESPN's app is favored over it's website. I don't care if various lifestyle magazines have apps. Lots of examples here, pick your own.
I spend my time on the web or in a select few apps like Discord, Hangouts, Signal, etc. Even then, I don't really care if the sites are optimized for mobile. I usually prefer when they aren't because most people do it poorly. Just make a nice website with appropriate viewports and non-fixed whitespace on the sides and it'll probably work out unless you're doing some fancy interactive stuff. In which case, I probably want it to be on a desktop anyway.
Such a poor take. Consumers mass spending time in chat and Netflix doesn't mean the web is dying.
Consumers hate apps. The average they install per month is zero. 90% of their installed apps are completely unused. Almost any new app they do install has single usage, and is then abandoned forever.
Every time a web designer complains that a full-page refresh is "jarring", a bit of me dies.
This is like saying a lightbulb turning on quickly is jarring. It's the expected, immediate behavior. If every lightbulb I used turned on with different durations and easing functions or flashed colors at me, or loaded a flashing placeholder while the lightbulb loaded, that would be jarring.
As far as I'm concerned, the problem is the people who choose to disable JavaScript and demand to be catered to without considering how much extra development resources I'd have to allocate to maintain a version of my app that works with JavaScript disabled, despite barely even constituting a rounding error in my usage statistics, and the JavaScript version offering a vastly superior experience for the rest of my users.
Or when I click the 'reply' button to post this very comment, which does result in a jarring full-page refresh — and one that instantly robs me of the fuller context in which I'm replying.
But this gives you the option of opening the reply link in a background tab (via click-and-hold or middle-click, depending on your UI). Can't do that in a JavaScript SPA without re-hydrating tens of megabytes of JS for each tab you load.
> without re-hydrating tens of megabytes of JS for each tab you load
You'll be taken more seriously if you don't engage in meaningless hyberbole. You could recreate the open-the-reply-page-in-a-new-tab behaviour of HN (with the context-preserving JS enhancement for the non-middle-clickers) with a few kilobytes of JS if you're doing it right.
> You could recreate the open-the-reply-page-in-a-new-tab behaviour of HN
That is the crux of the problem. Why is there this obsessive need to recreate what is already available?
> with a few kilobytes of JS if you're doing it right.
As experienced with PHP developers in the dark ages, that never works. It will be a choice between easy and incorrect or difficult and right. The majority will never do it right for various reasons. And the web will loose in the eyes of the users.
> That is the crux of the problem. Why is there this obsessive need to recreate what is already available?
For exactly the reasons stated: to both support in-line reply without the jarring page refresh, and to be able to open the reply form in a background tab.
And I think what Rich wants/is working on is making it both easy and right, because indeed, otherwise it will never happen.
It's funny to think about it that way given how much we've pushed back on them over the years, but a pop-up window might actually provide the best experience (bonus points if it was local to the tab).
I just shift-clicked reply, and it works quite well. I might add a rule to my sway config to make the "Add comment" windows floating :)
In the end, everyone is different and has different needs. That's why I like standards: everyone can set their user experience as they prefer it (or pick a web browser that chooses good defaults for them).
Agreed, I’ve often opened another tab, found the context of the comment I’m replying to and hopped back and forth. HN can be an echo chamber of JavaScript is the devil, websites should only serve html.
> HN can be an echo chamber of JavaScript is the devil, websites should only serve html.
It's a reaction to the reality of the web, which is that Javascript is commonly used when it's entirely unnecessary, much more of it is often used than is necessary, and it's often used to abuse webpage visitors. Most on HN don't object to ajax-y bits of JS that make a page more pleasant to use.
Ryan Florence makes a fine point that his tool is being used to build things that don't benefit from it, but this isn't necessarily a good interface. It's pretty but it's just got way too much going on at once. How does anyone actually read in that context?
Why do you assume that it's just web designers? Have you ever shown a web app vs. a native app to someone who doesn't write code? Or just someone who has design sensibility?
The lightbulb example is also not a good one. A lightbulb transitions between two states. An interactive application transitions between hundreds of states. Full page refreshes make each transition clunky and noticeable. Only programmers look at it and say "yea, that's fine," because we know how difficult a web browser is to implement. But end users don't care about difficulty. They care about the end result.
I don't really have a problem with web apps doing incremental loading when it makes sense (Facebook, for example, or letting the user add a comment in situ), but many many sites would be better off just loading documents instead of moving to an application framework. Take for instance TechCrunch.com vs Wired.com, Wired is much easier to use because it acts like a website. Yes, it does full page refreshes instead of showing a full-page loading spinner, but it behaves more consistently and doesn't require the user to learn new UI paradigms.
What about Google Sheets? It would be pretty strange to input a number into a cell and have the page refresh to perform a calculation no? Frankly I'm not sure how any application falls into the document paradigm. It was created for linking documents of text, not interactive applications.
Well, I might be biased as you are saying, and much of this is subjective, but I much prefer a snappy browsing experience, where clicking a link takes no longer than the round-trip time (25-50 ms in most cases) to load the web page.
Have you tried the dillo web browser, for instance? It's refreshingly fast and snappy (including on my old atom netbook from 2008) to use.
I have had a subjective feeling for a while that some user interfaces felt "solid", almost tangible. To me, Windows XP does that. Windows 10 feels like a smokescreen next to it. There might be pretty colors, fancy gradients, but I do not feel like I directly control the UI anymore, I am forced to wait for an animation to finish, I have trouble determining where the window border is. And I've found it much harder to rely on my positional memory to navigate apps that have a smooth transition, like mobile apps.
This is not a rant against Windows10's UI (I have barely used it, and just use it to draw a comparison in the Windows family, you could also compare different KDE versions), but with contemporary user interfaces in general. That could even be said of some command-line interfaces. We're also used to progress bars, or worse: spinners. Trained to wait idle in front of our computers, while a dozen megabytes of frameworks are stuffed down the pipe so that the page background is just the right white shade (probably while I am using a dark theme, and the CSS rules to apply that shade probably only work correctly on Google chrome). That's what modern web feels like to me.
"Only programmers look at it and say "yea, that's fine," because we know how difficult a web browser is to implement."
No, not just programmers. Also end users. It's a complete myth that the traditional link/page refresh method is jarring to users. It's perfectly normal and expected to click a link and to have it loaded in a reasonable time frame, without some weird transition in between.
But what you’re describing with lightbulbs is basically an ode to the technical limitations of the time they were invented.
We have had dimmable bulbs that are far less jarring for a long time and now smart bulbs can do the easing automatically when you flip the switch, and change color and brightness depending on time and environment.
It’s such a nice improvement. I don’t even notice until I turn it off and I realize that white light at night is piercing and yellow light during the day makes me sleepy. Or that 100% brightness in the morning and night is way too much.
I think it’s a case of not wanting to go back once you realize what you’ve been missing.
Sure the world you describe with flashing bulbs would be horrible but that’s not what it’s really like.
I think it's more prominent and damaging there on account of all the churn, combined with large amounts of stupid money.
Mobile native developer? Might be something new you want to get familiar with every couple years, but really you'll likely be OK, career-wise, if you sleep on it for another year or two unless you actually need it. C++ developers aren't chasing brand-new frameworks to stay hirable, generally. Java and C#, most of the ads seem to be "have experience with [eight-year-old 'new' thing that's basically an ecosystem-wide standard now anyway], plus a bunch of much older things", and those two alone are a really high percentage of all software jobs.
And the industry at large has completely disregarded browsers and demoted them to being mere thin clients for accessing applications.
Just why can't we improve the user agent instead of turning every website into an app that does its own thing to provide the UX?
For example:
> We can kick off requests as soon as the user first touches (or hovers) the link instead
There's no reason this couldn't be built-in to the user agent. It could very well pre-load pages before you even start scrolling around, or it could start loading as soon as you hover, or it could start loading as soon as you click. I get to decide, because I can configure my UA. People on data caps will be happy to turn it off. Meanwhile you can optimize your ugly slow service so that it processes requests fast enough that you don't need these hacks..
> We can provide better visual feedback that loading is taking place
Usually I get either crickets or a spinner or something went wrong if it's the javascript doing this. Again I think it is the user agent's place to give the user visual feedback (according to their configuration). I'd turn them off, because they're not useful. I'd rather have you spend time making your ugly slow service faster than implementing transition animations to "hide" the latency.
> The fact that we can do server-side rendering and communicate with databases and what-have-you using a language native to the web is a wonderful development.
The author isn't just a React apologist, but also seems to want javascript everywhere.
So much of this debate - sever side rendering, etc. - has to do with the inefficiency of DOM. Mobile and desktop UI toolkits aren't DOM for a reason. They do application UI and have application concerns, meanwhile JS is sitting in this weird Frankenstein ducktaped documents-and-apps markup world. An ecosystem that has to support a million (often competing) things, but all slowly, and with decades of legacy we can't break.
It's going to be interesting change of landscape when we have isomorphic Rust/Wasm delivering truly native web apps that don't render on top of the 30 years of DOM kludge.
The Rust community is just getting started and hasn't had a long time at this, but there's already some really impressive UI work being done in the browser with Rust/Wasm [1]. Once Rust frontend frameworks begin to arrive, it'll be a whole new ballgame. It's so damned fast.
JavaScript downloading and parsing is much more computationally expensive than html parsing.
The DOM seems slow, I think mostly because it requires translating between rendering systems - the representation of the html has to be updated, the styling has to be applied, and the change has to be painted on screen. This explains why updating a documentFragment as a batch operation is much faster than changing the dom directly in a loop.
God forbid. I happen to like adblockers, inspecting app DOM, and applying custom styles and features with browser extensions. I can customize even poorly-built web apps like Youtube and Facebook with enough poking around and custom selectors. It's great.
Don't bring native UX sensibilities to the web, or we'll retaliate by pushing Electron even harder for cross-platform native development. And yes, that is a threat. ;)
Every time this conversation comes up, I make the same point: the DOM is not a layout tool, the DOM is a user interface. The DOM forces you to give your users a pure-text representation of your current state -- it forces you to think of your current state as an XML-like data object before it allows you to think in visual terms. That's the point: your user interface is XML, not pixels.
Imagine if every native GTK app forced you to come up with a universal text interface that worked in terminals before it would let you add any of the weird keyboard handlers and unresponsive layouts and HDPI-unfriendly menus on top of it. That is how the web do.
> God forbid. I happen to like adblockers, inspecting app DOM, and applying custom styles and features with browser extensions. I can customize even poorly-built web apps like Youtube and Facebook with enough poking around and custom selectors. It's great.
This is weirdly lost on HNers every time this "debate" comes up.
Native apps are the wet dream of any website they complain about for having too many trackers and ads and data exfiltration.
The web browser is a fluke of history that gives users power that we don't have with native apps. Let's not be so quick to give it up just because you've never mitmproxy'd your phone to see what it's doing.
It's going to be interesting change of landscape when we have isomorphic Rust/Wasm delivering truly native web apps that don't render on top of the 30 years of DOM kludge.
Google Sheets has used canvas for rendering for years.
Hey that Makepad looks great. Too bad it doesn’t make my phone keyboard appear. You know… the same thing you get by adding a plain `contentEditable` DOM attribute.
Maybe reinventing the whole damn car on canvas isn’t a great idea either. I bet that the keyboard isn’t the only part that doesn’t work.
Flash was hated for this reason too: Breaking affordances. Imagine everyone reinventing their own UI framework on each app.
> Too bad it doesn’t make my phone keyboard appear.
I don't like this argument. It's like saying that because C++ can do everything, we don't need to build a new language to fix problems inherent with the existing paradigm.
Rust is just getting started, so give it time.
DOM is overloaded, messy, and slow. We need an application UI toolkit similar to what Android and iOS provide.
I don't think the argument is that you could never make a keyboard appear with WebGL. It's that the speed increases and improvements you're seeing are due to the fact that there are about a thousand edge cases and alternative environments that these WebGL-based replacements have never considered. Anybody can make a demo that's faster than the DOM. I can make a native framework that's faster than GTK if you let my demo ignore all the things that GTK has to care about.
The problem is that by the time you've finished building a WebGL layer that has the same accessibility features and component-level controls and custom shortcut support and extension APIs as the DOM, it will no longer be a snappy, fun, fast experience. What you'll end up with is a second implementation of a web browser that runs on top of a web browser, and that has to be downloaded fresh every time you visit a new website.
WebGL and Canvas frameworks are fast because they allow you to build an interface that does fewer things -- that only worries about pushing pixels to the screen. They allow you to avoid adding the overhead of app-agnostic universal UI components with predictable behaviors, or accessibility layers, or custom font support, or universal shortcuts for scaling, or responsive layout support.
And sometimes you don't need that stuff. Sometimes you do only care about pushing pixels to the screen, or you're doing something very specific that allows you to avoid thinking about edge cases. But if you're going to universally replace the DOM, then you do need to care about edge cases.
Keep in mind, Firefox is also running in C/Rust and rendering webpages using OpenGL. It's operating on the same bare-metal layer. The DOM is already written in low-level languages and rendered out with OpenGL. It's not slower than Canvas because they used the wrong tech stack, it's slower than Canvas because it does more stuff.
I'm very excited about WASM as a replacement for Javascript. And to their credit, that's what the Rust team is doing. For the most part, the direction that Rust is actually going isn't towards WebGL, it's towards getting good DOM access in WASM.
The future of Rust/WASM mostly looks like people writing code in the language of their choice, with speed improvements based on the fact that the language isn't high-level or garbage collected, and then using that faster, more comfortable language to manipulate the DOM, just like we always have.
Apart from "apologist" not really being a term conducive to constructive discussion, I think, the author is also the author of one of the main competitors to React (Svelte), and has often and strongly criticised it. (Which is not to say that he hates it, but just to point out that "apologist" isn't really correct, and thus that it could be that the article is triggering some defensive reflexes that might not be entirely justified.)
I hope that someday, more devs/designers will realize that adding more Javascript to change the web's document centric nature doesn't work, and just makes things worse. If you want an app, make an app, not a website.
My take is, however, that the web as we know it is going to be split in apps and websites.
Sites is stuff that works fine with an 'old classy' request->response method, stuff like blogs, newssites, wikis, information sites, simple booking sites etc. You can make a great living just doing that. Probably most content available on the web will fit in this category. However I think Wordpress and similar frameworks / libraries will continue to dominate this field.
Apps is stuff where you practically need a SPA, where there is no choice. Things like music players, photo editors, file managers, chat applications etc.
Old mom n pop shops will still be around and never need a SPA, but a lot of applications being ported to the web do need it. If you do old style websites, there is nothing wrong with that and it still works fine for a lot of stuff. But if offline capability is a requirement (as an example), it is very hard to make a compelling case without making a SPA.
I like both, I find the old style apps to be a lot quicker to develop but the SPA, PWA style app gives the user a much native feel which is important for a lot of apps.
I'd really love to see an entirely new rendering context for the web. Right now you have to go WASM > JS > DOM. What if there was something else, like AOM (application object model) that gave direct access to WASM. It would allow the DOM to go back to what it was originally intended for - interactive documents.
eh, not really. It's true that Canvas is its own rendering context, but it's just a drawing API. There is a whole suite of technology needed for applications that is currently only available to html/js. Things like accessibility, text input, etc. What I'm imagining is a rendering context that, like the html document, provides those things out of the box.
All I really want from the web is to get text, images and data and submit form data. I don't really want interactive applications which are almost but not quite entirely unlike proper native apps. I just want to read interesting people and submit my own thoughts in return. I want to see pictures & text about things I want to buy, and submit my address & payment information to buy them.
The modern web delivers some of that, but only accidentally. The modern web is all about delivering potential malware to me and expecting me to run megabytes and gigabytes of this code, all in order to … display pictures and text, something the browser has been capable of for over twenty years.
You have control over your browser. Just disable Javascript. Some websites don't work? So what?
Now compare that to the rest of software where you don't have that control and you'll see software has always been in the state of your hyperbole about pushing malware to your machine that can always be making http requests that you can't see.
It's a bit sad that even technical people are only waking up to this when it comes to the web because they can finally see it with the browser's network tab, so they think it's just a web problem and begin advocating for throwing the baby out.
> When I tap on a link on Tom's JS-free website, the browser first waits to confirm that it was a tap and not a brush/swipe, then makes a request, and then we have to wait for the response. With a framework-authored site with client-side routing, we can start to do more interesting things. We can make informed guesses based on analytics about which things the user is likely to interact with and preload the logic and data for them. We can kick off requests as soon as the user first touches (or hovers) the link instead of waiting for confirmation of a tap — worst case scenario, we've loaded some stuff that will be useful later if they do tap on it.
What? The solution to making a website fast is to crunch analytics (presumably on the client and in JS, all of which has to be loaded beforehand for this to work) and then try to predict what the user is going to do on the website, anticipate it, and start loading, even when it might go waste?
Wastage of network bandwidth aside, Speculative Execution destroyed the chip performance in the last two years and opened up a whole lot of scary security holes, some of which may never be fully patched without performance hits. And the bright idea is to do that in the browser?
It's hardly crunching analytics. If there's a call-to-action on the homepage, it's likely that the user will click it, so we should pre-load it. I believe Gatsby will pre-load any link that's visible in the viewport by default$
But what if the user does not click on it but clicks on something else? Then we are back to square one with a lot of effort for nothing.
> I believe Gatsby will pre-load any link that's visible in the viewport by default$
If it does that, then no wonder that the original article was completely right. On a page with 10 visible links in the viewport, I will only navigate to one or maybe I won't navigate. Then why the hell is my battery, network bandwidth, etc is being used for it what is essentially 90% wastage?
Yes, this. I about fell out of my chair reading this paragraph.
In these discussions, I find defendants of these SPA designs to almost always point to vague points about "rich UI" or "highly interactive", or make up complete hypotheticals like this example of pre-loading likely-to-be-clicked links. Show me the code. Show me the crazy-fast link-click-predicting website that does this and loads faster than, say, HackerNews.
It's good to see the pendulum swinging back to some semblance of sanity on this topic. The past ~5-10 years of the SPA being the default choice has been a wild time. I couldn't be happier that it's starting to receive some widespread criticism.
> Show me the crazy-fast link-click-predicting website that does this and loads faster than, say, HackerNews.
https://hn.svelte.dev/ is a Sapper implementation of Hacker News. It uses the preload-on-hover/touch technique described in the article. In my experience it does indeed feel faster than Hacker News, despite basically being something I threw together one weekend
Wow. It loaded the 1000+ comment Ask HN thread "What's your quarantine side project?" in less than a second for me. I've seen HN itself choke on smaller threads.
Update: since posting this it looks like the site is being hugged to death — might need to upgrade something in GCP :) Either that or it's a coincidental problem with https://api.hnpwa.com/v0/
The funny thing is that a single module inclusion in a traditional link based website will deliver all of this predictive preloading for you. One line of code.
Which debunks one of the critical advantages of an SPA.
The other is transitions. Which are never implemented because it's just too damn hard. Instead you get a spinner, 17 API requests (instead of 1 Ajax request), and a giant fragment of the DOM replaced whilst you lose your scroll position.
Being able be assured that you can find/hire folks to work on your tech stack is a pretty important concern for a business. Thus, it can make sense to go with a popular framework/language because it can help in that regard.
I was disappointed to find that this post falls into the same pit a number of these defences of the modern web fall into - creating a false dichotomy between "literally no JavaScript whatsoever" and "a framework-authored site with client-side routing". None of the features mentioned in that particular paragraph - user interaction analytics, preloading data and content [on link hover], transitions, avoiding full page loads - need a site to be an SPA, nor are they "fiendishly difficult" to do for the [near-]static sites MacWright discusses in his blog post.
I think it's a shame that frontend web developers have thrown themselves behind the SPA paradigm so hard that the notion of a JavaScript ecosystem that doesn't try to do pull _everything_ into its own domain is unimaginable. I'd love to see more mindshare go towards building libraries that are drop-in/"just add water" progressive enhancements for static sites.
As a person who is browsing the web, I do want server rendered pages, correct history of navigation, urls to match pages, a lack of refreshes, live collaboration with other users. What I dont want is a manual refresh to lose anything or bring me to a different page. And I want the site to work, and progressively fail if I have javascript off.
Most interactivity can still be server side. Look at google.com, as you type in a search query, and they return a static update with results matching what youve typed so far.
Ah - I didn't have anything quite that powerful in mind, more like fairly simple, browser-local enhancements to make interacting with regular old HTML pages more pleasant. For example a drop-in library that would save the state of a form and restore it on a refresh, like the old formsaver jQuery plugin. I would like to see an ecosystem of libraries like that again
>I'd love to see more mindshare go towards building libraries that are drop-in/"just add water" progressive enhancements for static sites.
Sounds like jQuery plugins.
Seriously though, I wish for a similar thing without the baggage. Maybe there needs to be a common interface defined for such "just add water" libraries.
There was/is so much that was genuinely awesome about jQuery. I still remember fiddling around with my blog as a teenager and being blown away by the DataTables plugin.
Interestingly enough, neither myself nor MacWright advocated returning to writing large jQuery apps so I truly fail to see how this comment is relevant.
I've long ago abandoned spaghetti mega-scripts and SPAs in favor of targeted JS libraries that extend HTML capabilities. They're not web components, they don't require some framework to manage, and my HTML works fine without them, but if I load the library and add certain attributes or tags to my markup, I get extra capabilities. The libraries don't require crazy tooling to manage, don't have extensive dependencies and so they facilitate steady incremental development.
I'm very happy with this approach and I'm reusing code I've written years ago for completely different projects.
> .. in favor of targeted JS libraries that extend HTML capabilities.
Do you mean libraries like Turbolinks[1] and/or Intercooler[2] here? I'm interested in what libraries you use, and others like these which help "bridge the gap" between traditional and single-page sites.
Yes, those are some of the examples. You can roll your own as well. With modern JS and CSS selectors you can create useful, reusable libraries with just several dozen lines of straightforward code.
Unpoly [1] is another one in that camp. Made good experiences with to smoothen page transitions in a server-side rendered app [2]. I find this model much more approachable for backend devs than going all-in on SPA. It doesn't help of course with more fine-grained interactions like say in-place editing in a table.
As discussed on a recent thread (https://news.ycombinator.com/item?id=23137324), there are a variety of nice frontend tricks to make a server-rendered site feel nicer (LiveView, TurboLinks, Livewire, instant.page).
I'm a fan of these kinds of solutions. For my 100% static website, https://instant.page does make it feel instant. TurboLinks feels a little "heavier" and has a more complex interaction with other frontend code, but it works very well.
Yes - those were the exact technologies I had in mind when reading that paragraph. We've been pre-fetching/loading HTML in place for ages! If all you need is faster/less jarring transitions between static pages, it's incredible to me that anyone would immediately reach for an SPA.
Funnily enough, the TFA is on a Ruby on Rails blogging platform that uses these tricks to feel incredibly fast. Just look at your network log as you hover links.
I recently used Turbolinks + Stimulus for a Django side project. While these projects originated in Rails, it was quite easy to add to Django with some middleware and webpack tweaking. Stimulus provides some good structure and constraints for adding JS "sprinkles" to the site and overall it's worked very well. It feels more like I'm building with the browser and HTML rather than against or around them. That said, I don't think this approach would fly at work and would probably be frowned upon as maybe inefficient or out of date compared to the pure SPA+API architecture.
IIRC there were some old packages but these were unmaintained and didn't work with later versions of Turbolinks, so I ended up looking at Rails source and other examples. Basically making sure to handle redirects and headers correctly. You can see the webpack config in the same project, pretty much just standard setup with some tweaks for loading Stimulus controllers.
Another is: DerbyJS, Racer, and ShareDB who have been fighting for this future for what feels like forever, but meteorjs just torched it from a popularity perspective, in the the event-driven server-side rendering realm. Despite giving a much worse end user experience, it was more popular with developers. Is Lever really the only company using Derby?
I think its kinda great that you can just use ShareDB with whatever else you use, or also use racer, or go full blown framework. The way its abstracted gives you the power to choose more or less.
LiveView may not be "the future", everyone loves their Javascript too much, but it is the future for me. AJAX with the server is what I feel I was promised back in the Web 2.0 days, not tons of Javascript running in the browser.
If it's a totally static site it certainly doesn't need it.
But if you have any amount of interactivity (forms, widgets, etc) SSR makes total sense. Specially with component-level hydration which means the duplication of content would be lower than traditional SSR. AFAIK Marko is the only framework that has this feature.
I recently started using Sapper for a personal site and have been enjoying it immensely. I find that the abstractions that Sapper/Svelte make in order to avoid full page loads, preload data, etc allow me to write the site in a component-oriented way while not shipping 5MB of JS to the browser. And, Sapper scales as the app gets bigger in a way that a raw static site just can't.
Rich seems to be advocating for a JS middle-ground here, which I think is a great direction to go in for this kind of workflow.
I don't mean to sound rude, and I apologise if I come across that way, but this is the exact sort of "JavaScript über alles" tunnel blindness that I'm tired of. Sapper/Svelte is _far_ more complex (especially in terms of overhead/learning curve for the site creator) than a tool a user wants to use to create enhanced static sites has any right to be.
Not everything is an app, and frankly I think we build a lot of non-apps as if they are apps because we enjoy the feeling that we've engineered something.
I rephrased what you were saying to take out the negative valence.
This is similar to other articles I've seen that draw a distinction between two choices: zero javascript vs full SPA. I think this is a false dichotomoy because most features advertised for SPAs (analytics, data/content preloading, transitions, optimized page loading) can be implemented for static sites as well. It would be nice to see frameworks that were more modular and interoperable because this would allow/give engineers the choice to decide which parts they want to be static and which parts they want to be dynamic.
I'm not sure if I agree with what you're saying though because you haven't provided examples of how the features of SPAs can be accomplished without JavaScript. Do you have references and examples?
Many people doing the coding haven't really thought that deeply about the systems.
I'd like "web programming" to start with Vannevar Bush's As We May Think, then go to Licklider, Ted Nelson, then hypercard programming (hypertalk). Set up a BBS, a gopher site and then write HTML for NCSA Mosaic.
Read the RFCs and W3C standards, learn about Netscape's SSJS failure before touching nodejs, you know, serious academic scholarship. Maybe look at the failed TCL browser support, which has example snippets in the HTML 4 standard, understand why it didn't work, etc.
I think it's a combination of both over-engineering and poor engineering leading to unnecessary and unmanageable complexity.
Some project starts and they decide to use an uncessarily complex framework (which may be well engineered for the cases it was developed for at the Facebook/Google scales of the world) then grab 3 more and glue them together using poor practices, then proceed to build all sorts of complexity ontop of that stack using poor engineering and typically non-standard practices.
New people join and voila, they immediately need to understand these 3-4 underlying complex yet well engineered systems and how they are poorly glued together before they can even begin to unravel the poor engineering practices that sit ontop of them so they can fix and extend them.
Parts of the application look well structured, other parts are incredibly confusing. Suddenly you need to go back and better understand some of the underlying frameworks leveraged so you can actually discern what's supposed to be going on which takes forever because that underlying framework is quite complex in and of itself.
In the end you're running around documentation page to documentation page from frameworks and looking at undocumented code someone wrote in between, consuming stupid amounts of time.
Someone built a big pile of technical debt and you just inherited it. Good luck, they've switched to another team, project, or employer and moved on before the mess unfolded.
Meanwhile, you're wondering why 90% of this exists for a product feedback submission form.
I needed to read this after fighting with Upwork (an apparently Angular website, which i found out via necessity, trying to figure out if my payment was being processed, double-billed, or not processing at all). Here is another primary example of a victim of the modern web, a website that needs none of it, yet had to be converted to one of the 'constantly spinning wheels on 20MB pages' framework. Thanks, modern web for slowly destroying every service that i use. At this rate, by next year the web will grind to a complete halt.
Genuine question: are smooth page transitions really worth all of this?
It seems that page transitions really are the main reason given for using JavaScript-everything for sites and simple applications that otherwise could have been built with some fast loading HTML and a couple of POST forms.
And worth noting React's implemention of vdom is at odds with smooth page transitions, since unmounting components are immediately removed from the DOM.
No they are not. Well, first of all, most SPAs don't actually deliver on this promise anyway.
But let's look into the point made by the author regarding the inspiring example of Apple's app store UX, and trying to aim for that.
We, meaning as an industry average, will not achieve that level of UX no matter the stack. Because nobody can afford it. It requires a team of top designers, interaction engineers, dev, QA, etc.
That's the problem with the SC valley mindset. They assume every web property has this huge team of top engineers behind them, and that this is a status quo, and applies to the whole web.
One piece of evidence: The site this is posted on, which is by now open-source and frequented by many developers, still does not manage to get page transitions right, and by clicking links and using the back button you can get in a state where the page suddenly doesn't let you scroll anymore.
I think transitions are cool the first few times I see them, but eventually I just want to get work done. I'll take a fast UI over a pretty one any day. The only transitions I want in a tool are the ones that help my mind follow what's happening. But that help has to outweigh any additional latency caused by having to wait for the transition to finish.
>With a framework-authored site with client-side routing, we can start to do more interesting things. We can make informed guesses based on analytics about which things the user is likely to interact with and preload the logic and data for them. We can kick off requests as soon as the user first touches (or hovers) the link instead of waiting for confirmation of a tap — worst case scenario, we've loaded some stuff that will be useful later if they do tap on it. We can provide better visual feedback that loading is taking place and a transition is about to occur. And we don't need to load the entire contents of the page — often, we can make do with a small bit of JSON because we already have the JavaScript for the page. This stuff gets fiendishly difficult to do by hand.
No, it's not. It's easy and you can do all that without an SPA framework. If you can't see this in about 5 seconds, you shouldn't be lecturing other about how to design websites.
Preloading hovered links can be done with a standalone library. AJAX can be done with another a standalone library. Removing extra crap from your page to facilitate faster AJAX can be done with a custom request header and a couple if-else statements on the server side. Best of all, this stuff can be added after you have a working website.
> Preloading hovered links can be done with a standalone library.
Couldn't it even be done in two lines with vanilla javascript? On hover fetch() the URL, then rely on the browser cache for when the user actually clicks?
> When I tap on a link on Tom's JS-free website, the browser first waits to confirm that it was a tap and not a brush/swipe, then makes a request, and then we have to wait for the response. With a framework-authored site with client-side routing, we can start to do more interesting things. We can make informed guesses based on analytics about which things the user is likely to interact with and preload the logic and data for them. We can kick off requests as soon as the user first touches (or hovers) the link instead of waiting for confirmation of a tap — worst case scenario, we've loaded some stuff that will be useful later if they do tap on it.
How many sites actually do this? And how much additional bandwidth (and battery life for mobile devices) does doing this consume?
> We can provide better visual feedback that loading is taking place and a transition is about to occur. And we don't need to load the entire contents of the page — often, we can make do with a small bit of JSON because we already have the JavaScript for the page.
In my experience sites that do this are almost universally slower and less responsive than sites that just use normal links. Maybe that's just confirmation bias and I just don't notice it as much on sites that do it well, but a particularly egregious example of this is Reddit's current mobile site vs their old i.reddit.com mobile site (which I use exclusively (despite it missing a number of newer features and having a lot of minor bugs the newer site doesn't) because it's way way faster).
> In my experience sites that do this are almost universally slower and less responsive than sites that just use normal links.
Yup. A car analogy: "Instead of waiting for the driver to turn the steering wheel before causing the car to turn, we put the car on the back of a flatbed truck that tracks driver behaviour and tries to predict their intent. Then we can start turning the flatbed truck a little bit sooner to improve user experience."
> Maybe that's just confirmation bias and I just don't notice it as much on sites that do it well
This seems to me to be the key phrase.
I sympathize with all the "JS has gone too far" people in this thread. I also hate bloated JS apps. But, "almost all SPAs are bloated trash" is a distinct claim from "SPAs are intrinsically trash".
In my experience it is possible to have lean, high-performance, accessible SPAs without too much developer difficulty. Svelte (created by the author of this article) is one framework in this space, although I think there are better approaches.
Do you know of good SPAs? Sites that feel snappy even though they're SPAs. Most sites I visit that are SPAs are consistently slow so I've learned to make the same association: SPA = bad.
It seems like this whole discussion would work better with examples where people are willing to say "This is done well, and it has these benefits from having been done in this way"
We've been experiencing sluggish pages since long before JS really became a thing too. PHP and a slow inline query to render results has been a possible problem for literally decades.
Do you investigate all the fast snappy sites you visit to confirm they aren't single page apps? What about the slow pages that aren't SPAs (most every news site)?
It seems like anyone who wants to dislike JS and/or SPAs can easily confirmation-bias their way into believing it.
This is just a demo, of course, but it is close enough to be representative. From just this simple demo we can already see significant differences: Svelte and Solid.js are much snappier. The author of the article, Rich, created Svelte.
Of course, this is just talking about performance, not yet getting accessibility, navigation, transitions, etc right.
I love this question, in another comment I call it the Fermi paradox of SPAs. Where are they?
The simple question as to where are all these inspiring SPAs that truly push the web to next levels...is completely unanswered.
We get docs sites, demos and blogs. Where when clicking on a link...wow!...it loads without a page refresh. Something possible using simple ajax some 15 years ago.
> I'm not aware of any other platform where you're expected to write the logic for your initial render using a different set of technologies than the logic for subsequent interactions. The very idea sounds daft.
It's not a perfect parallel, but this reminds me of systems like Qt Designer, or Apple's Interface Builder/Storyboard, or Android's XML layout system. Those systems all essentially give you an "initial render" made with one technology (XML files created in some sort of visual GUI-builder program) and "subsequent interactions" made with another (C++/Swift/Java code).
> Web developers are currently trapped in a mindset of discrete pages with jarring transitions — click a link, see the entire page get replaced whether through client-side routing or a page reload — while native app developers are thinking on another level.
In native apps, I'm a sucker for pretty transition animations, and I'd love to see those on the web.
But, every website I've ever seen with those types of fancy transitions for large pieces of content (as opposed to little on-page microinteractions) also feels slow, clunky, and heavy. As such, I've come to associate such transitions with slow, clunky and heavy web pages.
I'm not really a web developer, so feel free to tell me if everything that follows is stupid: It seems unlikely that our "current trajectory" can ever resolve this problem. Instead, we'd need an underlying technological shift in how browsers work.
Most large transitions are basically browser hacks—albeit ones we've used so frequently, and for such a long time, that they've come to be officially supported and accepted. To make them more usable, they'd probably need to work alongside the browser in some manner.
SPAs are a good thing for Apps. Back-office, etc... all great things here.
SPA tech is a good thing for web sites that have little appy parts (like checkout processes, or maps). I'm not saying for the entire website, but just little focused parts. Can you imagine going back to (the old) Yahoo Maps now that Google Maps exists?
Are SPAs good for entire websites (like the new reddit?) Personally I like the new reddit over old reddit. But this is where your users are highly relevant. If you don't listen and choose SPA for millions of users of the public, you will probably get Feedback. You might be lucky and only 10% hate it, but it might explode in your face if that's a key 10% that encompasses influencers.
From visiting tons of different sites that have decided to "modernize", I can assure you there is no defense for how god-awful the "modern web" actually is.
Like most deep in the SPA bubble, this author cannot imagine any other outcome than SPA-everything. Meanwhile, any alternative view is put aside as being an anti-JS crusader (which misses the point entirely), simply being old, or even barbaric whilst he continues to high five his bubble inhabitants on Twitter.
SPA as the status quo is a myth. It's a Fermi paradox. Where are they? Almost nothing of any importance is an SPA. You'd think that if they have such superior experience, they lead to superior business metrics, thus they are everywhere. Asides from true app-like experiences like Gmail, Spotify, the like, they're nowhere to be found. Not in places of significance. It's 2020 and Amazon continues to be old school page refreshes. Last time I checked they're doing quite OK. Even big parts of Facebook, the poster child of complex interactivity, continues to do full page refreshes in big parts of the experience.
Instead, SPAs are a startup default, not a web default. Big difference. And the way most are implemented, they don't live up to their potential benefits, instead deliver UX that is even worse than static:
- breaking back buttons
- breaking scrollbars
- rendering things that aren't interactive
These things don't have to occur, they can be solved in an SPA, but they do occur a lot in the wild. This matters. We live in the real world.
As somebody else here already mentioned, the article takes a completely wrong approach. It assumes some binary choice or outcome. The original point instead was that the web is not a single thing. It's a huge thing where different stacks are to be used for different use cases. This point is largely ignored, instead it is implied that SPAs should simply solve such use cases better, whilst continuing to be a default.
On the particular point of SPA links being typically faster/smarter: there's about 500 drop-in solutions to speed up static links. Which are usually not needed, because the point of such links being bad is overstated and lacks any user evidence. See my earlier remark on virtually all major websites using plain old links. They wouldn't if it was so bad.
Finally, a huge part lacking in this discussion is the accessibility of web development itself. The SPA web is an engineers web, it requires advanced programming skills, infrastructure, increasingly complex tools chains, and so on. If this was to be a true default (luckily it isn't), it would lock out the vast majority of people wanting to contribute to the web.
It's sad to see this sub culture of hardcore engineers with Macbook Pros thinking they own or represent the web or web development.
The whole point of a SPA is to give a user a better experience. If on average this does not materialize in the real world, and often achieves the exact opposite, the entire concept fails.
Bad SPA implementations are the standard. Saying that it's possible to make a good SPA implementation doesn't change the real world outcome that most often, they don't deliver.
Another angle I'd like to add to this discussion is something that gets near zero attention: longevity.
Many SPA developers rapidly move from project to project. Every once in a while, they learn yet another JS framework, and then hop between jobs to use that.
They never look back. They never truly need to take responsibility for a tech choice.
Try to hire an Angular 1 developer to work on 300K lines of code today. You can't. No skilled front-end developer would take on such a job with options to work on hotter tech.
Any SPA choice you make today will be completely obsolete in 3-5 years. 3-5 years, or even 10 years or more, is a normal life cycle for a serious web property. And not just obsolete, you'd have the hardest time getting the tool chain to still work at all.
The original developers don't care, they using tech N+5 now, somewhere else. They'll be very vocal how N+5 is vastly better than anything else, and really the only option for "the modern web".
Angular becomes a front-end COBOL in just a few years, not 3 or 4 decades.
There's more. A typical front-end architecture depends on a complex interwoven tool chain with a lifespan of at best years, sometimes even months.
Same for modules. It's normalized to have an absurd dependency tree of hundreds to thousands of inter-depending modules. The vast majority of which will be abandoned in a few years.
I wonder if a lot of the disagreement is just people talking past each other.
I used to think it was an oversimplification to divide the web into Documents and Applications. I thought it was more accurate to say it was a continuum, and using two different techniques was a sign that we still had not figured it out. After all, a blog post about programming might have an interactive example. An article about retirement might embed a calculator. If you try to categorize a site or even just a page as Document or Application, it gets fuzzy. But if you look at a page and just try to categorize it section by section, as Document or Application, it's easier. (Hence, Web Components make more sense to me.)
So anyway, most people spend some time surfing the web --- by that I mean visiting Documents. Clicking links from search results, to articles, to more articles. If you aren't using an adblocker, I can't imagine how you don't end up throwing your laptop against the wall. I ended up just turning off JavaScript for most sites, and the web looks more like how I think it should look. Every once in a while these people will post a rant, and it will resonate with most people.
But then an Application Developer will read it after a long day and say, hey, wait are you saying I should write my Application (like GMail) in jQuery? To be honest, Applications don't bother me the way overscripted Documents do. I almost expect them to be kind of slow. After all, even some Desktop Applications still have loading screens. So I don't mind so much if you're using React or whatever for your Application or even for that calculator embedded in the article about savings.
But for Documents --- like articles, blog posts, company home pages --- well, one thing I agree with SPA developers is that there could be less server-side rendering. These kinds of sites could often be compiled ahead of time into static HTML. Server-side rendering is better than SPA for these kinds of sites, but static sites are better than server side. I mean, who enjoys getting "Error connecting to MySQL database"? (Okay, that's rare.) I'm intrigued by the old-new JAM Stack :)
223 comments
[ 15.1 ms ] story [ 237 ms ] threadNative’s much more likely to be ok.
Chief problems are: web interface design tends to be much worse than native (even if they look nice on a screenshot), UI latency is bad and gets worse the more JS you throw at it, there’s more likely to be unhelpful functionality the developer’s accidentally created (selecting the text on a “button” rather then clicking it), and they’re more likely to have weird state-related fragility.
You probably don't need your js framework, your 10k npm dependencies, or your complex mix of server and client side rendering. Not every website needs an api and clients to consume it, and not everything needs to be an app.
The web is a success because it is simple, accessible, fast, and nobody cares how the server makes the html they are reading. Let's keep it that way.
There are definitely functionalities that are impractical to implement with server-side rendering and forms alone. Map widgets and drag-and-drop come to mind.
The issue I have though, is that the overwelming majority of web functionality can be implemented as server-side rendering.
The comparison is between server-side with a bit of js where required, and the proposed 'modern web' where js frameworks attempt to take over the entire experience server and client side so that they can remodel the world in their image.
Most websites simply don't need react and friends, even if they are more app-like than doc-based they still don't need it, and they certainly don't need to be a single page application (the best modern example of throwing out almost everything that is good about the web - urls, links, docs, stateless).
Believe me, you're preaching to the choir. Nor am I advocating for every website to have an API. But unfortunately we part ways here:
> The web is a success
The web is not a success. It's dying. Consumers vastly prefer native apps — one recent study (https://www.mobiloud.com/blog/mobile-apps-vs-the-mobile-web/) tells us that 90% of mobile time is spent in apps vs 10% in browsers.
If there is a site you use often enough it graduates to living in your phone. But the majority of what apps can do is never even touched.
I’d be much more interested in a breakdown of app usage, as I bet active time shifts more towards web
This one I'm always interested in. What is difficult about downloading an app?
Downloading an app is more personal, phone storage space is still a premium for many people. App devs don’t seem to care at all how big there app is. We yell at at web devs when their page is >1mb. I’ve tried downloading simple apps whose size are 400mb, what the hell are they doing? If I can visit their site that’s 1mb or download their app that’s 400x, maybe I’ll just visit the site and be on with my day.
You can criticize it, sure. But - you are using a computer 100% because of the web, not because of spreadsheet software.
Now, back to web vs. native. You just have people who prefer either. I exclusively use apps. I think the experience is better in every way, and I've never seen a web application deliver comparable experience to a native app. But, almost every native app is backed by a web server. And, some things I do want to remain web apps, like Wikipedia.
I think the web community overall looks at native apps like they are some weird, alien technology because they're completely blinded by what they build and what tools they use. Like always, if we understood why users enjoy native apps, we could learn a lot of things. I'd argue that we are learning that, which is why there are lots of SPAs. That doesn't mean that's the only way to build software, it just means that people do actually enjoy that experience.
There is some everything-looks-like-a-nail but that's not all. I'm making a native desktop app now which is slow going. Every platform I want to support is so different, and cross-platform tooling often requires branching and learning each ones quirks anyway.
Just making an Electron/ReactNative app is often the best of both worlds should a website not suffice. (Excluding concerns like battery life, app size, or memory footprint.)
Curious. Did you post this using a native app?
On my mobile I never access HN via the website, I use one of those apps.
If you remove time spent in those popular apps and their respective websites from the stats, the data would likely paint a vastly different story (that might not be in the best interest for a site that relies on pushing "Launching mobile apps for your WordPress site" to highlight ofc).
"It's often useful to take context into account when evaluating statistics"
This is especially true when you think about tasks rather than screen time. If I’m Facebook or Spotify selling ads, I want people glued to the app for a long time. If I’m selling things, giving information or customer service, etc. the story is completely different: someone placing an order faster is actually a win.
EDIT: My experience is colored by being in the cultural heritage space where the flurry of “we’re in the App Store!!!” entries met the hard reality of every engagement metric being much lower than web sites. There is huge variation hidden in global averages.
Taking myself as an example, I may spend 90% of my time on my cell phone using the Messages app, the Phone app and a handful of apps that I installed a long time ago, but I'm much more likely to try out a new web app than I am to try out a new native app. Looking at my phone now, I see exactly one native app that I installed in 2020.
Op is arguing that based on our intuition the data aggregated at that level doesn't distinguish between this more complex story and the simple one of "people prefer apps".
The advertising is so pervasive, so annoying, so invasive and so awful it just makes the medium unusable. The same trends are starting to creep into podcasting and video games and I just wish people would realize they are slowly destroying their own businesses with this garbage.
Does that really mean anything other than you can do more things with mobile devices than just browse the web? I might use WhatsApp on my phone, draw with Procreate on my iPad or play games. I don't see why any of those things should involve the web browser, but that doesn't mean the web is somehow dying.
I mean, to draw an analogy, it doesn't mean Netflix is dying if I use 90% of my time at home not watching Netflix.
EDIT: I do understand you can make web apps that work offline by jumping through enough hoops. But then again, why would you? Why try to unnecessarily shoehorn everything into the web paradigm?
Let's take an iPad drawing app that is super well integrated with Apple Pencil. What benefit would forcing it onto the web bring, considering the performance hit and usage of specialized hardware?
Or a recording app that I might use to take voice notes or record other audio. Why does that need to be a web application?
* platform agnostic
* can't be blocked by a central platform gate-keeper
* generally much smaller (download size) than native apps
* don't take up permanent space on your device (good for things you only use occasionally)
* always up-to-date
Personally I prefer native apps for tools I use frequently. Everything else I prefer the web.
* this is true-ish. It's not that they can't it's that they aren't. If Apple or Google just up and blocked a site in Safari or Chrome it's basically dead. "Technically accessible in Firefox" isn't exactly a selling point. You're also gate-kept by your ability to get a public cert.
* True but download size only really matters on first install. It's absolutely friction but not really something that I've ever seen people care about anymore. Pictures take up almost all of the storage on people's phones now.
* True but the trade-off there is that you have to download it every time. Native apps win in the long run if you use it often.
* Users have never cared about this. This is only a benefit to the very techy.
I'd rather see better cross-platform native tools than more web tools. The web is bloated, overloaded, and has a lot of historical baggage. That isn't to say it can't still be used well, but I still like seeing alternatives with innovation.
That depends, what is the usage pattern of browsers vs. everything else on the desktop computer? Because you can use the desktop computer for more things than browsing the web.
That's a very weird assumption to make considering that the web was intended for sharing information, not running applications. The fact that customers prefer native apps does not mean that the web is dead. The web is good for somethings. And native is good for others.
For ex., I read your article on a mobile webpage. Downloading an app for that would be madness. But trying to use a big webapp like jira on the mobile would be a study in madness. Hell, It doesn't work on the desktop well enough.
The bottom line is that the web is good for some things, native apps are good for some things. Instead of trying to shoehorn web everywhere, it would be better to use the correct tool for the job
What do you mean "prefer"? The correct word is pushed.
Many of the most popular apps are reliant on the web or web servers for their content (social media for example), and it's ok if some content is not on the web. Games for example are a special case which are better served by native code.
A marketer like the one doing those surveys is understandably going to be concerned with where the captive eyeballs are, and platforms do have a tendency to try to herd users into their walled garden, but in the long run I think the open web will win over corporate walled gardens.
Web apps are dying because the web isn't a good application platform. Google made a real good argument with Gmail and Maps, but unless you have their resources (even if you do, looking at Facebook here), it's very hard to create a great application experience on the web--for many of the reasons you write about in your post.
But I think that's fine. The web isn't a good application platform, but it is a good information platform. There's also other protocols beyond HTTP. Imagine if getting the most out of the internet didn't require millions of lines of C++, hyper-complicated JS JITs, layer upon layer on HTTP, and opening the door to the surveillance state.
For giggles, I just loaded HN on a 2011 MacBook Air. It took just under 2 seconds for the front page.
Then I loaded GMail on the same machine. 15 seconds to the front page. Plus, it came in with 21 errors ranging from invalid headers to invalid sources to cross-origin issues.
Essentially, you have purposefully asked the wrong question in order to lie to us using statistics.
Given how hard certain sites (fb, LinkedIn, reddit for a start) push their apps it is kind of understandable.
Please everyone remember though that using does not necessarily mean prefer.
I mostly loathe apps.
If the sites in the genres I care about remain, I am unaffected (except for, perhaps, economically in a bigger picture).
For example, I don't care if ESPN's app is favored over it's website. I don't care if various lifestyle magazines have apps. Lots of examples here, pick your own.
I spend my time on the web or in a select few apps like Discord, Hangouts, Signal, etc. Even then, I don't really care if the sites are optimized for mobile. I usually prefer when they aren't because most people do it poorly. Just make a nice website with appropriate viewports and non-fixed whitespace on the sides and it'll probably work out unless you're doing some fancy interactive stuff. In which case, I probably want it to be on a desktop anyway.
Consumers hate apps. The average they install per month is zero. 90% of their installed apps are completely unused. Almost any new app they do install has single usage, and is then abandoned forever.
- most people only install popular apps
- top apps in playstore are actively hostile to using their website.
Reddit, Imgur, instagram, snapchat, whatsapp, twitter etc. You name it. They either don't have a functioning mobile website or native only.
Svelte projects do not put 10k dependencies in the final bundle.
In fact when using Svelte you won't need many dependencies you typically need when using React:
- State management (MobX, Redux, etc)
- CSS stuff (classnames, CSS in JS, etc)
- Animation
Even on a simple use case like a synthetic benchmark Svelte is still the absolute leader in start-up metrics:
https://krausest.github.io/js-framework-benchmark/current.ht...
Also check the metrics for a real world project:
https://medium.com/dailyjs/a-realworld-comparison-of-front-e...
This is like saying a lightbulb turning on quickly is jarring. It's the expected, immediate behavior. If every lightbulb I used turned on with different durations and easing functions or flashed colors at me, or loaded a flashing placeholder while the lightbulb loaded, that would be jarring.
You'll be taken more seriously if you don't engage in meaningless hyberbole. You could recreate the open-the-reply-page-in-a-new-tab behaviour of HN (with the context-preserving JS enhancement for the non-middle-clickers) with a few kilobytes of JS if you're doing it right.
That is the crux of the problem. Why is there this obsessive need to recreate what is already available?
> with a few kilobytes of JS if you're doing it right.
As experienced with PHP developers in the dark ages, that never works. It will be a choice between easy and incorrect or difficult and right. The majority will never do it right for various reasons. And the web will loose in the eyes of the users.
For exactly the reasons stated: to both support in-line reply without the jarring page refresh, and to be able to open the reply form in a background tab.
And I think what Rich wants/is working on is making it both easy and right, because indeed, otherwise it will never happen.
I just shift-clicked reply, and it works quite well. I might add a rule to my sway config to make the "Add comment" windows floating :)
In the end, everyone is different and has different needs. That's why I like standards: everyone can set their user experience as they prefer it (or pick a web browser that chooses good defaults for them).
It's a reaction to the reality of the web, which is that Javascript is commonly used when it's entirely unnecessary, much more of it is often used than is necessary, and it's often used to abuse webpage visitors. Most on HN don't object to ajax-y bits of JS that make a page more pleasant to use.
I'm also kind of gawking at the screencast he uses as an example:
https://twitter.com/ryanflorence/status/1186675229621248000
Ryan Florence makes a fine point that his tool is being used to build things that don't benefit from it, but this isn't necessarily a good interface. It's pretty but it's just got way too much going on at once. How does anyone actually read in that context?
The lightbulb example is also not a good one. A lightbulb transitions between two states. An interactive application transitions between hundreds of states. Full page refreshes make each transition clunky and noticeable. Only programmers look at it and say "yea, that's fine," because we know how difficult a web browser is to implement. But end users don't care about difficulty. They care about the end result.
Have you tried the dillo web browser, for instance? It's refreshingly fast and snappy (including on my old atom netbook from 2008) to use.
I have had a subjective feeling for a while that some user interfaces felt "solid", almost tangible. To me, Windows XP does that. Windows 10 feels like a smokescreen next to it. There might be pretty colors, fancy gradients, but I do not feel like I directly control the UI anymore, I am forced to wait for an animation to finish, I have trouble determining where the window border is. And I've found it much harder to rely on my positional memory to navigate apps that have a smooth transition, like mobile apps.
This is not a rant against Windows10's UI (I have barely used it, and just use it to draw a comparison in the Windows family, you could also compare different KDE versions), but with contemporary user interfaces in general. That could even be said of some command-line interfaces. We're also used to progress bars, or worse: spinners. Trained to wait idle in front of our computers, while a dozen megabytes of frameworks are stuffed down the pipe so that the page background is just the right white shade (probably while I am using a dark theme, and the CSS rules to apply that shade probably only work correctly on Google chrome). That's what modern web feels like to me.
No, not just programmers. Also end users. It's a complete myth that the traditional link/page refresh method is jarring to users. It's perfectly normal and expected to click a link and to have it loaded in a reasonable time frame, without some weird transition in between.
We have had dimmable bulbs that are far less jarring for a long time and now smart bulbs can do the easing automatically when you flip the switch, and change color and brightness depending on time and environment.
It’s such a nice improvement. I don’t even notice until I turn it off and I realize that white light at night is piercing and yellow light during the day makes me sleepy. Or that 100% brightness in the morning and night is way too much.
I think it’s a case of not wanting to go back once you realize what you’ve been missing.
Sure the world you describe with flashing bulbs would be horrible but that’s not what it’s really like.
What you’re complaining about is the lightbulb taking 3 seconds to turn off and its toggle costing $100. Now that something nobody likes.
- The developers want to prove themselves with a new technology
- The site owner wants to make money, so adds are required
- The website needs to "verify identity" to cut down on fraud, so invasive trackers are added
- The finance team wants to cut down on infrastructure costs, so they want less done on the servers
- The user wants to do what they came for done, but may be frustrated by how the site slows down the browser
This tug-of-war is a lot of what leads to slow, resource-intensive, privacy-invading websites.
Mobile native developer? Might be something new you want to get familiar with every couple years, but really you'll likely be OK, career-wise, if you sleep on it for another year or two unless you actually need it. C++ developers aren't chasing brand-new frameworks to stay hirable, generally. Java and C#, most of the ads seem to be "have experience with [eight-year-old 'new' thing that's basically an ecosystem-wide standard now anyway], plus a bunch of much older things", and those two alone are a really high percentage of all software jobs.
Just why can't we improve the user agent instead of turning every website into an app that does its own thing to provide the UX?
For example:
> We can kick off requests as soon as the user first touches (or hovers) the link instead
There's no reason this couldn't be built-in to the user agent. It could very well pre-load pages before you even start scrolling around, or it could start loading as soon as you hover, or it could start loading as soon as you click. I get to decide, because I can configure my UA. People on data caps will be happy to turn it off. Meanwhile you can optimize your ugly slow service so that it processes requests fast enough that you don't need these hacks..
> We can provide better visual feedback that loading is taking place
Usually I get either crickets or a spinner or something went wrong if it's the javascript doing this. Again I think it is the user agent's place to give the user visual feedback (according to their configuration). I'd turn them off, because they're not useful. I'd rather have you spend time making your ugly slow service faster than implementing transition animations to "hide" the latency.
The author isn't just a React apologist, but also seems to want javascript everywhere.
So much of this debate - sever side rendering, etc. - has to do with the inefficiency of DOM. Mobile and desktop UI toolkits aren't DOM for a reason. They do application UI and have application concerns, meanwhile JS is sitting in this weird Frankenstein ducktaped documents-and-apps markup world. An ecosystem that has to support a million (often competing) things, but all slowly, and with decades of legacy we can't break.
It's going to be interesting change of landscape when we have isomorphic Rust/Wasm delivering truly native web apps that don't render on top of the 30 years of DOM kludge.
The Rust community is just getting started and hasn't had a long time at this, but there's already some really impressive UI work being done in the browser with Rust/Wasm [1]. Once Rust frontend frameworks begin to arrive, it'll be a whole new ballgame. It's so damned fast.
[1] http://makepad.nl/
The DOM seems slow, I think mostly because it requires translating between rendering systems - the representation of the html has to be updated, the styling has to be applied, and the change has to be painted on screen. This explains why updating a documentFragment as a batch operation is much faster than changing the dom directly in a loop.
God forbid. I happen to like adblockers, inspecting app DOM, and applying custom styles and features with browser extensions. I can customize even poorly-built web apps like Youtube and Facebook with enough poking around and custom selectors. It's great.
Don't bring native UX sensibilities to the web, or we'll retaliate by pushing Electron even harder for cross-platform native development. And yes, that is a threat. ;)
Every time this conversation comes up, I make the same point: the DOM is not a layout tool, the DOM is a user interface. The DOM forces you to give your users a pure-text representation of your current state -- it forces you to think of your current state as an XML-like data object before it allows you to think in visual terms. That's the point: your user interface is XML, not pixels.
Imagine if every native GTK app forced you to come up with a universal text interface that worked in terminals before it would let you add any of the weird keyboard handlers and unresponsive layouts and HDPI-unfriendly menus on top of it. That is how the web do.
This is weirdly lost on HNers every time this "debate" comes up.
Native apps are the wet dream of any website they complain about for having too many trackers and ads and data exfiltration.
The web browser is a fluke of history that gives users power that we don't have with native apps. Let's not be so quick to give it up just because you've never mitmproxy'd your phone to see what it's doing.
That is why I stopped consuming Reddit, Twitter, and Facebook - they aggressively push their shitty battery consuming apps that I don't want to use.
Nothing about TFA indicates that its author is a React apologist. Do those even exist anymore?
Google Sheets has used canvas for rendering for years.
Maybe reinventing the whole damn car on canvas isn’t a great idea either. I bet that the keyboard isn’t the only part that doesn’t work.
Flash was hated for this reason too: Breaking affordances. Imagine everyone reinventing their own UI framework on each app.
I don't like this argument. It's like saying that because C++ can do everything, we don't need to build a new language to fix problems inherent with the existing paradigm.
Rust is just getting started, so give it time.
DOM is overloaded, messy, and slow. We need an application UI toolkit similar to what Android and iOS provide.
The problem is that by the time you've finished building a WebGL layer that has the same accessibility features and component-level controls and custom shortcut support and extension APIs as the DOM, it will no longer be a snappy, fun, fast experience. What you'll end up with is a second implementation of a web browser that runs on top of a web browser, and that has to be downloaded fresh every time you visit a new website.
WebGL and Canvas frameworks are fast because they allow you to build an interface that does fewer things -- that only worries about pushing pixels to the screen. They allow you to avoid adding the overhead of app-agnostic universal UI components with predictable behaviors, or accessibility layers, or custom font support, or universal shortcuts for scaling, or responsive layout support.
And sometimes you don't need that stuff. Sometimes you do only care about pushing pixels to the screen, or you're doing something very specific that allows you to avoid thinking about edge cases. But if you're going to universally replace the DOM, then you do need to care about edge cases.
Keep in mind, Firefox is also running in C/Rust and rendering webpages using OpenGL. It's operating on the same bare-metal layer. The DOM is already written in low-level languages and rendered out with OpenGL. It's not slower than Canvas because they used the wrong tech stack, it's slower than Canvas because it does more stuff.
I'm very excited about WASM as a replacement for Javascript. And to their credit, that's what the Rust team is doing. For the most part, the direction that Rust is actually going isn't towards WebGL, it's towards getting good DOM access in WASM.
The future of Rust/WASM mostly looks like people writing code in the language of their choice, with speed improvements based on the fact that the language isn't high-level or garbage collected, and then using that faster, more comfortable language to manipulate the DOM, just like we always have.
Apart from "apologist" not really being a term conducive to constructive discussion, I think, the author is also the author of one of the main competitors to React (Svelte), and has often and strongly criticised it. (Which is not to say that he hates it, but just to point out that "apologist" isn't really correct, and thus that it could be that the article is triggering some defensive reflexes that might not be entirely justified.)
Quite the contrary.
The author has criticized React openly _many_ times.
He is also the creator of Svelte which mainly aims to reduce the amount of JavaScript web apps are using compared to React, jQuery, etc.
My take is, however, that the web as we know it is going to be split in apps and websites.
Sites is stuff that works fine with an 'old classy' request->response method, stuff like blogs, newssites, wikis, information sites, simple booking sites etc. You can make a great living just doing that. Probably most content available on the web will fit in this category. However I think Wordpress and similar frameworks / libraries will continue to dominate this field.
Apps is stuff where you practically need a SPA, where there is no choice. Things like music players, photo editors, file managers, chat applications etc.
Old mom n pop shops will still be around and never need a SPA, but a lot of applications being ported to the web do need it. If you do old style websites, there is nothing wrong with that and it still works fine for a lot of stuff. But if offline capability is a requirement (as an example), it is very hard to make a compelling case without making a SPA.
I like both, I find the old style apps to be a lot quicker to develop but the SPA, PWA style app gives the user a much native feel which is important for a lot of apps.
The modern web delivers some of that, but only accidentally. The modern web is all about delivering potential malware to me and expecting me to run megabytes and gigabytes of this code, all in order to … display pictures and text, something the browser has been capable of for over twenty years.
Now compare that to the rest of software where you don't have that control and you'll see software has always been in the state of your hyperbole about pushing malware to your machine that can always be making http requests that you can't see.
It's a bit sad that even technical people are only waking up to this when it comes to the web because they can finally see it with the browser's network tab, so they think it's just a web problem and begin advocating for throwing the baby out.
What? The solution to making a website fast is to crunch analytics (presumably on the client and in JS, all of which has to be loaded beforehand for this to work) and then try to predict what the user is going to do on the website, anticipate it, and start loading, even when it might go waste?
Wastage of network bandwidth aside, Speculative Execution destroyed the chip performance in the last two years and opened up a whole lot of scary security holes, some of which may never be fully patched without performance hits. And the bright idea is to do that in the browser?
> I believe Gatsby will pre-load any link that's visible in the viewport by default$
If it does that, then no wonder that the original article was completely right. On a page with 10 visible links in the viewport, I will only navigate to one or maybe I won't navigate. Then why the hell is my battery, network bandwidth, etc is being used for it what is essentially 90% wastage?
In these discussions, I find defendants of these SPA designs to almost always point to vague points about "rich UI" or "highly interactive", or make up complete hypotheticals like this example of pre-loading likely-to-be-clicked links. Show me the code. Show me the crazy-fast link-click-predicting website that does this and loads faster than, say, HackerNews.
It's good to see the pendulum swinging back to some semblance of sanity on this topic. The past ~5-10 years of the SPA being the default choice has been a wild time. I couldn't be happier that it's starting to receive some widespread criticism.
https://hn.svelte.dev/ is a Sapper implementation of Hacker News. It uses the preload-on-hover/touch technique described in the article. In my experience it does indeed feel faster than Hacker News, despite basically being something I threw together one weekend
Which debunks one of the critical advantages of an SPA.
The other is transitions. Which are never implemented because it's just too damn hard. Instead you get a spinner, 17 API requests (instead of 1 Ajax request), and a giant fragment of the DOM replaced whilst you lose your scroll position.
Being able be assured that you can find/hire folks to work on your tech stack is a pretty important concern for a business. Thus, it can make sense to go with a popular framework/language because it can help in that regard.
I think it's a shame that frontend web developers have thrown themselves behind the SPA paradigm so hard that the notion of a JavaScript ecosystem that doesn't try to do pull _everything_ into its own domain is unimaginable. I'd love to see more mindshare go towards building libraries that are drop-in/"just add water" progressive enhancements for static sites.
[edit: minor grammar correction]
Are you thinking something like ShareDB? https://github.com/share/sharedb
As a person who is browsing the web, I do want server rendered pages, correct history of navigation, urls to match pages, a lack of refreshes, live collaboration with other users. What I dont want is a manual refresh to lose anything or bring me to a different page. And I want the site to work, and progressively fail if I have javascript off.
Most interactivity can still be server side. Look at google.com, as you type in a search query, and they return a static update with results matching what youve typed so far.
Ah - I didn't have anything quite that powerful in mind, more like fairly simple, browser-local enhancements to make interacting with regular old HTML pages more pleasant. For example a drop-in library that would save the state of a form and restore it on a refresh, like the old formsaver jQuery plugin. I would like to see an ecosystem of libraries like that again
Sounds like jQuery plugins.
Seriously though, I wish for a similar thing without the baggage. Maybe there needs to be a common interface defined for such "just add water" libraries.
I've long ago abandoned spaghetti mega-scripts and SPAs in favor of targeted JS libraries that extend HTML capabilities. They're not web components, they don't require some framework to manage, and my HTML works fine without them, but if I load the library and add certain attributes or tags to my markup, I get extra capabilities. The libraries don't require crazy tooling to manage, don't have extensive dependencies and so they facilitate steady incremental development.
I'm very happy with this approach and I'm reusing code I've written years ago for completely different projects.
Do you mean libraries like Turbolinks[1] and/or Intercooler[2] here? I'm interested in what libraries you use, and others like these which help "bridge the gap" between traditional and single-page sites.
[1] https://github.com/turbolinks/turbolinks [2] https://intercoolerjs.org/
[1] https://unpoly.com/ [2] https://www.morling.dev/blog/quarkus-qute-test-ride/
I'm a fan of these kinds of solutions. For my 100% static website, https://instant.page does make it feel instant. TurboLinks feels a little "heavier" and has a more complex interaction with other frontend code, but it works very well.
IIRC there were some old packages but these were unmaintained and didn't work with later versions of Turbolinks, so I ended up looking at Rails source and other examples. Basically making sure to handle redirects and headers correctly. You can see the webpack config in the same project, pretty much just standard setup with some tweaks for loading Stimulus controllers.
https://github.com/derbyjs/derby
https://github.com/derbyjs/racer
https://github.com/share/sharedb
https://derbyjs.com/
Sure, you can do this with AJAX, but so far there are no SSR + component-level hydration + AJAX frameworks that solve this out of the box.
Facebook is working on something similar though as Dan Abramov has hinted at on Twitter.
But if you have any amount of interactivity (forms, widgets, etc) SSR makes total sense. Specially with component-level hydration which means the duplication of content would be lower than traditional SSR. AFAIK Marko is the only framework that has this feature.
See this article for more info on this topic:
https://medium.com/@mlrawlings/maybe-you-dont-need-that-spa-...
Rich seems to be advocating for a JS middle-ground here, which I think is a great direction to go in for this kind of workflow.
Not everything is an app, and frankly I think we build a lot of non-apps as if they are apps because we enjoy the feeling that we've engineered something.
This is similar to other articles I've seen that draw a distinction between two choices: zero javascript vs full SPA. I think this is a false dichotomoy because most features advertised for SPAs (analytics, data/content preloading, transitions, optimized page loading) can be implemented for static sites as well. It would be nice to see frameworks that were more modular and interoperable because this would allow/give engineers the choice to decide which parts they want to be static and which parts they want to be dynamic.
I'm not sure if I agree with what you're saying though because you haven't provided examples of how the features of SPAs can be accomplished without JavaScript. Do you have references and examples?
SPAs are newer, so they must be better, right? /s
I'd like "web programming" to start with Vannevar Bush's As We May Think, then go to Licklider, Ted Nelson, then hypercard programming (hypertalk). Set up a BBS, a gopher site and then write HTML for NCSA Mosaic.
Read the RFCs and W3C standards, learn about Netscape's SSJS failure before touching nodejs, you know, serious academic scholarship. Maybe look at the failed TCL browser support, which has example snippets in the HTML 4 standard, understand why it didn't work, etc.
I think we'd get dramatically better results
And JavaScript has laid claim to that throne which was once primarily contested by enterprise Java and .Net.
Some project starts and they decide to use an uncessarily complex framework (which may be well engineered for the cases it was developed for at the Facebook/Google scales of the world) then grab 3 more and glue them together using poor practices, then proceed to build all sorts of complexity ontop of that stack using poor engineering and typically non-standard practices.
New people join and voila, they immediately need to understand these 3-4 underlying complex yet well engineered systems and how they are poorly glued together before they can even begin to unravel the poor engineering practices that sit ontop of them so they can fix and extend them.
Parts of the application look well structured, other parts are incredibly confusing. Suddenly you need to go back and better understand some of the underlying frameworks leveraged so you can actually discern what's supposed to be going on which takes forever because that underlying framework is quite complex in and of itself.
In the end you're running around documentation page to documentation page from frameworks and looking at undocumented code someone wrote in between, consuming stupid amounts of time.
Someone built a big pile of technical debt and you just inherited it. Good luck, they've switched to another team, project, or employer and moved on before the mess unfolded.
Meanwhile, you're wondering why 90% of this exists for a product feedback submission form.
It seems that page transitions really are the main reason given for using JavaScript-everything for sites and simple applications that otherwise could have been built with some fast loading HTML and a couple of POST forms.
A good example are sophisticated forms with realtime validation, dynamic fields that depend on other fields, etc.
But let's look into the point made by the author regarding the inspiring example of Apple's app store UX, and trying to aim for that.
We, meaning as an industry average, will not achieve that level of UX no matter the stack. Because nobody can afford it. It requires a team of top designers, interaction engineers, dev, QA, etc.
That's the problem with the SC valley mindset. They assume every web property has this huge team of top engineers behind them, and that this is a status quo, and applies to the whole web.
They have no idea what bubble they are in.
No, it's not. It's easy and you can do all that without an SPA framework. If you can't see this in about 5 seconds, you shouldn't be lecturing other about how to design websites.
Preloading hovered links can be done with a standalone library. AJAX can be done with another a standalone library. Removing extra crap from your page to facilitate faster AJAX can be done with a custom request header and a couple if-else statements on the server side. Best of all, this stuff can be added after you have a working website.
Couldn't it even be done in two lines with vanilla javascript? On hover fetch() the URL, then rely on the browser cache for when the user actually clicks?
How many sites actually do this? And how much additional bandwidth (and battery life for mobile devices) does doing this consume?
> We can provide better visual feedback that loading is taking place and a transition is about to occur. And we don't need to load the entire contents of the page — often, we can make do with a small bit of JSON because we already have the JavaScript for the page.
In my experience sites that do this are almost universally slower and less responsive than sites that just use normal links. Maybe that's just confirmation bias and I just don't notice it as much on sites that do it well, but a particularly egregious example of this is Reddit's current mobile site vs their old i.reddit.com mobile site (which I use exclusively (despite it missing a number of newer features and having a lot of minor bugs the newer site doesn't) because it's way way faster).
Yup. A car analogy: "Instead of waiting for the driver to turn the steering wheel before causing the car to turn, we put the car on the back of a flatbed truck that tracks driver behaviour and tries to predict their intent. Then we can start turning the flatbed truck a little bit sooner to improve user experience."
This seems to me to be the key phrase.
I sympathize with all the "JS has gone too far" people in this thread. I also hate bloated JS apps. But, "almost all SPAs are bloated trash" is a distinct claim from "SPAs are intrinsically trash".
In my experience it is possible to have lean, high-performance, accessible SPAs without too much developer difficulty. Svelte (created by the author of this article) is one framework in this space, although I think there are better approaches.
Do you investigate all the fast snappy sites you visit to confirm they aren't single page apps? What about the slow pages that aren't SPAs (most every news site)?
It seems like anyone who wants to dislike JS and/or SPAs can easily confirmation-bias their way into believing it.
Anyway, for fast SPAs, here is a useful comparison: the "RealWorld app" demo.
I would urge everyone to look at the Lighthouse audits for these three implementations:
React/Redux: https://react-redux.realworld.io/
Angular: https://angular.realworld.io/
Vue: https://vue-vuex-realworld.netlify.app/#/
Svelte/Sapper: https://realworld.svelte.dev/
Solid.js: https://ryansolid.github.io/solid-realworld/
This is just a demo, of course, but it is close enough to be representative. From just this simple demo we can already see significant differences: Svelte and Solid.js are much snappier. The author of the article, Rich, created Svelte.
Of course, this is just talking about performance, not yet getting accessibility, navigation, transitions, etc right.
The simple question as to where are all these inspiring SPAs that truly push the web to next levels...is completely unanswered.
We get docs sites, demos and blogs. Where when clicking on a link...wow!...it loads without a page refresh. Something possible using simple ajax some 15 years ago.
It's not a perfect parallel, but this reminds me of systems like Qt Designer, or Apple's Interface Builder/Storyboard, or Android's XML layout system. Those systems all essentially give you an "initial render" made with one technology (XML files created in some sort of visual GUI-builder program) and "subsequent interactions" made with another (C++/Swift/Java code).
In native apps, I'm a sucker for pretty transition animations, and I'd love to see those on the web.
But, every website I've ever seen with those types of fancy transitions for large pieces of content (as opposed to little on-page microinteractions) also feels slow, clunky, and heavy. As such, I've come to associate such transitions with slow, clunky and heavy web pages.
I'm not really a web developer, so feel free to tell me if everything that follows is stupid: It seems unlikely that our "current trajectory" can ever resolve this problem. Instead, we'd need an underlying technological shift in how browsers work.
Most large transitions are basically browser hacks—albeit ones we've used so frequently, and for such a long time, that they've come to be officially supported and accepted. To make them more usable, they'd probably need to work alongside the browser in some manner.
SPA tech is a good thing for web sites that have little appy parts (like checkout processes, or maps). I'm not saying for the entire website, but just little focused parts. Can you imagine going back to (the old) Yahoo Maps now that Google Maps exists?
Are SPAs good for entire websites (like the new reddit?) Personally I like the new reddit over old reddit. But this is where your users are highly relevant. If you don't listen and choose SPA for millions of users of the public, you will probably get Feedback. You might be lucky and only 10% hate it, but it might explode in your face if that's a key 10% that encompasses influencers.
SPA as the status quo is a myth. It's a Fermi paradox. Where are they? Almost nothing of any importance is an SPA. You'd think that if they have such superior experience, they lead to superior business metrics, thus they are everywhere. Asides from true app-like experiences like Gmail, Spotify, the like, they're nowhere to be found. Not in places of significance. It's 2020 and Amazon continues to be old school page refreshes. Last time I checked they're doing quite OK. Even big parts of Facebook, the poster child of complex interactivity, continues to do full page refreshes in big parts of the experience.
Instead, SPAs are a startup default, not a web default. Big difference. And the way most are implemented, they don't live up to their potential benefits, instead deliver UX that is even worse than static:
- breaking back buttons - breaking scrollbars - rendering things that aren't interactive
These things don't have to occur, they can be solved in an SPA, but they do occur a lot in the wild. This matters. We live in the real world.
As somebody else here already mentioned, the article takes a completely wrong approach. It assumes some binary choice or outcome. The original point instead was that the web is not a single thing. It's a huge thing where different stacks are to be used for different use cases. This point is largely ignored, instead it is implied that SPAs should simply solve such use cases better, whilst continuing to be a default.
On the particular point of SPA links being typically faster/smarter: there's about 500 drop-in solutions to speed up static links. Which are usually not needed, because the point of such links being bad is overstated and lacks any user evidence. See my earlier remark on virtually all major websites using plain old links. They wouldn't if it was so bad.
Finally, a huge part lacking in this discussion is the accessibility of web development itself. The SPA web is an engineers web, it requires advanced programming skills, infrastructure, increasingly complex tools chains, and so on. If this was to be a true default (luckily it isn't), it would lock out the vast majority of people wanting to contribute to the web.
It's sad to see this sub culture of hardcore engineers with Macbook Pros thinking they own or represent the web or web development.
Some images on the web are poorly optimized, but that doesn't mean we should not have images.
The whole point of a SPA is to give a user a better experience. If on average this does not materialize in the real world, and often achieves the exact opposite, the entire concept fails.
Bad SPA implementations are the standard. Saying that it's possible to make a good SPA implementation doesn't change the real world outcome that most often, they don't deliver.
Many SPA developers rapidly move from project to project. Every once in a while, they learn yet another JS framework, and then hop between jobs to use that.
They never look back. They never truly need to take responsibility for a tech choice.
Try to hire an Angular 1 developer to work on 300K lines of code today. You can't. No skilled front-end developer would take on such a job with options to work on hotter tech.
Any SPA choice you make today will be completely obsolete in 3-5 years. 3-5 years, or even 10 years or more, is a normal life cycle for a serious web property. And not just obsolete, you'd have the hardest time getting the tool chain to still work at all.
The original developers don't care, they using tech N+5 now, somewhere else. They'll be very vocal how N+5 is vastly better than anything else, and really the only option for "the modern web".
Angular becomes a front-end COBOL in just a few years, not 3 or 4 decades.
There's more. A typical front-end architecture depends on a complex interwoven tool chain with a lifespan of at best years, sometimes even months.
Same for modules. It's normalized to have an absurd dependency tree of hundreds to thousands of inter-depending modules. The vast majority of which will be abandoned in a few years.
I used to think it was an oversimplification to divide the web into Documents and Applications. I thought it was more accurate to say it was a continuum, and using two different techniques was a sign that we still had not figured it out. After all, a blog post about programming might have an interactive example. An article about retirement might embed a calculator. If you try to categorize a site or even just a page as Document or Application, it gets fuzzy. But if you look at a page and just try to categorize it section by section, as Document or Application, it's easier. (Hence, Web Components make more sense to me.)
So anyway, most people spend some time surfing the web --- by that I mean visiting Documents. Clicking links from search results, to articles, to more articles. If you aren't using an adblocker, I can't imagine how you don't end up throwing your laptop against the wall. I ended up just turning off JavaScript for most sites, and the web looks more like how I think it should look. Every once in a while these people will post a rant, and it will resonate with most people.
But then an Application Developer will read it after a long day and say, hey, wait are you saying I should write my Application (like GMail) in jQuery? To be honest, Applications don't bother me the way overscripted Documents do. I almost expect them to be kind of slow. After all, even some Desktop Applications still have loading screens. So I don't mind so much if you're using React or whatever for your Application or even for that calculator embedded in the article about savings.
But for Documents --- like articles, blog posts, company home pages --- well, one thing I agree with SPA developers is that there could be less server-side rendering. These kinds of sites could often be compiled ahead of time into static HTML. Server-side rendering is better than SPA for these kinds of sites, but static sites are better than server side. I mean, who enjoys getting "Error connecting to MySQL database"? (Okay, that's rare.) I'm intrigued by the old-new JAM Stack :)