20 ms·

In Defense of the Modern Web

217 points by jdkoeck 6y ago

fenwick67 6y ago
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.
- jaywalk 6y ago
  A full-page refresh when I vote on a comment would be jarring. That's what he's saying.
  - timw4mail 6y ago
    If it works without JS enabled that way, but works the current way with JavaScript, what's the problem?
    - ss3000 6y ago
      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.
      - giantrobot 6y ago
        Everyone has JavaScript disabled sometimes. https://kryogenix.org/code/browser/everyonehasjs.html https://kryogenix.org/code/browser/everyonehasjs.html
  - rich_harris 6y ago
    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.
    - zozbot234 6y ago
      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.
      - rich_harris 6y ago
        > 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.
        quantummkv 6y ago
        > 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.
        Vinnl 6y ago
        > 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.
- coffeefirst 6y ago
  Yeah, I don't get that at all. Especially if you can make the next page really fast. I'm also kind of gawking at the screencast he uses as an example: https://twitter.com/ryanflorence/status/1186675229621248000 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?
  - ssivark 6y ago
    It seems more oriented to browsing/scanning, and particularly nice for that IMHO. What would be a baseline for comparison?
- deleted 6y ago
  [deleted]
- amw-zero 6y ago
  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.
  - fenwick67 6y ago
    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.
    - amw-zero 6y ago
      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.
  - MayeulC 6y ago
    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.
- Spivak 6y ago
  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.
- subpixel 6y ago
  I agree, and moreover I find the native app animated transitions held up as the end-goal to be nothing short of awful.
- turnipla 6y ago
  It depends. Neat short animations can be nice. Even your lightbulb “dimming in” and out would be quite nice. What you’re complaining about is the lightbulb taking 3 seconds to turn off and its toggle costing $100. Now that something nobody likes.
karatestomp 6y ago
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.
grey-area 6y ago
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.
- speedgoose 6y ago
  The web is not only html documents rendered server-side though. You need much more advanced interactions.
  - timw4mail 6y ago
    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.
    - speedgoose 6y ago
      Even HN would have a poor usability with only server side rendering.
      - timw4mail 6y ago
        Sure, but it's much leaner because it only uses JavaScript when it is necessary.
      - grey-area 6y ago
        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).
timw4mail 6y ago
I think one nuance is lost on both articles: web-development is generally stuck in a system where all the incentives are wrong. - 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.
- duxup 6y ago
  I think that first item is true about ... a lot of careers. Resume driven development isn't an exclusively web thing.
  - karatestomp 6y ago
    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.
- clarry 6y ago
  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.
echelon 6y ago
> 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. [1] http://makepad.nl/ http://makepad.nl/
- timw4mail 6y ago
  I don't think the DOM is the bottleneck as much as JavaScript is.
  - realharo 6y ago
    Based on what?
    - timw4mail 6y ago
      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.
  - deleted 6y ago
    [deleted]
theandrewbailey 6y ago
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.
ecmascript 6y ago
Interesting take and I kind of agree. 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.
- tenaciousDaniel 6y ago
  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.
  - giantrobot 6y ago
    `<canvas>`
    - tenaciousDaniel 6y ago
      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.
zeveb 6y ago
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.
- hombre_fatal 6y ago
  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.
cocktailpeanuts 6y ago
What we have today is a POST modernism web. Nothing about it is modern.
quantummkv 6y ago
> 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?
- frosted-flakes 6y ago
  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$
  - quantummkv 6y ago
    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?
- the_gastropod 6y ago
  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.
adamsea 6y ago
It’s easier to hire javascript developers, no? Even if it’s not the most efficient.
- adamsea 6y ago
  For more context, what I was thinking was: 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.
filleduchaos 6y ago
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. [edit: minor grammar correction]
- basch 6y ago
  Right? Are you thinking something like ShareDB? https://github.com/share/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.
  - filleduchaos 6y ago
    > Are you thinking something like ShareDB? https://github.com/share/sharedb https://github.com/share/sharedb 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
- trashburger 6y ago
factorialboy 6y ago
The criticism isn't directed towards technology X or platform Y. The target is over-engineering. And JavaScript has laid claim to that throne which was once primarily contested by enterprise Java and .Net.
- Frost1x 6y ago
  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.
buboard 6y ago
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.
simonw 6y ago
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.
- tylerchilds 6y ago
  And worth noting React's implemention of vdom is at odds with smooth page transitions, since unmounting components are immediately removed from the DOM.
- pier25 6y ago
  IMO the main reason for using React, Vue, or Svelte is not SPA but having sophisticated interactivity with better DX than using jQuery. A good example are sophisticated forms with realtime validation, dynamic fields that depend on other fields, etc.
- anderspitman 6y ago
  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.
- fleddr 6y ago
  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. They have no idea what bubble they are in.
- detaro 6y ago
gambler 6y ago
>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.
- Izkata 6y ago
  > 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?
  - Spivak 6y ago
    And isn't this what browsers do already with prefetch?
MrRadar 6y ago
> 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).
- AlexandrB 6y ago
  > 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."
- Isomorpheus 6y ago
  > 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.
csande17 6y 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).
Wowfunhappy 6y ago
> 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.
- ric2b 6y ago
  That's probably because those animations are made with JS in the main thread, so the whole thing becomes unresponsive while they happen.
coding123 6y ago
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.
thejynxed 6y ago
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.
fleddr 6y ago
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.
- robertoandred 6y ago
  The idea that some bad implementations of an idea serve as an indictment of the idea as a whole is utterly ridiculous. Some images on the web are poorly optimized, but that doesn't mean we should not have images.
fleddr 6y ago
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".
- eximius 6y ago
  This is just the COBOL problem in newer clothes. Raise the pay and someone will decide it's worth their time.
  - fleddr 6y ago
    Sure, but timelines are different. 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.
deleted 6y ago
[deleted]
combatentropy 6y ago
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 :)
deleted 6y ago
[deleted]
revskill 6y ago
I think SPA is just one of results created by libraries/frameworks like React, Vue,.... Those things were created not to produce SPA (we can do with vanilla JS), it's for modularization and componentation. Or we can say, they are implementations on how to achieve the same thing. The difference is performance.
anderspitman 6y ago
I don't have a problem with the "modern web". I love all the new technologies. But I think we should re-split the document web from the application web. A huge percentage of web content can be implemented with a subset of HTML and CSS. A browser that implemented a few semantic tags (including <img> and <video>), fonts, colors, and flexbox would be useful, secure, fast (even on slow devices/connections), and far easier to implement than the behemoths we have now. Let the application web keep evolving, but specify a well-defined subset for sites that don't need all the features.
cptskippy 6y ago
I'm having a hard time comprehending this mindset. According to this article we should accept: - Heavy sites that take a long time to load initially. - Are sluggish and unresponsive when not on this year's flagship phone. - Will probably break if the user leaves a tab open for too long. Because: - There's an opportunity to shave a fraction of a second off of your page load times if you want to utilize predictive analytics or extensive preloading to ensure the content request is already loaded in cache. The modern web is just layers upon layers of hacks and it's ugly and slow. I would recommend to anyone who disagrees to install the NoScript Add-on and run with it for 6 months. I did so and here's some things I've observed... When I enabled NoScript: - Most sites do not work without some Javascript that's been used to address Page reflow. They have a global display:none attribute that's removed after the entire page has loaded. All this discussion about page load times or responsiveness is BS when sites are hiding their site from you until it completely loads to avoid reflow. - Most sites rely heavily on Javascript to do basic formatting that's trivial in CSS. - Most sites use Webfonts loaded via Javascript When I disabled NoScript: - My Phone went from 60% battery at the end of the day to <20%. - The Web is slow again. - User hostile behavior like pop overs, auto-play video, and other garbage.
- rich_harris 6y ago
  > According to this article we should accept Well, I wrote the article, so I can say with some authority that you've badly misinterpreted it! Somehow I manage to build sites with exceptional performance that are snappier than the equivalent JS-free sites, using the techniques I talk about (and https://svelte.dev https://svelte.dev). Yes, there are a lot of bad sites out there that abuse JavaScript. No, that doesn't invalidate the article's thesis; it supports it.
  - cptskippy 6y ago
    > Well, I wrote the article, so I can say with some authority that you've badly misinterpreted it! Perhaps but point from Tom MacWright's article is that we're over complicating simple things (e.g blogs) with complicated and heavy libraries and frameworks. Then when we encounter performance issues we attempt to mitigate them by layering on additional crap or spending significant time optimizing the crap out of needless complexity. Your suggestion that full page loads are unnecessarily slow and cumbersome and that we can use predictive analytics, preloading and a slew of other techniques to get a faster response to a page load is the equivalent of building a Rube Goldberg machine to turn the page of a book "that much faster". Sure your techniques address one metric (i.e. response time) but they introduce all manner of other problems that then need to then be solved. For what? > Somehow I manage to build sites with exceptional performance that are snappier than the equivalent JS-free sites. Somehow you manage demonstrate that you completely misunderstood what Tom MacWright was saying. Back to my page turning analogy, I have no doubt someone could build a machine to turn the pages of a book "better" than I can. Does that mean everyone should have this miraculous page turning machine? At the end of the day my local pizzeria doesn't need a multi-megabyte SPA application utilizing client side ML and predictive analytics for me to get the phone number so I can call in an order, but that's the modern web.
luord 6y ago
Interesting that he agrees with the point of the original article I disagree with the most, the one on APIs. Maybe I'm wrong... Speaking of which... > 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. I'm not aware of the backend, the server side of many mobile application being written in kotlin (or java) or swift. In fact, it's common for the server and the client to be written in different technologies. Yes, I know that's not exactly what he means and in a native application, the application is in charge of the initial render. But he's criticizing APIs and I don't see how this statement can be possible without APIs unless he expects the backend to be in the same technology. Which, again, is not unusual for it not to be so.

217 points by jdkoeck 6y ago

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.

jaywalk 6y ago
A full-page refresh when I vote on a comment would be jarring. That's what he's saying.
- timw4mail 6y ago
  If it works without JS enabled that way, but works the current way with JavaScript, what's the problem?
  - ss3000 6y ago
    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.
    - giantrobot 6y ago
      Everyone has JavaScript disabled sometimes. https://kryogenix.org/code/browser/everyonehasjs.html https://kryogenix.org/code/browser/everyonehasjs.html
- rich_harris 6y ago
  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.
  - zozbot234 6y ago
    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.
    - rich_harris 6y ago
      > 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.
      - quantummkv 6y ago
        > 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.
        Vinnl 6y ago
        > 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.
coffeefirst 6y ago
Yeah, I don't get that at all. Especially if you can make the next page really fast. I'm also kind of gawking at the screencast he uses as an example: https://twitter.com/ryanflorence/status/1186675229621248000 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?
- ssivark 6y ago
  It seems more oriented to browsing/scanning, and particularly nice for that IMHO. What would be a baseline for comparison?
deleted 6y ago
[deleted]
amw-zero 6y ago
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.
- fenwick67 6y ago
  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.
  - amw-zero 6y ago
    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.
- MayeulC 6y ago
  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.
Spivak 6y ago
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.
subpixel 6y ago
I agree, and moreover I find the native app animated transitions held up as the end-goal to be nothing short of awful.
turnipla 6y ago
It depends. Neat short animations can be nice. Even your lightbulb “dimming in” and out would be quite nice. What you’re complaining about is the lightbulb taking 3 seconds to turn off and its toggle costing $100. Now that something nobody likes.

karatestomp 6y ago

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.

grey-area 6y ago

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.

speedgoose 6y ago
The web is not only html documents rendered server-side though. You need much more advanced interactions.
- timw4mail 6y ago
  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.
  - speedgoose 6y ago
    Even HN would have a poor usability with only server side rendering.
    - timw4mail 6y ago
      Sure, but it's much leaner because it only uses JavaScript when it is necessary.
    - grey-area 6y ago
      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).

timw4mail 6y ago

I think one nuance is lost on both articles: web-development is generally stuck in a system where all the incentives are wrong. - 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.

duxup 6y ago
I think that first item is true about ... a lot of careers. Resume driven development isn't an exclusively web thing.
- karatestomp 6y ago
  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.
clarry 6y ago
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.

echelon 6y ago

> 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. [1] http://makepad.nl/ http://makepad.nl/

timw4mail 6y ago
I don't think the DOM is the bottleneck as much as JavaScript is.
- realharo 6y ago
  Based on what?
  - timw4mail 6y ago
    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.
- deleted 6y ago
  [deleted]

theandrewbailey 6y ago

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.

ecmascript 6y ago

Interesting take and I kind of agree. 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.

tenaciousDaniel 6y ago
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.
- giantrobot 6y ago
  `<canvas>`
  - tenaciousDaniel 6y ago
    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.

zeveb 6y ago

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.

hombre_fatal 6y ago
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.

cocktailpeanuts 6y ago

What we have today is a POST modernism web. Nothing about it is modern.

quantummkv 6y ago

> 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?

frosted-flakes 6y ago
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$
- quantummkv 6y ago
  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?
the_gastropod 6y ago
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.

adamsea 6y ago

It’s easier to hire javascript developers, no? Even if it’s not the most efficient.

adamsea 6y ago
For more context, what I was thinking was: 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.

filleduchaos 6y ago

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. [edit: minor grammar correction]

basch 6y ago
Right? Are you thinking something like ShareDB? https://github.com/share/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.
- filleduchaos 6y ago
  > Are you thinking something like ShareDB? https://github.com/share/sharedb https://github.com/share/sharedb 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
trashburger 6y ago

factorialboy 6y ago

The criticism isn't directed towards technology X or platform Y. The target is over-engineering. And JavaScript has laid claim to that throne which was once primarily contested by enterprise Java and .Net.

Frost1x 6y ago
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.

buboard 6y ago

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.

simonw 6y ago

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.

tylerchilds 6y ago
And worth noting React's implemention of vdom is at odds with smooth page transitions, since unmounting components are immediately removed from the DOM.
pier25 6y ago
IMO the main reason for using React, Vue, or Svelte is not SPA but having sophisticated interactivity with better DX than using jQuery. A good example are sophisticated forms with realtime validation, dynamic fields that depend on other fields, etc.
anderspitman 6y ago
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.
fleddr 6y ago
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. They have no idea what bubble they are in.
detaro 6y ago

gambler 6y ago

>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.

Izkata 6y ago
> 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?
- Spivak 6y ago
  And isn't this what browsers do already with prefetch?

MrRadar 6y ago

> 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).

AlexandrB 6y ago
> 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."
Isomorpheus 6y ago
> 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.

csande17 6y 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).

Wowfunhappy 6y ago

> 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.

ric2b 6y ago
That's probably because those animations are made with JS in the main thread, so the whole thing becomes unresponsive while they happen.

coding123 6y ago

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.

thejynxed 6y ago

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.

fleddr 6y ago

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.

robertoandred 6y ago
The idea that some bad implementations of an idea serve as an indictment of the idea as a whole is utterly ridiculous. Some images on the web are poorly optimized, but that doesn't mean we should not have images.

fleddr 6y ago

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".

eximius 6y ago
This is just the COBOL problem in newer clothes. Raise the pay and someone will decide it's worth their time.
- fleddr 6y ago
  Sure, but timelines are different. 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.

deleted 6y ago

[deleted]

combatentropy 6y ago

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 :)

deleted 6y ago

[deleted]

revskill 6y ago

I think SPA is just one of results created by libraries/frameworks like React, Vue,.... Those things were created not to produce SPA (we can do with vanilla JS), it's for modularization and componentation. Or we can say, they are implementations on how to achieve the same thing. The difference is performance.

anderspitman 6y ago

I don't have a problem with the "modern web". I love all the new technologies. But I think we should re-split the document web from the application web. A huge percentage of web content can be implemented with a subset of HTML and CSS. A browser that implemented a few semantic tags (including <img> and <video>), fonts, colors, and flexbox would be useful, secure, fast (even on slow devices/connections), and far easier to implement than the behemoths we have now. Let the application web keep evolving, but specify a well-defined subset for sites that don't need all the features.

cptskippy 6y ago

I'm having a hard time comprehending this mindset. According to this article we should accept: - Heavy sites that take a long time to load initially. - Are sluggish and unresponsive when not on this year's flagship phone. - Will probably break if the user leaves a tab open for too long. Because: - There's an opportunity to shave a fraction of a second off of your page load times if you want to utilize predictive analytics or extensive preloading to ensure the content request is already loaded in cache. The modern web is just layers upon layers of hacks and it's ugly and slow. I would recommend to anyone who disagrees to install the NoScript Add-on and run with it for 6 months. I did so and here's some things I've observed... When I enabled NoScript: - Most sites do not work without some Javascript that's been used to address Page reflow. They have a global display:none attribute that's removed after the entire page has loaded. All this discussion about page load times or responsiveness is BS when sites are hiding their site from you until it completely loads to avoid reflow. - Most sites rely heavily on Javascript to do basic formatting that's trivial in CSS. - Most sites use Webfonts loaded via Javascript When I disabled NoScript: - My Phone went from 60% battery at the end of the day to <20%. - The Web is slow again. - User hostile behavior like pop overs, auto-play video, and other garbage.

rich_harris 6y ago
> According to this article we should accept Well, I wrote the article, so I can say with some authority that you've badly misinterpreted it! Somehow I manage to build sites with exceptional performance that are snappier than the equivalent JS-free sites, using the techniques I talk about (and https://svelte.dev https://svelte.dev). Yes, there are a lot of bad sites out there that abuse JavaScript. No, that doesn't invalidate the article's thesis; it supports it.
- cptskippy 6y ago
  > Well, I wrote the article, so I can say with some authority that you've badly misinterpreted it! Perhaps but point from Tom MacWright's article is that we're over complicating simple things (e.g blogs) with complicated and heavy libraries and frameworks. Then when we encounter performance issues we attempt to mitigate them by layering on additional crap or spending significant time optimizing the crap out of needless complexity. Your suggestion that full page loads are unnecessarily slow and cumbersome and that we can use predictive analytics, preloading and a slew of other techniques to get a faster response to a page load is the equivalent of building a Rube Goldberg machine to turn the page of a book "that much faster". Sure your techniques address one metric (i.e. response time) but they introduce all manner of other problems that then need to then be solved. For what? > Somehow I manage to build sites with exceptional performance that are snappier than the equivalent JS-free sites. Somehow you manage demonstrate that you completely misunderstood what Tom MacWright was saying. Back to my page turning analogy, I have no doubt someone could build a machine to turn the pages of a book "better" than I can. Does that mean everyone should have this miraculous page turning machine? At the end of the day my local pizzeria doesn't need a multi-megabyte SPA application utilizing client side ML and predictive analytics for me to get the phone number so I can call in an order, but that's the modern web.

luord 6y ago

Interesting that he agrees with the point of the original article I disagree with the most, the one on APIs. Maybe I'm wrong... Speaking of which... > 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. I'm not aware of the backend, the server side of many mobile application being written in kotlin (or java) or swift. In fact, it's common for the server and the client to be written in different technologies. Yes, I know that's not exactly what he means and in a native application, the application is in charge of the initial render. But he's criticizing APIs and I don't see how this statement can be possible without APIs unless he expects the backend to be in the same technology. Which, again, is not unusual for it not to be so.