11 ms·

Defaulting on Single Page Applications

122 points by 0xblinq 4y ago

Alifatisk 4y ago
> Single Page Application frameworks in the last few years have pivoted away from client-side rendering to server-rendering and we welcome this improvement. However, the large starting size of client JavaScript bundles customary to SPA persist: Remix (228 kB), Next.js (248 kB), Gatsby (210 kB), and Nuxt (191 kB). Good point, I also think stimulusreflex.com deserves some highlight in this case too. This is where it shines! https://v3-4-docs.docs.stimulusreflex.com/#faster-uis-smaller-downloads-and-longer-battery-life https://v3-4-docs.docs.stimulusreflex.com/#faster-uis-smalle...
benatkin 4y ago
> You can’t JavaScript your way out of an excess-JavaScript problem. These large JavaScript bundles are costly to site performance. I was gonna say: "This is what some Hugo fans might say, but 11ty and Astro suggest otherwise." Then I saw the author of the post is the author of 11ty. Still, the middle ground is being pursued by Svelte and Fresh. I prefer something less frameworky though.
endisneigh 4y ago
The SPA vs server side rendered page debate is so exhausted at this point. The tech is such that they’re nearly equivalent if you have a good team that understands the appropriate technology. You can have an SPA with a proper router that respects page history, loads html fragments from a server, remembers positions on reload, etc. You can also have a server side rendered page sprinkled with JavaScript and use web sockets to create dom element level transitions and interactivity The “MPA” described in the article has always been possible in a “SPA.” It’s more about the UX of your app than anything else
- j45 4y ago
  Exhausted but always new to someone. It's interesting to see technologies like livewire come out that take things back to basics.
- ec109685 4y ago
  Your second paragraph essentially is creating a little mini browser, and you have to make sure to get every detail right or you’re back to the uncanny valley of SPA web pages. Performance can even be worse with SPA “page” navigation if multiple round trips are needed for the data on the next page. SPA’s should be used web apps (think slack or Asana), and stick to sever rendered for web pages.
  - slaymaker1907 4y ago
    I think you've highlighted a big problem with SPAs in that they can encourage multiple API calls per user action. IMO, you should probably have a single endpoint per thing a user might do that might combine several conceptual APIs. i.e., if you have an API to add something to a list, have that API also return the current list.
    - BFLpL0QNek 4y ago
      I see this in most single page apps. They have a waterfall of multiple API requests by the browser to display a single page. That means the front end has a bunch of logic to aggregate and piece together requests. This in itself isn’t a big deal, if you move to doing it on the backend you still have the same logic and need to make the same sub requests. Where it does become problematic is it leads to fat API endpoints sending far more data to the client than is needed. GraphQL lets you choose what fields you query but odds are there’s still data available you can ask for that shouldn’t be asked for and sent to a browser. If your requests/aggregations are done serverside it gives you a better chance of filtering out data that should never be accessible in the browser. You can also make full use of Cache-Control headers and backend caching. Creating individual endpoints for web apps went out of fashion as it involves more effort and people don’t like effort to do things well. I see it re-invented recently as backend-for-frontend.
      - slaymaker1907 4y ago
        Multiple queries from the frontend is still not great because the latency is much higher than doing at the server all else being equal.
- simonw 4y ago
  How do you make sure your SPAs work well with screen readers?
  - endisneigh 4y ago
    More or less the same as a regular page - use aria labels, update names and titles of elements, make sure the focus is set correctly, etc.
    - taeric 4y ago
      And try to be frugal on the tags you make. Component design is the enemy here. Just take a peak at the nav elements in many designs and see how embedded the divs go.
      - sebazzz 4y ago
        Are you referring to styled-components and the like? What is exactly the problem with that?* * except media queries, those seem hard
        zdragnar 4y ago
        Many prebuilt component libraries design for maintenance and all possible uses over being frugal. The actual markup can get really ugly with i.e. MUI. When you put in the effort to build the components yourself, you aren't trying to be everything for everyone, so you get to skip a lot of the cruft.
        taeric 4y ago
        Exactly this. Is a large reason to not try to build the most general components, either. Build what you need, where you can. That all said, I also have to ack that the libraries are going to be hard to beat for speed of delivery. :(
        4y ago
- the_gipsy 4y ago
  > You can have an SPA with a proper router that respects page history, loads html fragments from a server, remembers positions on reload, etc. In theory.
  - Alifatisk 4y ago
    And in practice too?
- benatkin 4y ago
  No, it's not exhausted - people and businesses pushing heavyweight frameworks stand to lose out, and trying to silence the debate would help them. React seems like a bubble to me, created by fancy code that seems good at first glance but doesn't make a huge difference. What's it supposed to be amazing at, simple stuff or complex stuff? If simple stuff then why are people downloading 200K for Hello, World? If for complex stuff why isn't something like VSCode, Monaco, CodeMirror written with React? Those have state galore, and React's one-way data binding is no revelation for them. In fact inside React things like the ironically named react-hook-form get around React's one-way data binding by letting the form inputs be uncontrolled* (ironically named because react hooks makes it sound like it's going with the grain of react when it's thankfully going against it). Maybe ChatGPT will pop the bubble by churning out vanilla js that beats it. :) * https://react-hook-form.com/advanced-usage/#ControlledmixedwithUncontrolledComponents https://react-hook-form.com/advanced-usage/#Controlledmixedw... React Hook Form embraces uncontrolled components but is also compatible with controlled components.
  - endisneigh 4y ago
    There are smaller SPAs like preact or mithril. One could similarly argue that why should you have to use Django to show a user hello world? It really doesn’t matter. Master your tool and most of the supposed downsides can be avoided.
    - benatkin 4y ago
      I have a lot of respect for mithril, they created a tiny vdom that works really well. Though you don't always need one. https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead I have played thousands of bullet chess games on Lichees and is and was very snappy and used to be based on Mithril so it's very battle tested in a literal sense. https://bestofjs.org/projects?tags=vdom https://bestofjs.org/projects?tags=vdom FWIW I disagree that something like virtual DOM can be pure overhead. It is useful to have virtual just about anything. Virtual filesystems for instance.
  - nicoburns 4y ago
    It’s good when you want interactivity that’s technically straightforward but in high volume. It doesn’t work for code editors because they need very close interaction with the DOM, whereas React provides an abstraction layer that covers the common cases.
- simplotek 4y ago
  > (...) they’re nearly equivalent if you have a good team that (...) That's a lot of hand-waving weasel words to blame those experiencing problems for the naturally occurring problems. If it was the same thing, we would not be having discussions on their pros and cons. This is not a team-specific issue.
thrill 4y ago
Quit using these ginormous frameworks and libraries. Vanilla Javascript is all you need.
- graypegg 4y ago
  The organizational and maintainability benefits you get from using something like react far out weigh the actually quite minor file size bump. That is the least of your worries. source: myself; someone who moved to working on a project entirely written in vanilla JS… which has just become its own bespoke framework.
  - WillPostForFood 4y ago
    I agree, but note that we are talking about a benefit that accrues to the developer, not the user.
    - slaymaker1907 4y ago
      It also benefits users in that you can implement more features and fix more bugs in less time. Performance is a feature and what that means is that while you can't just completely ignore it, it's not always the highest priority.
      - bdougherty 4y ago
        > It also benefits users in that you can implement more features and fix more bugs in less time. This is mostly a bullshit answer that is hardly ever the case in reality and is pretty much always used as an excuse to favor developers over users.
  - spankalee 4y ago
    You can get the same organizational benefits and components with vanilla HTML & JS like web components.
    - 4y ago
simonw 4y ago
I think it's worth calling out accessibility directly, in particular screen reader compatibility. I have yet to find a great guide to making SPAs work well with screen readers that goes beyond "read the ARIA spec" - but the ARIA spec isn't actually that useful for understanding the nuts and bolts of how you should build things so that e.g. screen readers know when the SPA has navigated to a new page, or loaded fresh content in a smaller page region. My understanding is that MPAs are, by default, massively more accessible than SPAs. But my experience is that SPA authors rarely seem to indicate that they care.
- SparkyMcUnicorn 4y ago
  Using a framework that is accessibility friendly is probably the best first step. Vuetify has gotten good feedback, with little to no additional steps for my implementations. If I'm remembering correctly, Tailwind's Headless UI, Chakra, and a few others are in the same boat. Searching for "a11y [framework]" on GitHub gives good results and some "awesome" pages that link to resources on the subject.
- 88913527 4y ago
  You need to have a first-class understanding of accessibility to not have a11y problems. If your MPA framework allows you to define an "onClick" handler with a div tag, you're back in React's set of accessibility problems (versus using a button element, etc).
  - sacnoradhq 4y ago
    Don't get me started on things React sucks at.
  - robertoandred 4y ago
    What accessibility problems do you think React has? It doesn't make you put onClicks on divs.
    - 88913527 4y ago
      Poorly phrased. React has no inherent a11y issue. People misapply it too frequently due to a lack of fundamental knowledge. MFA's cater towards building less interactive content, and more so static pages, so they are less likely to have a11y bugs. I wouldn't be surprised one bit if Angular apps failed a11y audits at similar rates to React apps. But it isn't a problem with SPA's as an architectural concept, the problem is uneducated engineers.
pqdbr 4y ago
This article was the first time I learned about https://developer.chrome.com/docs/web-platform/view-transitions/ https://developer.chrome.com/docs/web-platform/view-transiti.... It looks really great, and I think Rails Hotwired / Turbo could really benefit from this API. Of course, someone beat me to it: https://dev.to/nejremeslnici/how-to-use-view-transitions-in-hotwire-turbo-1kdi https://dev.to/nejremeslnici/how-to-use-view-transitions-in-...
- Alifatisk 4y ago
  Very cool!
slaymaker1907 4y ago
I think the view transitions API will be good, but it's currently only available for Chromium browsers so it is not really a competitor to SPAs for the time being. I'm also kind of opposed to really broad generalizations like this since what is most effective currently kind of depends on what you're building. A calculator built as an MPA would be kind of ridiculous.
- Ralfp 4y ago
  I’ve liked the transitions demo from Chrome guys, but it has barely any support yet.
fks 4y ago
An incredible example of what's suddenly possible with the View Transition API: https://twitter.com/charca/status/1637832314364497920 https://twitter.com/charca/status/1637832314364497920 (Built with Astro)
kerblang 4y ago
Nobody ever talks about the monolithic all-in-one framework upgrade? You really haven't come to terms with SPA until you've done the all-in-one framework upgrade, man. It's like running thru a hailstorm of razor blades
- peterangular 4y ago
  Devs who push for monolith all-in-one SPA frameworks are seldom ones who stick around long enough after shipping to experience what you're discussing. They're far more concerned with the new framework hotness vs. building a lasting and consistent user experience. Just my anecdotal experience.
  - sacnoradhq 4y ago
    Remember the explosion of front-end tools no one uses anymore? They usually follow the pattern of 3 seconds of hype followed by 10 years of digging out a mountain of technical debt from some asshole who has since moved on.
nfRfqX5n 4y ago
> Inclusive and robust by default, Energy-efficiency, Privacy-focused I imagine trying to use these reasons with executives and getting laughed out of the room
domenicd 4y ago
Note that MPAs can also opt-in to prerendering, where the browser spins up a hidden background tab (sort of) that renders the next page, and then gets activated when the user clicks a link. This gives truly instant-feeling navigations. More detail at https://developer.chrome.com/blog/prerender-pages/ https://developer.chrome.com/blog/prerender-pages/ . For now page-to-page prerendering is Chrome only, but since it's a progressive enhancement that seems fine. (Safari does prerendering from the URL bar as well.) SPAs can get this sort of thing too, but it's less automatic and generally requires framework support for keeping track of chunks of not-yet-visible, non-user-interactable inert DOM and matching them up with link clicks. Whereas with MPAs, because you're using the standard page rendering and link paradigm, the browser can manage for you. Source: engineer on Chrome working on this feature :)
- nextaccountic 4y ago
  > SPAs can get this sort of thing too, but it's less automatic and generally requires framework support for keeping track of chunks of not-yet-visible, non-user-interactable inert DOM and matching them up with link clicks Do you know of a React library for doing this? tanstack react-query can prefetch [0] but it just prefetches a REST API, it doesn't prerender in an invisible DOM node or something (also "prerendering" in React usually refer to server-side rendering of HTML text, not to prerendering something in the browser, so this seems a bit hard to search for) [0] https://tanstack.com/query/latest/docs/react/guides/prefetching https://tanstack.com/query/latest/docs/react/guides/prefetch...
- simplotek 4y ago
  > Note that MPAs can also opt-in to prerendering, where the browser spins up a hidden background tab (sort of) that renders the next page, and then gets activated when the user clicks a link. This gives truly instant-feeling navigations. I recall Opera doing this sort of thing around two decades ago. It had a setting to aggressively cash all links, and navigating between those was instantaneously. Is this what Chrome does?
  - MrJohz 4y ago
    I remember reading once (but now I can't find the details, this may be apocryphal): a few browsers did try this for a while, but it turned out be a disaster for certain sites. If, for example, you have a page loaded with a list of items, each of which has a delete link next to it (think PHPMyAdmin): what happens if the browser automatically sends a get request to every link it sees in order to prefetch the content? The server will just see this as a user clicking a link to the delete page and automatically delete the item. The solution to this is obviously that servers should obey the rules of HTTP methods better: GET is idempotent and doesn't change state, so it should be impossible to delete data just by clicking a link. Instead, you should at least need to submit a form via a POST request in some way. In practice, though, browsers need to deal with badly designed servers, which is why almost all of this prerendering, precaching, etc stuff requires an explicit opt-in from the website.
paulddraper 4y ago
> large bundle sizes 228KB That's a moderately sized image. That's <1s of 1080p video. And that's assuming you haven't heard of a thing called "gzip." At some point, I think we're finding things to be unhappy about.
- sintaxi 4y ago
  The issue with large JavaScript files is the overhead of the browser parsing, interpreting, and executing of the JavaScript. The network transfer size has nothing to do with it.
  - kitkat_new 4y ago
    wasm would be faster regarding parsing, interpreting and executing
    - sidewndr46 4y ago
      WASM cannot interact with the DOM.
      - kitkat_new 4y ago
        it can through JS interoperability (only needs tiny JS files), all of the remaining things can be handled by WASM.
- re-thc 4y ago
  I only hear of "brotli" :)
  - paulddraper 4y ago
    Well even better :)
- zzo38computer 4y ago
  Just because video will be a much large file size, does not mean that text and forms should have to be, too (unless you are writing an entire book, I suppose).
robertoandred 4y ago
His way to make a website available to any browser is to use an API that nothing but the latest Chrome supports?
- userbinator 4y ago
  Google's propaganda runs deep. Chrome is like the new IE, but far worse for user control and privacy.
  - samtho 4y ago
    I see comments like this a lot and it always makes me wonder if we have collectively forgotten just how damaging IE was the web or if our default vilification of a browser we don’t like is to just compare it with IE.
    - userbinator 4y ago
      "damaging"? That's Google-propaganda for sure. Chrome is far more "damaging" than IE ever was.
      - samtho 4y ago
        I never said chrome was not damaging. In fact, it’s damage is likely to be more widespread. The underlying point here was that it feels like we’ve picked an apples-to-oranges comparison when we say just how bad chrome is when compared to IE. Both were popular for different reasons, during different points of the internet, and are damaging in different ways.
- chrismorgan 4y ago
  If you’re talking about the View Transitions API, it’s a fairly unimportant progressive enhancement that wouldn’t even be a good idea for most sites. It doesn’t matter if the browser doesn’t support it.
hdlothia 4y ago
What confuses me the most about these articles is the idea what ppl jumped on these frameworks just to chase new shiny things. There is always rdd going on but did these frameworks really not improve anything about the web experience for users? My career started around the same time react and angular started to take off. Why did we move away from mpas if they were so much better?
- andrewmutz 4y ago
  Did they improve things for users? From a performance perspective it's a bit of a wash. You get slower first page load and lots of spinners in exchange for faster navigation
  - hdlothia 4y ago
    ok so how did they get so much market share? cargo culting from fbook? or was it the appeal of pushing computer to the client like ther other commenter said?
    - sophiabits 4y ago
      React & friends are fast to build apps in and are quick to onboard new engineers on. Developer experience has been prioritized over user experience.
- wetpaws 4y ago
  Cause splitting backend and frontend lets you keep all the js code and client resources on CDN.
- amrocha 4y ago
  The shift to SPAs happened around the same time as mobile browsing was becoming the norm. Phones were alright, but data speeds were really slow. So instead of having to download an entire HTML page and all the assets used every time you navigate, people built SPAs. Download everything up front, and then fetch data with small API requests. This way even though first load might take a while, everything is cached, and the client just needs to query the API for data. The other side of it is that websites used to be pretty simple, and as browsers evolved past IE10, the kinds of things people build on the web also got more complex.
FpUser 4y ago
Single page applications do not have to be loaded all in advance: function main_state_changed(aState) { main_state_display.innerHTML = loadFileFromServer(aState); } this way your app loads parts on on need basis. As for tooling - I do use minification but the rest is plain html, css and javascript and couple of selected libs. No frameworks and works wonders for me.
- komali2 4y ago
  Do you have more examples of this you can link? I'm curious about what's going on here.
  - JenrHywy 4y ago
    Angular allows you to split your code into modules and then load them on-demand. For example, we have a module for the admin pages, which is only loaded when routing to one of them, which means that module is never loaded for non-admin users.
    - FpUser 4y ago
      No Angular needed. Simple Fetch does all that.
      - JenrHywy 4y ago
        GP asked for an example, of which Angular is one
  - FpUser 4y ago
    You can load any file from server into string. Use for example fetch call to do it. You can then assign innerHTML property of any DOM element of your choosing to that string [0]. The string can contain any valid HTML and JavaScript. This makes your front end modular and scalable. It is dead simple and does not require anything but plain JavaScript. It is amazing how modern web developers flock to that mess of frameworks and tooling to achieve what basic JS and no tooling do way more efficiently and with less time spent. [0] - https://www.w3schools.com/jsref/prop_html_innerhtml.asp https://www.w3schools.com/jsref/prop_html_innerhtml.asp
komali2 4y ago
> Search engines use site performance as a search ranking signal, which makes good performance crucial. So this is probably wildly naive, but I find myself wondering why SEO is so important still in 2023. Like, how much traffic is coming from Google that converts to paying customers or clients? I suppose it's industry specific, but for my friends that have sold product on e-commerce sites, the best way to make money seems to have been find a way to post on reddit for a given niche community without getting banned, and Instagram ads. Maybe Facebook ads. For a SAAS, I'm really curious how much converted traffic comes from Google. When I need a SAAS I usually first ask all my friends, then start searching "service_i_need reddit sysadmin" to see what other people are using and their experience. Maybe I'll read a listicle from an aggregator i trust. Also, you can just pay Google to be at the top of whatever search results, so you can Optimize by just giving them money.
- sacnoradhq 4y ago
  If no one can find you, then all of your effort is meaningless and you will make $0. That's why SEO exists. It's impossible for shoestring apps to give Google money. They would fail at being businesses if they funneled money they didn't have to Google.
  - komali2 4y ago
    Sure, but I'm asking, who's being found these days on Google? It seems to me people are being found on listicles, reddit, instagram, facebook, and various word of mouth channels.
- sophiabits 4y ago
  The exact data on how much search traffic converts varies wildly from business to business so it’s hard to give a ballpark figure. The big win from SEO traffic that I’ve seen is that CAC for these customers tends to be a lot lower than for customers coming in via ads. Paid advertising and posting on social media has its place, but there are a LOT of people using Google and getting to rank 1 for important keywords usually works out cheaper than paying for the ad space.
zzo38computer 4y ago
The benefits they list for classic multi-page applications are good. Even disregarding searching and caching, the other stuff listed there I care about sufficiently (to work even if scripts are disabled, or with extensions, with other web browsers, accessibility, back/forward/scrolling, energy efficiency, etc), that the classic multi-page applications are good.
sacnoradhq 4y ago
Déjà vu 2011. Sigh. This has happened before. The failures need: - Update the URL rather than depend on ephemeral DOM state like some damn Flash app - Don't load the entire site all at once as one giant file - Use server- and client-rendering wherever it makes the most sense - Accessibility or be in a heap of legal trouble globally - Get fancy by swapping js and html, but be prepared to deal with all edge-cases of things that don't know what magic is happening
yawaramin 4y ago
I'm really enjoying using htmx nowadays to sprinkle interactivity on server-rendered pages with almost no JavaScript. Its extra attributes make it easy to do common interactions on pages. Highly recommended 12 KB gzipped zero-dependency JavaScript. Example: <button title="Remove 'ABC' from cart" hx-delete="/cart/123/item/abc" hx-target="#item-abc"> Clicking this button will trigger a `DELETE /cart/123/item/abc` request and swap the response into the element selected by the `hx-target` selector. The response would be an HTML fragment. So instead of an API serving JSON you would have an API serving...HTML. It's a neat fit with any server rendering technology.
- arethuza 4y ago
  I take it there isn't a problem with the HTML response also using those "hx-" attributes?
  - yawaramin 4y ago
    Exactly, this enables setting up a series of interactions in the page, i.e. an interactive workflow.
nathants 4y ago
single page isn’t far enough. the deployment artifact needs to be a single html file. i do it like this: https://github.com/nathants/aws-gocljs https://github.com/nathants/aws-gocljs
andyrichardson 4y ago
Hype culture in developer tooling has gotten out of hand imho. A SPA with precaching is almost always going to be the most responsive experience. Next and similar tools are decent if you NEED SSR and don't want to go the prerendering route - but there's some extra work involved.

122 points by 0xblinq 4y ago

> Single Page Application frameworks in the last few years have pivoted away from client-side rendering to server-rendering and we welcome this improvement. However, the large starting size of client JavaScript bundles customary to SPA persist: Remix (228 kB), Next.js (248 kB), Gatsby (210 kB), and Nuxt (191 kB). Good point, I also think stimulusreflex.com deserves some highlight in this case too. This is where it shines! https://v3-4-docs.docs.stimulusreflex.com/#faster-uis-smaller-downloads-and-longer-battery-life https://v3-4-docs.docs.stimulusreflex.com/#faster-uis-smalle...

benatkin 4y ago

> You can’t JavaScript your way out of an excess-JavaScript problem. These large JavaScript bundles are costly to site performance. I was gonna say: "This is what some Hugo fans might say, but 11ty and Astro suggest otherwise." Then I saw the author of the post is the author of 11ty. Still, the middle ground is being pursued by Svelte and Fresh. I prefer something less frameworky though.

endisneigh 4y ago

The SPA vs server side rendered page debate is so exhausted at this point. The tech is such that they’re nearly equivalent if you have a good team that understands the appropriate technology. You can have an SPA with a proper router that respects page history, loads html fragments from a server, remembers positions on reload, etc. You can also have a server side rendered page sprinkled with JavaScript and use web sockets to create dom element level transitions and interactivity The “MPA” described in the article has always been possible in a “SPA.” It’s more about the UX of your app than anything else

j45 4y ago
Exhausted but always new to someone. It's interesting to see technologies like livewire come out that take things back to basics.
ec109685 4y ago
Your second paragraph essentially is creating a little mini browser, and you have to make sure to get every detail right or you’re back to the uncanny valley of SPA web pages. Performance can even be worse with SPA “page” navigation if multiple round trips are needed for the data on the next page. SPA’s should be used web apps (think slack or Asana), and stick to sever rendered for web pages.
- slaymaker1907 4y ago
  I think you've highlighted a big problem with SPAs in that they can encourage multiple API calls per user action. IMO, you should probably have a single endpoint per thing a user might do that might combine several conceptual APIs. i.e., if you have an API to add something to a list, have that API also return the current list.
  - BFLpL0QNek 4y ago
    I see this in most single page apps. They have a waterfall of multiple API requests by the browser to display a single page. That means the front end has a bunch of logic to aggregate and piece together requests. This in itself isn’t a big deal, if you move to doing it on the backend you still have the same logic and need to make the same sub requests. Where it does become problematic is it leads to fat API endpoints sending far more data to the client than is needed. GraphQL lets you choose what fields you query but odds are there’s still data available you can ask for that shouldn’t be asked for and sent to a browser. If your requests/aggregations are done serverside it gives you a better chance of filtering out data that should never be accessible in the browser. You can also make full use of Cache-Control headers and backend caching. Creating individual endpoints for web apps went out of fashion as it involves more effort and people don’t like effort to do things well. I see it re-invented recently as backend-for-frontend.
    - slaymaker1907 4y ago
      Multiple queries from the frontend is still not great because the latency is much higher than doing at the server all else being equal.
simonw 4y ago
How do you make sure your SPAs work well with screen readers?
- endisneigh 4y ago
  More or less the same as a regular page - use aria labels, update names and titles of elements, make sure the focus is set correctly, etc.
  - taeric 4y ago
    And try to be frugal on the tags you make. Component design is the enemy here. Just take a peak at the nav elements in many designs and see how embedded the divs go.
    - sebazzz 4y ago
      Are you referring to styled-components and the like? What is exactly the problem with that?* * except media queries, those seem hard
      - zdragnar 4y ago
        Many prebuilt component libraries design for maintenance and all possible uses over being frugal. The actual markup can get really ugly with i.e. MUI. When you put in the effort to build the components yourself, you aren't trying to be everything for everyone, so you get to skip a lot of the cruft.
        taeric 4y ago
        Exactly this. Is a large reason to not try to build the most general components, either. Build what you need, where you can. That all said, I also have to ack that the libraries are going to be hard to beat for speed of delivery. :(
        4y ago
the_gipsy 4y ago
> You can have an SPA with a proper router that respects page history, loads html fragments from a server, remembers positions on reload, etc. In theory.
- Alifatisk 4y ago
  And in practice too?
benatkin 4y ago
No, it's not exhausted - people and businesses pushing heavyweight frameworks stand to lose out, and trying to silence the debate would help them. React seems like a bubble to me, created by fancy code that seems good at first glance but doesn't make a huge difference. What's it supposed to be amazing at, simple stuff or complex stuff? If simple stuff then why are people downloading 200K for Hello, World? If for complex stuff why isn't something like VSCode, Monaco, CodeMirror written with React? Those have state galore, and React's one-way data binding is no revelation for them. In fact inside React things like the ironically named react-hook-form get around React's one-way data binding by letting the form inputs be uncontrolled* (ironically named because react hooks makes it sound like it's going with the grain of react when it's thankfully going against it). Maybe ChatGPT will pop the bubble by churning out vanilla js that beats it. :) * https://react-hook-form.com/advanced-usage/#ControlledmixedwithUncontrolledComponents https://react-hook-form.com/advanced-usage/#Controlledmixedw... React Hook Form embraces uncontrolled components but is also compatible with controlled components.
- endisneigh 4y ago
  There are smaller SPAs like preact or mithril. One could similarly argue that why should you have to use Django to show a user hello world? It really doesn’t matter. Master your tool and most of the supposed downsides can be avoided.
  - benatkin 4y ago
    I have a lot of respect for mithril, they created a tiny vdom that works really well. Though you don't always need one. https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead I have played thousands of bullet chess games on Lichees and is and was very snappy and used to be based on Mithril so it's very battle tested in a literal sense. https://bestofjs.org/projects?tags=vdom https://bestofjs.org/projects?tags=vdom FWIW I disagree that something like virtual DOM can be pure overhead. It is useful to have virtual just about anything. Virtual filesystems for instance.
- nicoburns 4y ago
  It’s good when you want interactivity that’s technically straightforward but in high volume. It doesn’t work for code editors because they need very close interaction with the DOM, whereas React provides an abstraction layer that covers the common cases.
simplotek 4y ago
> (...) they’re nearly equivalent if you have a good team that (...) That's a lot of hand-waving weasel words to blame those experiencing problems for the naturally occurring problems. If it was the same thing, we would not be having discussions on their pros and cons. This is not a team-specific issue.

thrill 4y ago

Quit using these ginormous frameworks and libraries. Vanilla Javascript is all you need.

graypegg 4y ago
The organizational and maintainability benefits you get from using something like react far out weigh the actually quite minor file size bump. That is the least of your worries. source: myself; someone who moved to working on a project entirely written in vanilla JS… which has just become its own bespoke framework.
- WillPostForFood 4y ago
  I agree, but note that we are talking about a benefit that accrues to the developer, not the user.
  - slaymaker1907 4y ago
    It also benefits users in that you can implement more features and fix more bugs in less time. Performance is a feature and what that means is that while you can't just completely ignore it, it's not always the highest priority.
    - bdougherty 4y ago
      > It also benefits users in that you can implement more features and fix more bugs in less time. This is mostly a bullshit answer that is hardly ever the case in reality and is pretty much always used as an excuse to favor developers over users.
- spankalee 4y ago
  You can get the same organizational benefits and components with vanilla HTML & JS like web components.
  - 4y ago

simonw 4y ago

I think it's worth calling out accessibility directly, in particular screen reader compatibility. I have yet to find a great guide to making SPAs work well with screen readers that goes beyond "read the ARIA spec" - but the ARIA spec isn't actually that useful for understanding the nuts and bolts of how you should build things so that e.g. screen readers know when the SPA has navigated to a new page, or loaded fresh content in a smaller page region. My understanding is that MPAs are, by default, massively more accessible than SPAs. But my experience is that SPA authors rarely seem to indicate that they care.

SparkyMcUnicorn 4y ago
Using a framework that is accessibility friendly is probably the best first step. Vuetify has gotten good feedback, with little to no additional steps for my implementations. If I'm remembering correctly, Tailwind's Headless UI, Chakra, and a few others are in the same boat. Searching for "a11y [framework]" on GitHub gives good results and some "awesome" pages that link to resources on the subject.
88913527 4y ago
You need to have a first-class understanding of accessibility to not have a11y problems. If your MPA framework allows you to define an "onClick" handler with a div tag, you're back in React's set of accessibility problems (versus using a button element, etc).
- sacnoradhq 4y ago
  Don't get me started on things React sucks at.
- robertoandred 4y ago
  What accessibility problems do you think React has? It doesn't make you put onClicks on divs.
  - 88913527 4y ago
    Poorly phrased. React has no inherent a11y issue. People misapply it too frequently due to a lack of fundamental knowledge. MFA's cater towards building less interactive content, and more so static pages, so they are less likely to have a11y bugs. I wouldn't be surprised one bit if Angular apps failed a11y audits at similar rates to React apps. But it isn't a problem with SPA's as an architectural concept, the problem is uneducated engineers.

pqdbr 4y ago

This article was the first time I learned about https://developer.chrome.com/docs/web-platform/view-transitions/ https://developer.chrome.com/docs/web-platform/view-transiti.... It looks really great, and I think Rails Hotwired / Turbo could really benefit from this API. Of course, someone beat me to it: https://dev.to/nejremeslnici/how-to-use-view-transitions-in-hotwire-turbo-1kdi https://dev.to/nejremeslnici/how-to-use-view-transitions-in-...

Alifatisk 4y ago
Very cool!

slaymaker1907 4y ago

I think the view transitions API will be good, but it's currently only available for Chromium browsers so it is not really a competitor to SPAs for the time being. I'm also kind of opposed to really broad generalizations like this since what is most effective currently kind of depends on what you're building. A calculator built as an MPA would be kind of ridiculous.

Ralfp 4y ago
I’ve liked the transitions demo from Chrome guys, but it has barely any support yet.

fks 4y ago

An incredible example of what's suddenly possible with the View Transition API: https://twitter.com/charca/status/1637832314364497920 https://twitter.com/charca/status/1637832314364497920 (Built with Astro)

kerblang 4y ago

Nobody ever talks about the monolithic all-in-one framework upgrade? You really haven't come to terms with SPA until you've done the all-in-one framework upgrade, man. It's like running thru a hailstorm of razor blades

peterangular 4y ago
Devs who push for monolith all-in-one SPA frameworks are seldom ones who stick around long enough after shipping to experience what you're discussing. They're far more concerned with the new framework hotness vs. building a lasting and consistent user experience. Just my anecdotal experience.
- sacnoradhq 4y ago
  Remember the explosion of front-end tools no one uses anymore? They usually follow the pattern of 3 seconds of hype followed by 10 years of digging out a mountain of technical debt from some asshole who has since moved on.

nfRfqX5n 4y ago

> Inclusive and robust by default, Energy-efficiency, Privacy-focused I imagine trying to use these reasons with executives and getting laughed out of the room

domenicd 4y ago

Note that MPAs can also opt-in to prerendering, where the browser spins up a hidden background tab (sort of) that renders the next page, and then gets activated when the user clicks a link. This gives truly instant-feeling navigations. More detail at https://developer.chrome.com/blog/prerender-pages/ https://developer.chrome.com/blog/prerender-pages/ . For now page-to-page prerendering is Chrome only, but since it's a progressive enhancement that seems fine. (Safari does prerendering from the URL bar as well.) SPAs can get this sort of thing too, but it's less automatic and generally requires framework support for keeping track of chunks of not-yet-visible, non-user-interactable inert DOM and matching them up with link clicks. Whereas with MPAs, because you're using the standard page rendering and link paradigm, the browser can manage for you. Source: engineer on Chrome working on this feature :)

nextaccountic 4y ago
> SPAs can get this sort of thing too, but it's less automatic and generally requires framework support for keeping track of chunks of not-yet-visible, non-user-interactable inert DOM and matching them up with link clicks Do you know of a React library for doing this? tanstack react-query can prefetch [0] but it just prefetches a REST API, it doesn't prerender in an invisible DOM node or something (also "prerendering" in React usually refer to server-side rendering of HTML text, not to prerendering something in the browser, so this seems a bit hard to search for) [0] https://tanstack.com/query/latest/docs/react/guides/prefetching https://tanstack.com/query/latest/docs/react/guides/prefetch...
simplotek 4y ago
> Note that MPAs can also opt-in to prerendering, where the browser spins up a hidden background tab (sort of) that renders the next page, and then gets activated when the user clicks a link. This gives truly instant-feeling navigations. I recall Opera doing this sort of thing around two decades ago. It had a setting to aggressively cash all links, and navigating between those was instantaneously. Is this what Chrome does?
- MrJohz 4y ago
  I remember reading once (but now I can't find the details, this may be apocryphal): a few browsers did try this for a while, but it turned out be a disaster for certain sites. If, for example, you have a page loaded with a list of items, each of which has a delete link next to it (think PHPMyAdmin): what happens if the browser automatically sends a get request to every link it sees in order to prefetch the content? The server will just see this as a user clicking a link to the delete page and automatically delete the item. The solution to this is obviously that servers should obey the rules of HTTP methods better: GET is idempotent and doesn't change state, so it should be impossible to delete data just by clicking a link. Instead, you should at least need to submit a form via a POST request in some way. In practice, though, browsers need to deal with badly designed servers, which is why almost all of this prerendering, precaching, etc stuff requires an explicit opt-in from the website.

paulddraper 4y ago

> large bundle sizes 228KB That's a moderately sized image. That's <1s of 1080p video. And that's assuming you haven't heard of a thing called "gzip." At some point, I think we're finding things to be unhappy about.

sintaxi 4y ago
The issue with large JavaScript files is the overhead of the browser parsing, interpreting, and executing of the JavaScript. The network transfer size has nothing to do with it.
- kitkat_new 4y ago
  wasm would be faster regarding parsing, interpreting and executing
  - sidewndr46 4y ago
    WASM cannot interact with the DOM.
    - kitkat_new 4y ago
      it can through JS interoperability (only needs tiny JS files), all of the remaining things can be handled by WASM.
re-thc 4y ago
I only hear of "brotli" :)
- paulddraper 4y ago
  Well even better :)
zzo38computer 4y ago
Just because video will be a much large file size, does not mean that text and forms should have to be, too (unless you are writing an entire book, I suppose).

robertoandred 4y ago

His way to make a website available to any browser is to use an API that nothing but the latest Chrome supports?

userbinator 4y ago
Google's propaganda runs deep. Chrome is like the new IE, but far worse for user control and privacy.
- samtho 4y ago
  I see comments like this a lot and it always makes me wonder if we have collectively forgotten just how damaging IE was the web or if our default vilification of a browser we don’t like is to just compare it with IE.
  - userbinator 4y ago
    "damaging"? That's Google-propaganda for sure. Chrome is far more "damaging" than IE ever was.
    - samtho 4y ago
      I never said chrome was not damaging. In fact, it’s damage is likely to be more widespread. The underlying point here was that it feels like we’ve picked an apples-to-oranges comparison when we say just how bad chrome is when compared to IE. Both were popular for different reasons, during different points of the internet, and are damaging in different ways.
chrismorgan 4y ago
If you’re talking about the View Transitions API, it’s a fairly unimportant progressive enhancement that wouldn’t even be a good idea for most sites. It doesn’t matter if the browser doesn’t support it.

hdlothia 4y ago

What confuses me the most about these articles is the idea what ppl jumped on these frameworks just to chase new shiny things. There is always rdd going on but did these frameworks really not improve anything about the web experience for users? My career started around the same time react and angular started to take off. Why did we move away from mpas if they were so much better?

andrewmutz 4y ago
Did they improve things for users? From a performance perspective it's a bit of a wash. You get slower first page load and lots of spinners in exchange for faster navigation
- hdlothia 4y ago
  ok so how did they get so much market share? cargo culting from fbook? or was it the appeal of pushing computer to the client like ther other commenter said?
  - sophiabits 4y ago
    React & friends are fast to build apps in and are quick to onboard new engineers on. Developer experience has been prioritized over user experience.
wetpaws 4y ago
Cause splitting backend and frontend lets you keep all the js code and client resources on CDN.
amrocha 4y ago
The shift to SPAs happened around the same time as mobile browsing was becoming the norm. Phones were alright, but data speeds were really slow. So instead of having to download an entire HTML page and all the assets used every time you navigate, people built SPAs. Download everything up front, and then fetch data with small API requests. This way even though first load might take a while, everything is cached, and the client just needs to query the API for data. The other side of it is that websites used to be pretty simple, and as browsers evolved past IE10, the kinds of things people build on the web also got more complex.

FpUser 4y ago

Single page applications do not have to be loaded all in advance: function main_state_changed(aState) { main_state_display.innerHTML = loadFileFromServer(aState); } this way your app loads parts on on need basis. As for tooling - I do use minification but the rest is plain html, css and javascript and couple of selected libs. No frameworks and works wonders for me.

komali2 4y ago
Do you have more examples of this you can link? I'm curious about what's going on here.
- JenrHywy 4y ago
  Angular allows you to split your code into modules and then load them on-demand. For example, we have a module for the admin pages, which is only loaded when routing to one of them, which means that module is never loaded for non-admin users.
  - FpUser 4y ago
    No Angular needed. Simple Fetch does all that.
    - JenrHywy 4y ago
      GP asked for an example, of which Angular is one
- FpUser 4y ago
  You can load any file from server into string. Use for example fetch call to do it. You can then assign innerHTML property of any DOM element of your choosing to that string [0]. The string can contain any valid HTML and JavaScript. This makes your front end modular and scalable. It is dead simple and does not require anything but plain JavaScript. It is amazing how modern web developers flock to that mess of frameworks and tooling to achieve what basic JS and no tooling do way more efficiently and with less time spent. [0] - https://www.w3schools.com/jsref/prop_html_innerhtml.asp https://www.w3schools.com/jsref/prop_html_innerhtml.asp

komali2 4y ago

> Search engines use site performance as a search ranking signal, which makes good performance crucial. So this is probably wildly naive, but I find myself wondering why SEO is so important still in 2023. Like, how much traffic is coming from Google that converts to paying customers or clients? I suppose it's industry specific, but for my friends that have sold product on e-commerce sites, the best way to make money seems to have been find a way to post on reddit for a given niche community without getting banned, and Instagram ads. Maybe Facebook ads. For a SAAS, I'm really curious how much converted traffic comes from Google. When I need a SAAS I usually first ask all my friends, then start searching "service_i_need reddit sysadmin" to see what other people are using and their experience. Maybe I'll read a listicle from an aggregator i trust. Also, you can just pay Google to be at the top of whatever search results, so you can Optimize by just giving them money.

sacnoradhq 4y ago
If no one can find you, then all of your effort is meaningless and you will make $0. That's why SEO exists. It's impossible for shoestring apps to give Google money. They would fail at being businesses if they funneled money they didn't have to Google.
- komali2 4y ago
  Sure, but I'm asking, who's being found these days on Google? It seems to me people are being found on listicles, reddit, instagram, facebook, and various word of mouth channels.
sophiabits 4y ago
The exact data on how much search traffic converts varies wildly from business to business so it’s hard to give a ballpark figure. The big win from SEO traffic that I’ve seen is that CAC for these customers tends to be a lot lower than for customers coming in via ads. Paid advertising and posting on social media has its place, but there are a LOT of people using Google and getting to rank 1 for important keywords usually works out cheaper than paying for the ad space.

zzo38computer 4y ago

The benefits they list for classic multi-page applications are good. Even disregarding searching and caching, the other stuff listed there I care about sufficiently (to work even if scripts are disabled, or with extensions, with other web browsers, accessibility, back/forward/scrolling, energy efficiency, etc), that the classic multi-page applications are good.

sacnoradhq 4y ago

Déjà vu 2011. Sigh. This has happened before. The failures need: - Update the URL rather than depend on ephemeral DOM state like some damn Flash app - Don't load the entire site all at once as one giant file - Use server- and client-rendering wherever it makes the most sense - Accessibility or be in a heap of legal trouble globally - Get fancy by swapping js and html, but be prepared to deal with all edge-cases of things that don't know what magic is happening

yawaramin 4y ago

I'm really enjoying using htmx nowadays to sprinkle interactivity on server-rendered pages with almost no JavaScript. Its extra attributes make it easy to do common interactions on pages. Highly recommended 12 KB gzipped zero-dependency JavaScript. Example: <button title="Remove 'ABC' from cart" hx-delete="/cart/123/item/abc" hx-target="#item-abc"> Clicking this button will trigger a `DELETE /cart/123/item/abc` request and swap the response into the element selected by the `hx-target` selector. The response would be an HTML fragment. So instead of an API serving JSON you would have an API serving...HTML. It's a neat fit with any server rendering technology.

arethuza 4y ago
I take it there isn't a problem with the HTML response also using those "hx-" attributes?
- yawaramin 4y ago
  Exactly, this enables setting up a series of interactions in the page, i.e. an interactive workflow.

nathants 4y ago

single page isn’t far enough. the deployment artifact needs to be a single html file. i do it like this: https://github.com/nathants/aws-gocljs https://github.com/nathants/aws-gocljs

andyrichardson 4y ago

Hype culture in developer tooling has gotten out of hand imho. A SPA with precaching is almost always going to be the most responsive experience. Next and similar tools are decent if you NEED SSR and don't want to go the prerendering route - but there's some extra work involved.