8 ms·

Yes, demonstrably and provably. Count the number of pageload indicators (spinners, throbbers...whatever you like to call them) in your daily browsing. They are

Yes, demonstrably and provably. Count the number of pageload indicators (spinners, throbbers...whatever you like to call them) in your daily browsing. They are everywhere...now. AJAX (and, I suspect, the shadown DOM model) have proliferated in recent years, and there is no site design simple enough that someone hasn't thought to put every page element behind a JS call. Don't forget to put CSS in there, too! Frontend developers are at fault for all this. There, I said it.

dahfizz 6y ago
It's a culture problem in the web dev world. There is an obsession with new and shiny and building something "cool". It's all about the developer experience and not the product. That's why there's such insane churn in the tooling and ecosystem. People rewrite and redesign constantly in order to work with the new cool framework.
- namuol 6y ago
  Insane churn? Wordpress powers over 1/3 of the web. JQuery is still doing most heavy JS lifting on most blogs/CMS-driven sites. React has dominated "real" frontend webapp development for a solid 5 years. These things don't make headlines or get retweeted. The web produces a lot of variety because it has the widest distribution and the lowest barriers to entry.
  - kulig 6y ago
    5 years is not a lot of time.
    - namuol 6y ago
      I think we can count on it to be around for awhile: https://www.npmtrends.com/@angular/core-vs-react-vs-vue https://www.npmtrends.com/@angular/core-vs-react-vs-vue
  - LargoLasskhyfv 6y ago
    I can do very well without some of that variety. Sometimes barriers to entry are a good thing.
    - namuol 6y ago
      Not sure what you mean. You're welcome to hand-write all of your web apps from the ground up with zero dependencies and no build system. It's still the web.
- ericwood 6y ago
  This gets parroted a lot around here but the last 5 years or so there's really only been a few major players in the framework space. Maybe the "framework of the day" mentality was pretty strong in the early 2010's but things have cooled off significantly since then and you'd be hard-pressed to find most shops using more than the big 3-4 contenders.
  - RandoHolmes 6y ago
    My experience is that it's just as relevant today. I had a front-end developer come in and add node, bootstrap, and SCSS as a dependency to a very simple app. We went from having a super simple build chain to one that now needed maintenance. And part of his argument? he "thought better" in SCSS. People have zero respect for the risk of dependencies, complicating the buildchain, or long term maintenance.
    - pbalau 6y ago
      It's a combination of arrogance, lack of skill and sheer stupidity. For an example, look at nuxtjs docs, there is an example config, that everyone seem to use, that lints on each build. Because code using 4 spaces indentation is slower than code using 2 spaces... The last ui dev I had to work with managed to produce in about 1 year a very complicated dockerfile, that was spewing, between other things, an image for e2e testing - but no actual tests and you needed a huge makefile to actually build the thing, a soup of copy-pasted config files that resulted in a vendors.js bundle of about 100 megs - there were more config files than source code, 2 branches named <username>.wip.somedate with commits that commented out some parts of a config, just to uncomment them back in the next commit. The app itself, with ssr no less, was a logo and some text, that was using some custom components, built with some third party vue component that was rendering css in js, thus you had to wait for the entire vendors.js to download before you got anything rendered. His answer to anyone questioning his choices was "this is how modern ux development works". After he was let go, I took over the ui and along with another coworker we managed to have a working version of the app in 9 days, with no prior knowledge of vuejs and nuxtjs. You can imagine how complicated the app is...
    - ericwood 6y ago
namuol 6y ago
> Frontend developers are at fault for all this. There, I said it. Let me trade one dead horse for another: Product and marketing teams are at fault for all this. Or if you prefer, the advertising industry is at fault. Take the payload of any typical blog or (God help you) your small-town newspaper website and count how many requests correspond to the actual content. Now ask yourself, who's paying someone to bloat this website, and why?
- fibers 6y ago
  'i was only following orders'
  - namuol 6y ago
    Most people, web developers included, don't have the luxury to quit their job every time they disagree with the decisions being made for them.
- lhorie 6y ago
  Eh. If one wants to play the blame game, we can be here all day. The marketing dept asking to add sharing widgets are to blame. The team lead pushing for Squarespace so they can get away hiring junior devs under them is to blame. The frontend dev using half of the React ecosystem on a static site + simple form is to blame. The designer insisting on huge eye candy images is to blame. The UX person set on adding a carousel is to blame. The project manager prioritizing feature count is to blame. Etc etc etc. The bottom line is that nobody really has any strong incentives to advocate for performance, so it falls by the sidelines.
  - mpoteat 6y ago
    Maybe the users are too blame as they measurably prefer websites with modern UX and don't really care about latency over a few hundred milliseconds.
    - searchableguy 6y ago
dijit 6y ago
I didn’t touch “web dev” since php/dream-weaver/myspace era. I started working with some web developers for a simple project recently, my mock product was built with vue.js using the standard way of “including” it: But what really threw me for a loop was that the web developers told me that that’s wrong, they are now _compiling_ (Or, semantically “packing”) JavaScript blobs to make even very simple websites. I don’t know why we as a community have started doing that, but it feels like an anti-pattern, it makes adding new dependencies opaque and we can very quickly end up including dozens and dozens of lines of code which must all be rendered by every device that comes into contact with my site. Often this happens because we want only a small bit of the functionality too.
- RandoHolmes 6y ago
  100% with you there. I personally think it's a bit insane to add node.js as a dependency to a simple PHP project.
  - WrtCdEvrydy 6y ago
    To be honest, we've seen this in Rails and PHP in the form of grunt.
- WrtCdEvrydy 6y ago
  Wait till someone wants to add JS polyfills for everything...
- lukeramsden 6y ago
  > Often this happens because we want only a small bit of the functionality too. To be fair, this 'compiling' also allows for tree shaking, which if you use a well-structured library like lodash/date-fns etc, allows you to get that small bit of functionality without paying for the whole library.
- sanitycheck 6y ago
  So.. There are benefits to this for complex apps - but 90% (charitably) of this kind of code is not in a complex app. I think it's for two main reasons: 1. If you don't use complicated new technology you won't get a job doing web dev. 2. Many new JS devs don't understand JS/HTML/CSS well, they only understand a particular framework - and even then not in a sufficiently deep way. When you come across a seemingly normal site that requires JS in order to display anything, it's pretty unlikely that anyone involved ever considered not doing it that way.
deleted 6y ago
[deleted]
starik36 6y ago
> Frontend developers are at fault for all this As a recent front end dev, I fought tooth and nail not to include all kinds of tracking drek into the company's site. I lost every time because management overruled me. At some point, it occurred to me that it's not my site and I shouldn't be taking personally that which doesn't belong to me.
- cblconfederate 6y ago
  this is not about tracking though. Even with an ad blocker, just about every website and blog now presents multiple spinning boxes when its loading. This is unnecessary , timewasting, environmentally unfriendly programming. And yes , 100% of the time it s devs that choose to build a site this way. It's come to the point where i feel bad for using plain old single-request-loading html, because it doesn't look 'spinny' enough, and users may think it's uncool.
  - sozy777 6y ago
    If business wants something quick and the cost of the website being slow doesn't matter... Why bother? On the other side, I've been building websites that gets +95 on mobile on Google page speed. If no image above the fold... It gets 100. In mobile, yes. And I still have analytics, YouTube and images... So I'd say depends by what business needs.
  - namuol 6y ago
    > just about every website and blog now presents multiple spinning boxes when its loading The vast majority of "page" content is baked into prerendered HTML and CSS rendered. I'm not sure what spinners you're talking about unless you're referring to web apps with timelines/news feeds that dynamically load. Users love sites that load the important content and are interactive ASAP. Trust me, they appreciate your boring (fast) HTML.
    - zwaps 6y ago
      see my above comment in this thread for a counter-example.
deleted 6y ago
[deleted]
1vuio0pswjnm7 6y ago
An old colleague of mine in the 90's used to say "Software is like a gas. It expands to fill available space." The behaviour of desktop software developers in 1990's was a prelude to web frontend and app developers today. As the resource capacity of PC's increased through the 90's, software developers grabbed it for themselves; for the end user, the experience of using the software never got any faster. As the storage, processing power and network speeds have increased, web frontend and app developers seem to have grabbed it for themselves as well; the end user experience has generally not gotten faster (if the user follows the instructions: use popular, Javascript-enabled browser, enable images, video). In the 1990's, users were asked to upgrade their computers so they could run the new, larger but not experientally faster, desktop software. Today, we see the same sort of OS and device upgrades; "unsupported" versions of software that will not run on newer version of the OS. Plus we have a culture of allowing automatic, remotely-controlled installation of new software. Automatic upgrades. Telemetry. "Field testing" of new features. A sizeable amount of user choice and necessity for user consent has been successfully eliminated. The number of outgoing TCP connections made by today's average websites, usually triggered through cascades of Javascript files, is simply staggering. It would never have been acceptable to do that with the networks and server software of the 1990's and 2000's. Users were not involved in the decision of developers to grab the newly available network resources and CPU for themselves. I do not use a popular browser for most web use. This allows me to only make a single TCP connection to a website when I access it and can retrieve dozens or hundreds of pages over a single connection, thanks to old, standard features of the web documented in RFCs (pipelining). It is very fast and efficient. For me, the web has gotten much faster, but only because I choose the software and I decide whether and when to upgrade. It is my computer, after all. I am not really impressed by the popular browsers of today because it does not feel at all like the user is in control. Users of these programs have been reduced to guinea pigs.
- nine_k 6y ago
  Product managers add features and/or speed up development by using more resource-hungry runtimes up to the point where the users still tolerate the performance but barely so. Once the product has enough traction and switching costs, the user would rather tolerate the mild pain of slowness than the more acute pain of switching and adapting to a (so far) faster competitor. This is very much like the idea of the optimal price point where the customer already cringes but still buys.
deleted 6y ago
[deleted]
Kiro 6y ago
No, the article demonstrably and provably shows you why you're wrong.
onion2k 6y ago
Frontend developers are at fault for all this. There, I said it. Is it frontend devs who are putting Turbolinks in Rails apps then?
zwaps 6y ago
Here is my favorite example of "put every page element behind a JS call": https://www.scmp.com/ https://www.scmp.com/ A news site. It does precisely the same thing as news sites did a decade ago. On my machine, it loads slowly. Then, it needs to re-load every time you scroll. It's extremely slow. Indeed, on Firefox, it doesn't load everything consistently. If you click on an article, things get even worse because it needs to reload text when you scroll. This website is what I would call "barely usable". Let me reiterate: This site does nothing new compared to old news websites. There is zero benefit to the user. It simply is slow. I don't know who is to blame for this. But if even your text loads slow, you are building a bad website. I am sure, some frontend developer got paid for making this website. I am not sure they should have been.

dahfizz 6y ago

It's a culture problem in the web dev world. There is an obsession with new and shiny and building something "cool". It's all about the developer experience and not the product. That's why there's such insane churn in the tooling and ecosystem. People rewrite and redesign constantly in order to work with the new cool framework.

namuol 6y ago
Insane churn? Wordpress powers over 1/3 of the web. JQuery is still doing most heavy JS lifting on most blogs/CMS-driven sites. React has dominated "real" frontend webapp development for a solid 5 years. These things don't make headlines or get retweeted. The web produces a lot of variety because it has the widest distribution and the lowest barriers to entry.
- kulig 6y ago
  5 years is not a lot of time.
  - namuol 6y ago
    I think we can count on it to be around for awhile: https://www.npmtrends.com/@angular/core-vs-react-vs-vue https://www.npmtrends.com/@angular/core-vs-react-vs-vue
- LargoLasskhyfv 6y ago
  I can do very well without some of that variety. Sometimes barriers to entry are a good thing.
  - namuol 6y ago
    Not sure what you mean. You're welcome to hand-write all of your web apps from the ground up with zero dependencies and no build system. It's still the web.
ericwood 6y ago
This gets parroted a lot around here but the last 5 years or so there's really only been a few major players in the framework space. Maybe the "framework of the day" mentality was pretty strong in the early 2010's but things have cooled off significantly since then and you'd be hard-pressed to find most shops using more than the big 3-4 contenders.
- RandoHolmes 6y ago
  My experience is that it's just as relevant today. I had a front-end developer come in and add node, bootstrap, and SCSS as a dependency to a very simple app. We went from having a super simple build chain to one that now needed maintenance. And part of his argument? he "thought better" in SCSS. People have zero respect for the risk of dependencies, complicating the buildchain, or long term maintenance.
  - pbalau 6y ago
    It's a combination of arrogance, lack of skill and sheer stupidity. For an example, look at nuxtjs docs, there is an example config, that everyone seem to use, that lints on each build. Because code using 4 spaces indentation is slower than code using 2 spaces... The last ui dev I had to work with managed to produce in about 1 year a very complicated dockerfile, that was spewing, between other things, an image for e2e testing - but no actual tests and you needed a huge makefile to actually build the thing, a soup of copy-pasted config files that resulted in a vendors.js bundle of about 100 megs - there were more config files than source code, 2 branches named <username>.wip.somedate with commits that commented out some parts of a config, just to uncomment them back in the next commit. The app itself, with ssr no less, was a logo and some text, that was using some custom components, built with some third party vue component that was rendering css in js, thus you had to wait for the entire vendors.js to download before you got anything rendered. His answer to anyone questioning his choices was "this is how modern ux development works". After he was let go, I took over the ui and along with another coworker we managed to have a working version of the app in 9 days, with no prior knowledge of vuejs and nuxtjs. You can imagine how complicated the app is...
  - ericwood 6y ago

namuol 6y ago

> Frontend developers are at fault for all this. There, I said it. Let me trade one dead horse for another: Product and marketing teams are at fault for all this. Or if you prefer, the advertising industry is at fault. Take the payload of any typical blog or (God help you) your small-town newspaper website and count how many requests correspond to the actual content. Now ask yourself, who's paying someone to bloat this website, and why?

fibers 6y ago
'i was only following orders'
- namuol 6y ago
  Most people, web developers included, don't have the luxury to quit their job every time they disagree with the decisions being made for them.
lhorie 6y ago
Eh. If one wants to play the blame game, we can be here all day. The marketing dept asking to add sharing widgets are to blame. The team lead pushing for Squarespace so they can get away hiring junior devs under them is to blame. The frontend dev using half of the React ecosystem on a static site + simple form is to blame. The designer insisting on huge eye candy images is to blame. The UX person set on adding a carousel is to blame. The project manager prioritizing feature count is to blame. Etc etc etc. The bottom line is that nobody really has any strong incentives to advocate for performance, so it falls by the sidelines.
- mpoteat 6y ago
  Maybe the users are too blame as they measurably prefer websites with modern UX and don't really care about latency over a few hundred milliseconds.
  - searchableguy 6y ago

dijit 6y ago

I didn’t touch “web dev” since php/dream-weaver/myspace era. I started working with some web developers for a simple project recently, my mock product was built with vue.js using the standard way of “including” it: But what really threw me for a loop was that the web developers told me that that’s wrong, they are now _compiling_ (Or, semantically “packing”) JavaScript blobs to make even very simple websites. I don’t know why we as a community have started doing that, but it feels like an anti-pattern, it makes adding new dependencies opaque and we can very quickly end up including dozens and dozens of lines of code which must all be rendered by every device that comes into contact with my site. Often this happens because we want only a small bit of the functionality too.

RandoHolmes 6y ago
100% with you there. I personally think it's a bit insane to add node.js as a dependency to a simple PHP project.
- WrtCdEvrydy 6y ago
  To be honest, we've seen this in Rails and PHP in the form of grunt.
WrtCdEvrydy 6y ago
Wait till someone wants to add JS polyfills for everything...
lukeramsden 6y ago
> Often this happens because we want only a small bit of the functionality too. To be fair, this 'compiling' also allows for tree shaking, which if you use a well-structured library like lodash/date-fns etc, allows you to get that small bit of functionality without paying for the whole library.
sanitycheck 6y ago
So.. There are benefits to this for complex apps - but 90% (charitably) of this kind of code is not in a complex app. I think it's for two main reasons: 1. If you don't use complicated new technology you won't get a job doing web dev. 2. Many new JS devs don't understand JS/HTML/CSS well, they only understand a particular framework - and even then not in a sufficiently deep way. When you come across a seemingly normal site that requires JS in order to display anything, it's pretty unlikely that anyone involved ever considered not doing it that way.

deleted 6y ago

[deleted]

starik36 6y ago

> Frontend developers are at fault for all this As a recent front end dev, I fought tooth and nail not to include all kinds of tracking drek into the company's site. I lost every time because management overruled me. At some point, it occurred to me that it's not my site and I shouldn't be taking personally that which doesn't belong to me.

cblconfederate 6y ago
this is not about tracking though. Even with an ad blocker, just about every website and blog now presents multiple spinning boxes when its loading. This is unnecessary , timewasting, environmentally unfriendly programming. And yes , 100% of the time it s devs that choose to build a site this way. It's come to the point where i feel bad for using plain old single-request-loading html, because it doesn't look 'spinny' enough, and users may think it's uncool.
- sozy777 6y ago
  If business wants something quick and the cost of the website being slow doesn't matter... Why bother? On the other side, I've been building websites that gets +95 on mobile on Google page speed. If no image above the fold... It gets 100. In mobile, yes. And I still have analytics, YouTube and images... So I'd say depends by what business needs.
- namuol 6y ago
  > just about every website and blog now presents multiple spinning boxes when its loading The vast majority of "page" content is baked into prerendered HTML and CSS rendered. I'm not sure what spinners you're talking about unless you're referring to web apps with timelines/news feeds that dynamically load. Users love sites that load the important content and are interactive ASAP. Trust me, they appreciate your boring (fast) HTML.
  - zwaps 6y ago
    see my above comment in this thread for a counter-example.

deleted 6y ago

[deleted]

1vuio0pswjnm7 6y ago

An old colleague of mine in the 90's used to say "Software is like a gas. It expands to fill available space." The behaviour of desktop software developers in 1990's was a prelude to web frontend and app developers today. As the resource capacity of PC's increased through the 90's, software developers grabbed it for themselves; for the end user, the experience of using the software never got any faster. As the storage, processing power and network speeds have increased, web frontend and app developers seem to have grabbed it for themselves as well; the end user experience has generally not gotten faster (if the user follows the instructions: use popular, Javascript-enabled browser, enable images, video). In the 1990's, users were asked to upgrade their computers so they could run the new, larger but not experientally faster, desktop software. Today, we see the same sort of OS and device upgrades; "unsupported" versions of software that will not run on newer version of the OS. Plus we have a culture of allowing automatic, remotely-controlled installation of new software. Automatic upgrades. Telemetry. "Field testing" of new features. A sizeable amount of user choice and necessity for user consent has been successfully eliminated. The number of outgoing TCP connections made by today's average websites, usually triggered through cascades of Javascript files, is simply staggering. It would never have been acceptable to do that with the networks and server software of the 1990's and 2000's. Users were not involved in the decision of developers to grab the newly available network resources and CPU for themselves. I do not use a popular browser for most web use. This allows me to only make a single TCP connection to a website when I access it and can retrieve dozens or hundreds of pages over a single connection, thanks to old, standard features of the web documented in RFCs (pipelining). It is very fast and efficient. For me, the web has gotten much faster, but only because I choose the software and I decide whether and when to upgrade. It is my computer, after all. I am not really impressed by the popular browsers of today because it does not feel at all like the user is in control. Users of these programs have been reduced to guinea pigs.

nine_k 6y ago
Product managers add features and/or speed up development by using more resource-hungry runtimes up to the point where the users still tolerate the performance but barely so. Once the product has enough traction and switching costs, the user would rather tolerate the mild pain of slowness than the more acute pain of switching and adapting to a (so far) faster competitor. This is very much like the idea of the optimal price point where the customer already cringes but still buys.

deleted 6y ago

[deleted]

Kiro 6y ago

No, the article demonstrably and provably shows you why you're wrong.

onion2k 6y ago

Frontend developers are at fault for all this. There, I said it. Is it frontend devs who are putting Turbolinks in Rails apps then?

zwaps 6y ago

Here is my favorite example of "put every page element behind a JS call": https://www.scmp.com/ https://www.scmp.com/ A news site. It does precisely the same thing as news sites did a decade ago. On my machine, it loads slowly. Then, it needs to re-load every time you scroll. It's extremely slow. Indeed, on Firefox, it doesn't load everything consistently. If you click on an article, things get even worse because it needs to reload text when you scroll. This website is what I would call "barely usable". Let me reiterate: This site does nothing new compared to old news websites. There is zero benefit to the user. It simply is slow. I don't know who is to blame for this. But if even your text loads slow, you are building a bad website. I am sure, some frontend developer got paid for making this website. I am not sure they should have been.