6 ms·

After years of testing different JS frameworks and build systems, I became convinced that heavy Javascript frontends are generally a bad model for the web. One

After years of testing different JS frameworks and build systems, I became convinced that heavy Javascript frontends are generally a bad model for the web. One thing is to generate a build and ship it once over the wire in the form of an Installer or bytecode executable. Another thing is to ship the entire package and/or parts of it with every launch event, plus the complexity of shipping transpiled code to different interpreters (different browser in this case) which adds more complexity to the model until it finally explodes. The server side with HTML generated at the backend is a more predictable, faster and simpler approach. Bandwidth is not the issue anymore, but latency. Heavy API consumption from the client, leaves data exposed and increases the latter. Hotwire/Turboframes/StimulusJS removed the need of generating HTML code at the client, leaving a single source of truth while still having a dynamic/friendly frontend. I consider it to be a better model for the web. Plus, new Page Transition API and Navigation API are possibly game changers for a lot of use cases out here.

wil421 4y ago
This is why I am convinced part of the reason Google and Facebook create JS frameworks is so they can move computation out their data centers and onto your computer.
- helloguillecl 4y ago
  I think that is in the case of Facebook they were trying to solve their own use case, and in the case of Google, they saw it as a way of strengthening the strategic position of the web in general vs apps.
- hiptobecubic 4y ago
  Eh, i think you're thinking too small here. This whole thread is full of people saying things like, "When _I'm_ building a webapp," and "_My_ projects end up loading slowly," etc. Google is saying things like, "When 400 people are working on a web app, how can we avoid it turning into a shit show."
no_wizard 4y ago
It should all be down the applications need for client side interactions. Even with hotwire/turboframes, phoenix liveview or other websocket / real time server driven update patterns, it can be suboptimal for many catagories of applications as these rely on (albeit smart) whole replacement of DOM nodes. In heavy applications, or applications that have a lot of represented state, its not the panacea it might seem at first glance. I always tell people, "mileage may vary, there's no silver bullets in this industry". I think it holds true especially when talking about stuff like this.
- helloguillecl 4y ago
  One thing is to have JS for client-side interactivity, and another thing is to generate the entire HTML using javascript by sending both the data and javascript bundles to the client.
  - no_wizard 4y ago
    Incremental rehydration techniques make this much much less of an issue (React 18 supports this now, IIRC, for instance). The tl;dr is that if you employ SSG or SSR you won't endup up with immediate re-hydrating once the client loads up, but only when something triggers the need for re-hydration, like a button click. That to me seems like the sweet spot for highly interactive applications that are very stateful, however like I said previously, your mileage may vary.
candiddevmike 4y ago
Streaming section by section of a frontend sounds like a troubleshooting nightmare. Users expect an interactive experience with a website. That means JavaScript. Anything else is going to be more complex.
- alttab 4y ago
  "users expect an interactive experience with a website" - I think this is a generalization that is getting a lot of web developers into needlessly complex toolchains and frameworks. When I'm in a browser, 99% of the time I expect the page to have what I'm looking for. I rarely care if its interactive. In fact, the more interactive it is, the less enjoyable the experience is. This holds even firmer when I'm on a desktop.
  - kitsunesoba 4y ago
    I tend to agree. It’s frustrating whenever whatever nugget of information I’m seeking is buried under multiple clicks (navigation, collapsible sections, modals, popovers, etc) and even worse when one or more of those clicks results in a loading spinner that takes longer to play its fade in transition than it would’ve taken to load an entire static page.
- gamblor956 4y ago
  No, regular users definitely prefer web pages over interactive websites. With webpages, any delays make intuitive sense and are accepted by the user. With an interactive web app, the web app gets blamed for any delays or latency because there is no full-page refresh.
noud 4y ago
The more I work with advanced JS frameworks, the more I think I could also have done it with just vanilla javascript (with some jquery). Webapps I made 10 years ago where no less responsive than the webapps I make now. Nor do they take more time to create. The only difference is the size of the applications. They significantly increase with all overhead of frameworks. I wouldn't be surprised when webapp development will return partly to what it was a decade ago, where small (stand-alone) libraries are preferred to these huge, batteries-included, frameworks. edit: With some exceptions. Some webapps are huge. They are near impossible to program without a solid framework. But this is no more than 5% of all the webapps I create.
- lukevp 4y ago
  React and react-dom are < 100kb compressed, which is pretty much how big jquery is. Preact is even smaller. Which framework are you talking about that’s huge and batteries-included? if you want to drop react in a script tag and write JS that’s compatible with all browsers, you can do that too.
  - fwip 4y ago
    I got curious and looked it up, looks like Jquery is about 30kb compressed & minified nowadays: https://mathiasbynens.be/demo/jquery-size https://mathiasbynens.be/demo/jquery-size
  - helloguillecl 4y ago
    If you are running a client side app generally you’ll need many other libraries as well. Just to name a few: GraphQL, i18n, Google Firebase, Date parser/formatter, Numbers, etc.
    - nawgz 4y ago
      > GraphQL What libraries does this require? I'm just issuing fetch requests and getting back JSON. Apollo is absolutely NOT EVEN CLOSE TO required to do GQL... Honestly, both GraphQL and everything else listed seems pretty orthogonal to the original discussion of frameworks... Whether you used VanillaJS or React or a server-rendering platform, your choices of internationalization & datastores & auth & functionality require code...
aledalgrande 4y ago
I think NextJS + React server components would work pretty well for your idea of UX, while maintaining that powerful and flexible DX React has. https://vercel.com/blog/everything-about-react-server-components https://vercel.com/blog/everything-about-react-server-compon...
- helloguillecl 4y ago
  I think NextJS is the best frontend implementation I came across.
_fat_santa 4y ago
What I realized a while back is web development has split into two "routes": building websites and building webapps and I think part of the problem is those two often get conflated. With a website, the idea is a visitor might only visit a single page. Under this model you want to ship as little JS as possible, and ensure that if the user just tries to read a blog post, the entire site isn't getting downloaded. Contrast that with a webapp. I'm currently building a real estate investment calculator/dashboard and the mental model is diametrically different than building a website. Unlike a site, I want the entire app to be loaded upfront because the user is using the "entire" app, not just viewing a page. The problem I see is when one is trying to design a "site" but uses the "app" model, or vice versa. Attempt to use an SSR framework like NextJS for an "app" and you are going to have a bad time, likewise try setting up a site like you would a webapp and you are going to have some pretty serious limitations.
- davidguetta 4y ago
  What country are you from ? I've been doing exactly this in the past year so maybe we could compare / chat about our stuff.
- clarle 4y ago
  This is it. Another thing with a webapp that someone might use regularly is that the JavaScript bundle that's sent down is cached and you likely won't have that same load time every single time. However, if you have a landing page that someone might only visit once, then you want to optimize for as little JavaScript as possible, and in that case, just a pure server-side render might be best for that job.
- simonw 4y ago
  I don't think this model actually works in practice, because mobile traffic vastly eclipses web traffic for almost every kind of web application. Tricks that work on desktop - where a web application might stay open in a browser tab for weeks at a time - don't apply on mobile. On mobile, I'm much more likely to drop into your app for a few minutes to achieve a single goal, then navigate away and un-load it again. So assuming that I'm going to pay that loading price once and then keep interacting with your application doesn't actually work - most of my interactions with your app will be a cold start, often with an empty cache too since browser caches on mobile devices (especially cheaper Android phones) are much smaller.
redmorphium 4y ago
This post isn't about a Javascript frontend, though. The author works very clearly on a Node.js server, and nothing from that gets shipped to a client/browser.
benbristow 4y ago
What about with something that runs in WebAssembly, like .NET's Blazor?
- no_wizard 4y ago
  if you think React is big, you'll be sad by the 2 MB mandatory runtime you have to download just to run your Blazor WASM code, which can add megabytes on top. That said, if your application is actually complex enough to warrant this upfront download cost, might make sense. YMMV as always EDIT: in case it wasn't obvious, I was talking about Blazor WASM not Blazor server
  - protonbob 4y ago
    There are two ways to run blazor. I don't think the WASM version of blazor is the one you're talking about.
    - no_wizard 4y ago
      It most certainly is. As noted in thread: https://github.com/dotnet/aspnetcore/issues/41909 https://github.com/dotnet/aspnetcore/issues/41909
petee 4y ago
> After years of testing different JS frameworks and build systems, I became convinced that heavy Javascript frontends are generally a bad model for the web Funny, after only 5 minutes on any website i come to the same conclusion as a user :P
scotty79 4y ago
I wonder how fast could be something that just replaces everything in the browser, HTML, CSS, JS with just webasm and some reasonable UI engine.
- nawgz 4y ago
  HTML/CSS/JS IS a pretty reasonable UI engine. What tools have you seen that are lighter and allow you to express the same capabilities??
  - scotty79 4y ago
    I haven't but I have trouble with Electron haters that seem to think everything else is better.
samstave 4y ago
sERIOUS question: Is there a method for testing a site that defines how much JS heavy FEs are? --- I have noticed a significant issue with speed on sites after upgrading my main machines, but dont know how to judge if its local or remote. I have a flagshit HP gaming machine, with the best laptop nvidia card on the market.... windows 11 (with a sister machine of same specs with linux) Ryzen 5K RTX 3070 blah blah... But the load times on these "gaming centric" machines are way slower than older, les spec'd machines... I cant tell where my bottle-neck is. How test this specific, in your opinion?
tomxor 4y ago
> Bandwidth is not the issue anymore, but latency. Bandwidth is also the issue, but most web devs or website owners don't seem to realise or care that most of the world is probably struggling with their page weight. Internet speeds are more disparate now than in the 90s, but this issue tends to be made opaque by available bandwidth statistics... There are no distribution statistics available at all. Instead bandwidth stats are always aggregated as a regional average, and worse those samples tend to be from voluntary subset (at least in my country). Even when the median is used, it conceals a significant bandwidth divide due to communication technology gaps. The bandwidth distribution could be roughly inferred more accurately by grouping the averages by communication technology rather than region - this way a large number of very poor bandwidth users aren't concealed by a handful of super fast gigabit fiber connections or a marginal majority of fiber connections. There's a huge number of households still stuck with ADSL, 100% fiber is a very long way off (will probably never have full coverage, expecting LTE to fill this gap) and there is a huge gap between these technologies. To compound this issue households have to share connections between multiple people and increasingly hungry devices that don't respect users data usage (looking at Apple's massive inefficient update images in particular).

wil421 4y ago

This is why I am convinced part of the reason Google and Facebook create JS frameworks is so they can move computation out their data centers and onto your computer.

helloguillecl 4y ago
I think that is in the case of Facebook they were trying to solve their own use case, and in the case of Google, they saw it as a way of strengthening the strategic position of the web in general vs apps.
hiptobecubic 4y ago
Eh, i think you're thinking too small here. This whole thread is full of people saying things like, "When _I'm_ building a webapp," and "_My_ projects end up loading slowly," etc. Google is saying things like, "When 400 people are working on a web app, how can we avoid it turning into a shit show."

no_wizard 4y ago

It should all be down the applications need for client side interactions. Even with hotwire/turboframes, phoenix liveview or other websocket / real time server driven update patterns, it can be suboptimal for many catagories of applications as these rely on (albeit smart) whole replacement of DOM nodes. In heavy applications, or applications that have a lot of represented state, its not the panacea it might seem at first glance. I always tell people, "mileage may vary, there's no silver bullets in this industry". I think it holds true especially when talking about stuff like this.

helloguillecl 4y ago
One thing is to have JS for client-side interactivity, and another thing is to generate the entire HTML using javascript by sending both the data and javascript bundles to the client.
- no_wizard 4y ago
  Incremental rehydration techniques make this much much less of an issue (React 18 supports this now, IIRC, for instance). The tl;dr is that if you employ SSG or SSR you won't endup up with immediate re-hydrating once the client loads up, but only when something triggers the need for re-hydration, like a button click. That to me seems like the sweet spot for highly interactive applications that are very stateful, however like I said previously, your mileage may vary.

candiddevmike 4y ago

Streaming section by section of a frontend sounds like a troubleshooting nightmare. Users expect an interactive experience with a website. That means JavaScript. Anything else is going to be more complex.

alttab 4y ago
"users expect an interactive experience with a website" - I think this is a generalization that is getting a lot of web developers into needlessly complex toolchains and frameworks. When I'm in a browser, 99% of the time I expect the page to have what I'm looking for. I rarely care if its interactive. In fact, the more interactive it is, the less enjoyable the experience is. This holds even firmer when I'm on a desktop.
- kitsunesoba 4y ago
  I tend to agree. It’s frustrating whenever whatever nugget of information I’m seeking is buried under multiple clicks (navigation, collapsible sections, modals, popovers, etc) and even worse when one or more of those clicks results in a loading spinner that takes longer to play its fade in transition than it would’ve taken to load an entire static page.
gamblor956 4y ago
No, regular users definitely prefer web pages over interactive websites. With webpages, any delays make intuitive sense and are accepted by the user. With an interactive web app, the web app gets blamed for any delays or latency because there is no full-page refresh.

noud 4y ago

The more I work with advanced JS frameworks, the more I think I could also have done it with just vanilla javascript (with some jquery). Webapps I made 10 years ago where no less responsive than the webapps I make now. Nor do they take more time to create. The only difference is the size of the applications. They significantly increase with all overhead of frameworks. I wouldn't be surprised when webapp development will return partly to what it was a decade ago, where small (stand-alone) libraries are preferred to these huge, batteries-included, frameworks. edit: With some exceptions. Some webapps are huge. They are near impossible to program without a solid framework. But this is no more than 5% of all the webapps I create.

lukevp 4y ago
React and react-dom are < 100kb compressed, which is pretty much how big jquery is. Preact is even smaller. Which framework are you talking about that’s huge and batteries-included? if you want to drop react in a script tag and write JS that’s compatible with all browsers, you can do that too.
- fwip 4y ago
  I got curious and looked it up, looks like Jquery is about 30kb compressed & minified nowadays: https://mathiasbynens.be/demo/jquery-size https://mathiasbynens.be/demo/jquery-size
- helloguillecl 4y ago
  If you are running a client side app generally you’ll need many other libraries as well. Just to name a few: GraphQL, i18n, Google Firebase, Date parser/formatter, Numbers, etc.
  - nawgz 4y ago
    > GraphQL What libraries does this require? I'm just issuing fetch requests and getting back JSON. Apollo is absolutely NOT EVEN CLOSE TO required to do GQL... Honestly, both GraphQL and everything else listed seems pretty orthogonal to the original discussion of frameworks... Whether you used VanillaJS or React or a server-rendering platform, your choices of internationalization & datastores & auth & functionality require code...

aledalgrande 4y ago

I think NextJS + React server components would work pretty well for your idea of UX, while maintaining that powerful and flexible DX React has. https://vercel.com/blog/everything-about-react-server-components https://vercel.com/blog/everything-about-react-server-compon...

helloguillecl 4y ago
I think NextJS is the best frontend implementation I came across.

_fat_santa 4y ago

What I realized a while back is web development has split into two "routes": building websites and building webapps and I think part of the problem is those two often get conflated. With a website, the idea is a visitor might only visit a single page. Under this model you want to ship as little JS as possible, and ensure that if the user just tries to read a blog post, the entire site isn't getting downloaded. Contrast that with a webapp. I'm currently building a real estate investment calculator/dashboard and the mental model is diametrically different than building a website. Unlike a site, I want the entire app to be loaded upfront because the user is using the "entire" app, not just viewing a page. The problem I see is when one is trying to design a "site" but uses the "app" model, or vice versa. Attempt to use an SSR framework like NextJS for an "app" and you are going to have a bad time, likewise try setting up a site like you would a webapp and you are going to have some pretty serious limitations.

davidguetta 4y ago
What country are you from ? I've been doing exactly this in the past year so maybe we could compare / chat about our stuff.
clarle 4y ago
This is it. Another thing with a webapp that someone might use regularly is that the JavaScript bundle that's sent down is cached and you likely won't have that same load time every single time. However, if you have a landing page that someone might only visit once, then you want to optimize for as little JavaScript as possible, and in that case, just a pure server-side render might be best for that job.
simonw 4y ago
I don't think this model actually works in practice, because mobile traffic vastly eclipses web traffic for almost every kind of web application. Tricks that work on desktop - where a web application might stay open in a browser tab for weeks at a time - don't apply on mobile. On mobile, I'm much more likely to drop into your app for a few minutes to achieve a single goal, then navigate away and un-load it again. So assuming that I'm going to pay that loading price once and then keep interacting with your application doesn't actually work - most of my interactions with your app will be a cold start, often with an empty cache too since browser caches on mobile devices (especially cheaper Android phones) are much smaller.

redmorphium 4y ago

This post isn't about a Javascript frontend, though. The author works very clearly on a Node.js server, and nothing from that gets shipped to a client/browser.

benbristow 4y ago

What about with something that runs in WebAssembly, like .NET's Blazor?

no_wizard 4y ago
if you think React is big, you'll be sad by the 2 MB mandatory runtime you have to download just to run your Blazor WASM code, which can add megabytes on top. That said, if your application is actually complex enough to warrant this upfront download cost, might make sense. YMMV as always EDIT: in case it wasn't obvious, I was talking about Blazor WASM not Blazor server
- protonbob 4y ago
  There are two ways to run blazor. I don't think the WASM version of blazor is the one you're talking about.
  - no_wizard 4y ago
    It most certainly is. As noted in thread: https://github.com/dotnet/aspnetcore/issues/41909 https://github.com/dotnet/aspnetcore/issues/41909

petee 4y ago

> After years of testing different JS frameworks and build systems, I became convinced that heavy Javascript frontends are generally a bad model for the web Funny, after only 5 minutes on any website i come to the same conclusion as a user :P

scotty79 4y ago

I wonder how fast could be something that just replaces everything in the browser, HTML, CSS, JS with just webasm and some reasonable UI engine.

nawgz 4y ago
HTML/CSS/JS IS a pretty reasonable UI engine. What tools have you seen that are lighter and allow you to express the same capabilities??
- scotty79 4y ago
  I haven't but I have trouble with Electron haters that seem to think everything else is better.

samstave 4y ago

sERIOUS question: Is there a method for testing a site that defines how much JS heavy FEs are? --- I have noticed a significant issue with speed on sites after upgrading my main machines, but dont know how to judge if its local or remote. I have a flagshit HP gaming machine, with the best laptop nvidia card on the market.... windows 11 (with a sister machine of same specs with linux) Ryzen 5K RTX 3070 blah blah... But the load times on these "gaming centric" machines are way slower than older, les spec'd machines... I cant tell where my bottle-neck is. How test this specific, in your opinion?

tomxor 4y ago

> Bandwidth is not the issue anymore, but latency. Bandwidth is also the issue, but most web devs or website owners don't seem to realise or care that most of the world is probably struggling with their page weight. Internet speeds are more disparate now than in the 90s, but this issue tends to be made opaque by available bandwidth statistics... There are no distribution statistics available at all. Instead bandwidth stats are always aggregated as a regional average, and worse those samples tend to be from voluntary subset (at least in my country). Even when the median is used, it conceals a significant bandwidth divide due to communication technology gaps. The bandwidth distribution could be roughly inferred more accurately by grouping the averages by communication technology rather than region - this way a large number of very poor bandwidth users aren't concealed by a handful of super fast gigabit fiber connections or a marginal majority of fiber connections. There's a huge number of households still stuck with ADSL, 100% fiber is a very long way off (will probably never have full coverage, expecting LTE to fill this gap) and there is a huge gap between these technologies. To compound this issue households have to share connections between multiple people and increasingly hungry devices that don't respect users data usage (looking at Apple's massive inefficient update images in particular).