6 ms·

Modern front end javascript frameworks are made to offload the compute from the server to the end user. This saves the company money while giving the end user a

Modern front end javascript frameworks are made to offload the compute from the server to the end user. This saves the company money while giving the end user a worse/slower experience and drained batteries. However when I point this out react zealots get angry but never hit back with good counter arguements. Blame Facebook and Google for starting this awful trend.

gandutraveler 5y ago
Exactly. A simple html page that can be served immediately requires UI framework engine load, multiple pre fetches, data calls and then the final render/re-renders. SSR/Hybrid does slightly better but still the time to first interaction is becoming worse every year.
tonyedgecombe 5y ago
Yes, I find it strange that the advocates of modern JavaScript based sites say they are faster when my experience as a user is the complete opposite, even on modern hardware.
tdeck 5y ago
While this is true, what compute does something like Twitter's UI really need? It's only displaying a list of short messages, which doesn't seem like a heavy task even for a netbook.
ChuckNorris89 5y ago
>Modern front end javascript frameworks are made to offload the compute from the server to the end user Which is why I roll my eyes every time someone recommends using vintage laptops from the days they were user upgradable (ThinkPads, MacBooks, etc) and scream from the top of the hills what a great experience that is and why everyone should join in on that. Yeah I get it, as a HW engineer and tech enthusiast and big right to repair advocate, I also appreciate how upgradable older machines were and how easy to repair they were and I still keep some old machines kicking around, but the modern web is simply a jarring experience on those old machines compared to the experience on modern machines with the latest processors that I cannot in good conscience recommend it to people, if they can afford something decent. If you live in Vim and the terminal and just use your laptop to SSH into stuff then yeah, they work just fine, but for consuming content on the modern web or heavy productivity tasks I can never recommend staying on vintage HW if your time has any value and if you can afford the upgrade to newer HW. It's just not a nice experience and with most web-devs using M1 class machines it doesn't look like things will improve for the users on less powerful hardware which I guess here lies the problem. In Hollywood/Netflix productions, video mastering is done on super accurate $50K monitors but they use in parallel a $300 Walmart grade TV, set to the shitty "Vivid" setting to make sure the final content also looks good on the average TV average consumers have in their homes. I think the same thing should be done in web development. Feel free to develop the front-end on your kitted out $6000 M1 MacBook Pros but testing should also be done on your average $500 Walmart laptop to check it runs well.
- snowwrestler 5y ago
  How often do you actually browse with old hardware? I have a 2009 MacBook Pro that I and my family use almost every day for basic web browsing. It has no trouble with Reddit, YouTube, Facebook, PBS Kids, even newspaper sites. We do block ads, which probably helps. Is it as fast as my M1 MacBook Air? No, of course not. Is it unusably slow? No.
  - ChuckNorris89 5y ago
    >How often do you actually browse with old hardware? On a daily basis. It's a matter of perspective in the end. I upgraded from a notebook with a 6th gen Intel chip which I thought was fine to a notebook with a 5th gen Ryzen and the difference blew me away and made me realize how sluggish things were on my older machine in comparison. There's nothing wrong per se with my old machine, on it's own it's fine, but the newer on is so much faster in comparison, it's night and day for me. For my parents the old machine is fine not it's own but they're coming from one with a core 2 quad so there's that perspective.
- YXNjaGVyZWdlbgo 5y ago
  It's fascinating how most of hackernews is arguing against making usable products for 70% of the internet users. Go on https://gs.statcounter.com/screen-resolution-stats https://gs.statcounter.com/screen-resolution-stats and look at the screen resolutions used in africa, india, china and most of the non developed world. Do you think these devices are in any means powerful? Let them eat Megabytes.
  - ChuckNorris89 5y ago
    >It's fascinating how most of hackernews is arguing against making usable products for 70% of the internet users. Don't know who you're referring to but I wasn't arguing against making usable products. I'm not even a web developer. I merely stated the facts grounded in the real world. Most of the web is dogshit slow. What is more likely to happen from the two: 1) Web-devs starting to optimize their code to run well on old hardware or 2) People upgrade to HW that can run the current web a little bit better. > used in africa, india, china and most of the non developed world. Do you think these devices are in any means powerful? I find it funny the moments the HN users try to shoe-horn the poverty of the third world into various arguments, as if that's somehow a consideration for most people in rich countries on how they conduct their lives. Spoiler alert, most people only care about what happens in their surrounding, and in their personal bubble, and that's it, and most app-devs and web-devs care about the userbase they can monetize the most, which is why some app devs, especially in the US, never port their apps to Android as well and are fine with only with the more affluent iOS majority userbase. So bringing up the third world poverty and inclusiveness in such contexts feels deeply ironic to me. Yeah, I'd like that too, that web-devs and app devs would not discriminate between iOS and Android and all websites would run great on older machines, but that's not the truth. The truth is that most websites developed in the west are not optimized property therefore heavily favor those with modern machines and some apps are even Apple exclusive to the detriment of those left out. I've seen Facebook offer Lite version of their mobile client and messaging apps but that's only due to their huge userbase in the developing world, which like ou said, owns mostly low-end devices.
AnIdiotOnTheNet 5y ago
Considering how ludicrously fast modern computers are, offloading your calculations to them (on its own) cannot possibly explain why web sites are so slow. Games routinely perform millions of trigonometry calculations in tens of milliseconds, web pages render some images and text! Edit: Ugh, yes, I know network is part of the equation. Parent specifically called out client-side rendering though and that's what I'm responding to.
- hammyhavoc 5y ago
  It's simple: websites aren't static like they used to be. CMS query a database for each page load, which is inefficient as hell for serving up what's essentially just an article with no interactive elements, hence the use of static site generators on top of a CMS, or CloudFlare Pages, or GitHub Pages.
  - deleted 5y ago
    [deleted]
  - zozbot234 5y ago
    You solve this by putting a static cache in front of your CMS. It's a very common web architecture. No need to offload anything to the client.
  - scarface74 5y ago
    When were websites that did anything, ever “static”? I was creating websites that had to read from a database in 2001.
    - hammyhavoc 5y ago
      This is the point: the overwhelming majority of websites, especially blogs, articles, and general information such as store info, services, portfolio, opening times et al, could all be static instead of running a database query on every page load. Caching on CMS like WordPress via plugins helps, but they still query a database on each page load. Ergo, the rise in popularity of static site generators even on top of WordPress. Not everything needs to read from a database for every page load. tl;dr, not all websites need to "do" anything other than serve static information, but the way in which websites are commonly created and served is piss-poor. Just because the served content is static files doesn't mean that a CMS can't generate it if users want a graphical editor in their browser, and still want their theme of choice.
jraph 5y ago
I don't think the problem is "offload[ing] the compute from the server to the end user". It's sending incredible bloat powered by inefficient frameworks and programming practices, and careless use of the bandwidth. There are frameworks and programming practices that allow doing the same things without burning people's computers and making people wait. Making people wait and burning their bandwidth and data plan is just disrespectful but nobody cares as long as the app works fine on the customer's new phone or laptop. I'm saying it as someone who does frontend development so it's not just guessing. I'm writing a Svelte SMS app whose whole frontend is 3 times less heavy than just React itself, and fast on underpowered hardware. I've also built a networked Scrabble game that's instantaneous on an iPad from 2010. I've not focused on performance. This stuff is not impossible to figure out. It's just that these apps don't need to produce and diff entire virtual doms on every mouse move, do not come with custom web fonts, do not embed an entire icon pack of which 10 icons are used, do not use a 100 kb CSS reset framework, do not use 4K images to draw buttons and do not bundle the whole npm planet to work. The amount of features provided by current browser engines is incredible and it is possible to build amazing things by embracing them without breaking a sweat. React and this state of the frontend world depress me. It's okay to do client side computation. Just don't do it by sending megabytes of interpreted code for that.
- scarface74 5y ago
  I agree with this take. Even though I avoid the clusterfuck of the front end ecosystem like the plague, I have a coworker who is a big proponent of Svelte and from what I’ve seen, it’s really well optimized. That being said, if I were a front end developer, I would look at the job openings and see most jobs ask for React experience and be more concerned with resume driven development.
  - jraph 5y ago
    It's clear that React is the winning framework currently, with probably Angular and Vue following. I would not blame anyone looking to be employed as a frontend developer to go with React. That's part of the problem and it's a vicious circle. And most people like React and I can understand that. It's easy to use and understand. At least at first (debugging subtle (performance or not) bugs related to React's model is… not always easy but these bugs usually arrive when your app is already big enough. This is probably true of any framework). What's more, most people are not that sensitive to performance and if they are, they might not be aware of React's problems before learning it and practicing (which is also true of any framework). And also, nobody is fired for picking React.
wusspuss 5y ago
>Modern front end javascript frameworks are made to offload the compute from the server to the end user. This saves the company money Does it? I doubt hiring people to produce dozens of megabytes of compressed (!) javascript costs less than the cpu cycles it takes to produce html, especially if that's succinct html, not said megabytes of diarrhea. And "people" here almost definitely does not mean "that one guy who makes the frontend" - no single human could ever produce such abomination. For one thing he just wouldn't have the time! And then if we're frank there are no traces of humanity in twitter's front end - only the pungent smell or festering corporate development.
Beltalowda 5y ago
> Modern front end javascript frameworks are made to offload the compute from the server to the end user. This saves the company money while giving the end user a worse/slower experience and drained batteries. I think it actually has a lot more to do with mobile. Back in the day you could just send everyone the same HTML/JS/CSS rendered on your server and it would work for everyone. Now things are more complicated: people want "native apps" on their Android and iOS and whatnot, and also want a "desktop" version and a "web version". So you build a "light" server API, and put a lot of logic in the frontend. Not to save money, but because all the frontend logic is different on every platform (and in different languages: JS on web, Java or Kotlin on Android, Obj-C or Swift on iOS). Mobile complicated these things a lot more than people realize.
- scarface74 5y ago
  But with mobile apps, you can cache more assets on the client and in the case if iOS, as much work as Apple does to optimize WebKit. Objective C/Swift is still much faster. Mobile apps are also more bloated than needed. But at least you only have to load them once. Then again, client side frameworks started taking off in 2012.
- wusspuss 5y ago
  >Back in the day you could just send everyone the same HTML/JS/CSS rendered on your server and it would work for everyone. HN itself works perfect on mobile or anywhere for that matter and is very lightweight. I don't think it's because they optimized it. They just didn't fuck with it. >Now things are more complicated: people want "native apps" on their Android and iOS Do people want those? I believe it's just companies shoving those down people's throats
jiscariot 5y ago
For HN, this is also an "I have seen the enemy and he is us" situation. I say this with love, but judging from every week threads talking about half-million total comp at FANGs, there is probably no internet forum more responsible for the state and direction of the modern web than HN.
Abishek_Muthian 5y ago
With Mega Corporations themselves changing back to server side rendering due to the slow web frameworks like React, your reasoning stands vindicated.[1] As a side note, I would also like to mention that OP in spite of having probably the fastest hand held computer wasn't able to mitigate some of the issues of the web like useless scripts, Ads etc. because Apple doesn't provide that control to the users; Where an android at fraction of the cost with Firefox and UBlock Origin/No Script could have provided a better web experience. [1] https://twitter.com/amilajack/status/1484970825568505856 https://twitter.com/amilajack/status/1484970825568505856

gandutraveler 5y ago

Exactly. A simple html page that can be served immediately requires UI framework engine load, multiple pre fetches, data calls and then the final render/re-renders. SSR/Hybrid does slightly better but still the time to first interaction is becoming worse every year.

tonyedgecombe 5y ago

Yes, I find it strange that the advocates of modern JavaScript based sites say they are faster when my experience as a user is the complete opposite, even on modern hardware.

tdeck 5y ago

While this is true, what compute does something like Twitter's UI really need? It's only displaying a list of short messages, which doesn't seem like a heavy task even for a netbook.

ChuckNorris89 5y ago

>Modern front end javascript frameworks are made to offload the compute from the server to the end user Which is why I roll my eyes every time someone recommends using vintage laptops from the days they were user upgradable (ThinkPads, MacBooks, etc) and scream from the top of the hills what a great experience that is and why everyone should join in on that. Yeah I get it, as a HW engineer and tech enthusiast and big right to repair advocate, I also appreciate how upgradable older machines were and how easy to repair they were and I still keep some old machines kicking around, but the modern web is simply a jarring experience on those old machines compared to the experience on modern machines with the latest processors that I cannot in good conscience recommend it to people, if they can afford something decent. If you live in Vim and the terminal and just use your laptop to SSH into stuff then yeah, they work just fine, but for consuming content on the modern web or heavy productivity tasks I can never recommend staying on vintage HW if your time has any value and if you can afford the upgrade to newer HW. It's just not a nice experience and with most web-devs using M1 class machines it doesn't look like things will improve for the users on less powerful hardware which I guess here lies the problem. In Hollywood/Netflix productions, video mastering is done on super accurate $50K monitors but they use in parallel a $300 Walmart grade TV, set to the shitty "Vivid" setting to make sure the final content also looks good on the average TV average consumers have in their homes. I think the same thing should be done in web development. Feel free to develop the front-end on your kitted out $6000 M1 MacBook Pros but testing should also be done on your average $500 Walmart laptop to check it runs well.

snowwrestler 5y ago
How often do you actually browse with old hardware? I have a 2009 MacBook Pro that I and my family use almost every day for basic web browsing. It has no trouble with Reddit, YouTube, Facebook, PBS Kids, even newspaper sites. We do block ads, which probably helps. Is it as fast as my M1 MacBook Air? No, of course not. Is it unusably slow? No.
- ChuckNorris89 5y ago
  >How often do you actually browse with old hardware? On a daily basis. It's a matter of perspective in the end. I upgraded from a notebook with a 6th gen Intel chip which I thought was fine to a notebook with a 5th gen Ryzen and the difference blew me away and made me realize how sluggish things were on my older machine in comparison. There's nothing wrong per se with my old machine, on it's own it's fine, but the newer on is so much faster in comparison, it's night and day for me. For my parents the old machine is fine not it's own but they're coming from one with a core 2 quad so there's that perspective.
YXNjaGVyZWdlbgo 5y ago
It's fascinating how most of hackernews is arguing against making usable products for 70% of the internet users. Go on https://gs.statcounter.com/screen-resolution-stats https://gs.statcounter.com/screen-resolution-stats and look at the screen resolutions used in africa, india, china and most of the non developed world. Do you think these devices are in any means powerful? Let them eat Megabytes.
- ChuckNorris89 5y ago
  >It's fascinating how most of hackernews is arguing against making usable products for 70% of the internet users. Don't know who you're referring to but I wasn't arguing against making usable products. I'm not even a web developer. I merely stated the facts grounded in the real world. Most of the web is dogshit slow. What is more likely to happen from the two: 1) Web-devs starting to optimize their code to run well on old hardware or 2) People upgrade to HW that can run the current web a little bit better. > used in africa, india, china and most of the non developed world. Do you think these devices are in any means powerful? I find it funny the moments the HN users try to shoe-horn the poverty of the third world into various arguments, as if that's somehow a consideration for most people in rich countries on how they conduct their lives. Spoiler alert, most people only care about what happens in their surrounding, and in their personal bubble, and that's it, and most app-devs and web-devs care about the userbase they can monetize the most, which is why some app devs, especially in the US, never port their apps to Android as well and are fine with only with the more affluent iOS majority userbase. So bringing up the third world poverty and inclusiveness in such contexts feels deeply ironic to me. Yeah, I'd like that too, that web-devs and app devs would not discriminate between iOS and Android and all websites would run great on older machines, but that's not the truth. The truth is that most websites developed in the west are not optimized property therefore heavily favor those with modern machines and some apps are even Apple exclusive to the detriment of those left out. I've seen Facebook offer Lite version of their mobile client and messaging apps but that's only due to their huge userbase in the developing world, which like ou said, owns mostly low-end devices.

AnIdiotOnTheNet 5y ago

Considering how ludicrously fast modern computers are, offloading your calculations to them (on its own) cannot possibly explain why web sites are so slow. Games routinely perform millions of trigonometry calculations in tens of milliseconds, web pages render some images and text! Edit: Ugh, yes, I know network is part of the equation. Parent specifically called out client-side rendering though and that's what I'm responding to.

hammyhavoc 5y ago
It's simple: websites aren't static like they used to be. CMS query a database for each page load, which is inefficient as hell for serving up what's essentially just an article with no interactive elements, hence the use of static site generators on top of a CMS, or CloudFlare Pages, or GitHub Pages.
- deleted 5y ago
  [deleted]
- zozbot234 5y ago
  You solve this by putting a static cache in front of your CMS. It's a very common web architecture. No need to offload anything to the client.
- scarface74 5y ago
  When were websites that did anything, ever “static”? I was creating websites that had to read from a database in 2001.
  - hammyhavoc 5y ago
    This is the point: the overwhelming majority of websites, especially blogs, articles, and general information such as store info, services, portfolio, opening times et al, could all be static instead of running a database query on every page load. Caching on CMS like WordPress via plugins helps, but they still query a database on each page load. Ergo, the rise in popularity of static site generators even on top of WordPress. Not everything needs to read from a database for every page load. tl;dr, not all websites need to "do" anything other than serve static information, but the way in which websites are commonly created and served is piss-poor. Just because the served content is static files doesn't mean that a CMS can't generate it if users want a graphical editor in their browser, and still want their theme of choice.

jraph 5y ago

I don't think the problem is "offload[ing] the compute from the server to the end user". It's sending incredible bloat powered by inefficient frameworks and programming practices, and careless use of the bandwidth. There are frameworks and programming practices that allow doing the same things without burning people's computers and making people wait. Making people wait and burning their bandwidth and data plan is just disrespectful but nobody cares as long as the app works fine on the customer's new phone or laptop. I'm saying it as someone who does frontend development so it's not just guessing. I'm writing a Svelte SMS app whose whole frontend is 3 times less heavy than just React itself, and fast on underpowered hardware. I've also built a networked Scrabble game that's instantaneous on an iPad from 2010. I've not focused on performance. This stuff is not impossible to figure out. It's just that these apps don't need to produce and diff entire virtual doms on every mouse move, do not come with custom web fonts, do not embed an entire icon pack of which 10 icons are used, do not use a 100 kb CSS reset framework, do not use 4K images to draw buttons and do not bundle the whole npm planet to work. The amount of features provided by current browser engines is incredible and it is possible to build amazing things by embracing them without breaking a sweat. React and this state of the frontend world depress me. It's okay to do client side computation. Just don't do it by sending megabytes of interpreted code for that.

scarface74 5y ago
I agree with this take. Even though I avoid the clusterfuck of the front end ecosystem like the plague, I have a coworker who is a big proponent of Svelte and from what I’ve seen, it’s really well optimized. That being said, if I were a front end developer, I would look at the job openings and see most jobs ask for React experience and be more concerned with resume driven development.
- jraph 5y ago
  It's clear that React is the winning framework currently, with probably Angular and Vue following. I would not blame anyone looking to be employed as a frontend developer to go with React. That's part of the problem and it's a vicious circle. And most people like React and I can understand that. It's easy to use and understand. At least at first (debugging subtle (performance or not) bugs related to React's model is… not always easy but these bugs usually arrive when your app is already big enough. This is probably true of any framework). What's more, most people are not that sensitive to performance and if they are, they might not be aware of React's problems before learning it and practicing (which is also true of any framework). And also, nobody is fired for picking React.

wusspuss 5y ago

>Modern front end javascript frameworks are made to offload the compute from the server to the end user. This saves the company money Does it? I doubt hiring people to produce dozens of megabytes of compressed (!) javascript costs less than the cpu cycles it takes to produce html, especially if that's succinct html, not said megabytes of diarrhea. And "people" here almost definitely does not mean "that one guy who makes the frontend" - no single human could ever produce such abomination. For one thing he just wouldn't have the time! And then if we're frank there are no traces of humanity in twitter's front end - only the pungent smell or festering corporate development.

Beltalowda 5y ago

> Modern front end javascript frameworks are made to offload the compute from the server to the end user. This saves the company money while giving the end user a worse/slower experience and drained batteries. I think it actually has a lot more to do with mobile. Back in the day you could just send everyone the same HTML/JS/CSS rendered on your server and it would work for everyone. Now things are more complicated: people want "native apps" on their Android and iOS and whatnot, and also want a "desktop" version and a "web version". So you build a "light" server API, and put a lot of logic in the frontend. Not to save money, but because all the frontend logic is different on every platform (and in different languages: JS on web, Java or Kotlin on Android, Obj-C or Swift on iOS). Mobile complicated these things a lot more than people realize.

scarface74 5y ago
But with mobile apps, you can cache more assets on the client and in the case if iOS, as much work as Apple does to optimize WebKit. Objective C/Swift is still much faster. Mobile apps are also more bloated than needed. But at least you only have to load them once. Then again, client side frameworks started taking off in 2012.
wusspuss 5y ago
>Back in the day you could just send everyone the same HTML/JS/CSS rendered on your server and it would work for everyone. HN itself works perfect on mobile or anywhere for that matter and is very lightweight. I don't think it's because they optimized it. They just didn't fuck with it. >Now things are more complicated: people want "native apps" on their Android and iOS Do people want those? I believe it's just companies shoving those down people's throats

jiscariot 5y ago

For HN, this is also an "I have seen the enemy and he is us" situation. I say this with love, but judging from every week threads talking about half-million total comp at FANGs, there is probably no internet forum more responsible for the state and direction of the modern web than HN.

Abishek_Muthian 5y ago

With Mega Corporations themselves changing back to server side rendering due to the slow web frameworks like React, your reasoning stands vindicated.[1] As a side note, I would also like to mention that OP in spite of having probably the fastest hand held computer wasn't able to mitigate some of the issues of the web like useless scripts, Ads etc. because Apple doesn't provide that control to the users; Where an android at fraction of the cost with Firefox and UBlock Origin/No Script could have provided a better web experience. [1] https://twitter.com/amilajack/status/1484970825568505856 https://twitter.com/amilajack/status/1484970825568505856