4 ms·

IMO, phone apps changed users’ expectations for websites. They want the same interactivity on Facebook.com that they get on the Facebook app. Same with Kayak (o

IMO, phone apps changed users’ expectations for websites. They want the same interactivity on Facebook.com that they get on the Facebook app. Same with Kayak (or whatever travel site people use these days). Same with Google Maps. However, the vast majority of sites are totally fine as static pages, as long as the user has a fast connection that makes loading between pages imperceptible.

CaptArmchair 6y ago
Well, this goes even deeper. Historically, the Web started out as hypertext: static text documents which were interlinked. But right off the bat, there was this drive to create "Rich Web Applications": the browser as an alternate to applications which you don't need to install on a "gatekept" operating system (Windows and OSX). Flash, Silverlight, Java Web Applets,... All those browser plugins were exactly meant to achieve this. But none of them quite fully lived up to the potential of the idea. There's a good reason why Microsoft in the 90's wanted to dominate the browser market: because it was a potential threat to lose control over what users could or couldn't do with their computers. Things changed when mobile devices landed, and Google jumped into the browser market. Suddenly, building a web experience no longer wasn't as "trivial" as making sure your CSS worked on Explorer, Safari and Firefox. At the same time, the "Application Wars" moved into the mobile realm where there was this battle between "native applications" and "web based applications". The latter was the notion that you could get the same functionality without having to install an app from an app store on your device. Those dynamics of competition were - and still are - a driving force behind innovation that made browser engines ever more powerful and complex. "Front-end" as a dedicate discipline didn't truly exist before the 2010's. You were a web master, a web developer, a web designer or something of the sort. But as soon as that complexity did hit, "front end engineering" became a specialization. Where it is really a cottage industry build on top of those complex browser engines, API's and sprawling specifications. For better or worse. > However, the vast majority of sites are totally fine as static pages, as long as the user has a fast connection that makes loading between pages imperceptible. Exactly. And that's still a completely valid use case. The problem is how the industry has shoehorned an entire generation of front-end developers into believing that you need all those gizmo's to write HTML, CSS and JS. When you're a budding front-end engineer and you land your first job from your internship, you're not even going to question the tools used by your employer. You're just going to use them because all you see is a big black box of complexity and nobody explains the history that has created that box. I think that's why people will, like the author, ultimately drop out. When writing code for a living turns into this obligatory, rote exercise of juggling this mass of dependencies and complexity, with little to no time or authority to question why they need all this in the first place.
- danjac 6y ago
  > I think that's why people will, like the author, ultimately drop out. When writing code for a living turns into this obligatory, rote exercise of juggling this mass of dependencies and complexity, with little to no time or authority to question why they need all this in the first place. This is why I'm optimistic that some small companies or startups will look at this black box, go "nope" and look at simpler alternatives : maybe hotwire or htmx, or some other tech or architecture allows them to build the things they need to build quickly and efficiently and outpace their complexity-bound competition - much like Rails was the alternative back in 2004 to the J2EE behemoths of the day that the industry considered the "right" way to build a web app.
  - goodoldneon 6y ago
    I think it's more likely that faster CPUs will make CPU hog pages less noticeable. Companies keep making bloated pages but users will decreasingly care.
    - danjac 6y ago
      It's not about the cost of the end-user bloat (although that's a problem), but the cost of development and maintenance required by complex front-end frameworks and architectures.
rini17 6y ago
But that does not mean expectations of web users have to be thrown under the bus. Such as, you click on something by mistake and try to fix it by using Back button. With facebook nope, if you forgot to open the link in a new tab, the original view is irretrievably lost. You sometimes can't even scroll back to review something, whole page gets reloaded and it vanishes. Supposedly one-page apps are meant to improve latency and interactivity, but FB is slow as molasses and frustrating regardless.
- goodoldneon 6y ago
  FB's terrible back functionality is their own fault since libraries like React Router give you a ton of control over back/forward behavior. As for FB's slowness, SPAs are hard to do well when you have a lot of live data all over the page. You can get clever with optimistic backend calls and caching, but in the end you still have frequent state changes. Users want infinite scroll to be fast, so you need over-eager loading _in case_ they scroll. Add over-eager loading all over the page (in case they click on a user profile, in case they click on FB Marketplace, etc.) and you have a recipe for a CPU hog.

CaptArmchair 6y ago

Well, this goes even deeper. Historically, the Web started out as hypertext: static text documents which were interlinked. But right off the bat, there was this drive to create "Rich Web Applications": the browser as an alternate to applications which you don't need to install on a "gatekept" operating system (Windows and OSX). Flash, Silverlight, Java Web Applets,... All those browser plugins were exactly meant to achieve this. But none of them quite fully lived up to the potential of the idea. There's a good reason why Microsoft in the 90's wanted to dominate the browser market: because it was a potential threat to lose control over what users could or couldn't do with their computers. Things changed when mobile devices landed, and Google jumped into the browser market. Suddenly, building a web experience no longer wasn't as "trivial" as making sure your CSS worked on Explorer, Safari and Firefox. At the same time, the "Application Wars" moved into the mobile realm where there was this battle between "native applications" and "web based applications". The latter was the notion that you could get the same functionality without having to install an app from an app store on your device. Those dynamics of competition were - and still are - a driving force behind innovation that made browser engines ever more powerful and complex. "Front-end" as a dedicate discipline didn't truly exist before the 2010's. You were a web master, a web developer, a web designer or something of the sort. But as soon as that complexity did hit, "front end engineering" became a specialization. Where it is really a cottage industry build on top of those complex browser engines, API's and sprawling specifications. For better or worse. > However, the vast majority of sites are totally fine as static pages, as long as the user has a fast connection that makes loading between pages imperceptible. Exactly. And that's still a completely valid use case. The problem is how the industry has shoehorned an entire generation of front-end developers into believing that you need all those gizmo's to write HTML, CSS and JS. When you're a budding front-end engineer and you land your first job from your internship, you're not even going to question the tools used by your employer. You're just going to use them because all you see is a big black box of complexity and nobody explains the history that has created that box. I think that's why people will, like the author, ultimately drop out. When writing code for a living turns into this obligatory, rote exercise of juggling this mass of dependencies and complexity, with little to no time or authority to question why they need all this in the first place.

danjac 6y ago
> I think that's why people will, like the author, ultimately drop out. When writing code for a living turns into this obligatory, rote exercise of juggling this mass of dependencies and complexity, with little to no time or authority to question why they need all this in the first place. This is why I'm optimistic that some small companies or startups will look at this black box, go "nope" and look at simpler alternatives : maybe hotwire or htmx, or some other tech or architecture allows them to build the things they need to build quickly and efficiently and outpace their complexity-bound competition - much like Rails was the alternative back in 2004 to the J2EE behemoths of the day that the industry considered the "right" way to build a web app.
- goodoldneon 6y ago
  I think it's more likely that faster CPUs will make CPU hog pages less noticeable. Companies keep making bloated pages but users will decreasingly care.
  - danjac 6y ago
    It's not about the cost of the end-user bloat (although that's a problem), but the cost of development and maintenance required by complex front-end frameworks and architectures.

rini17 6y ago

But that does not mean expectations of web users have to be thrown under the bus. Such as, you click on something by mistake and try to fix it by using Back button. With facebook nope, if you forgot to open the link in a new tab, the original view is irretrievably lost. You sometimes can't even scroll back to review something, whole page gets reloaded and it vanishes. Supposedly one-page apps are meant to improve latency and interactivity, but FB is slow as molasses and frustrating regardless.

goodoldneon 6y ago
FB's terrible back functionality is their own fault since libraries like React Router give you a ton of control over back/forward behavior. As for FB's slowness, SPAs are hard to do well when you have a lot of live data all over the page. You can get clever with optimistic backend calls and caching, but in the end you still have frequent state changes. Users want infinite scroll to be fast, so you need over-eager loading _in case_ they scroll. Add over-eager loading all over the page (in case they click on a user profile, in case they click on FB Marketplace, etc.) and you have a recipe for a CPU hog.