9 ms·

...get a PageSpeed score of 100/100 I'm slowly coming around to the idea that PageSpeed (or Lighthouse, or Core Web Vitals, or whatever Google has invented thi

...get a PageSpeed score of 100/100 I'm slowly coming around to the idea that PageSpeed (or Lighthouse, or Core Web Vitals, or whatever Google has invented this week) is what drives a lot of the complexity in web app dev. People refuse to throw out what they've learned, so every time there's a new metric to chase in case you lose SERPS ranking for being slow! devs heap another layer of complexity on to the Webpack bonfire. Hydration is an example of this. People chased 'first contentful paint' and 'cumulative layout shift' timings because that's what Google told everyone they needed to optimize for. That meant reducing the amount of upfront work done in JS, pushing some barebones HTML and CSS to the client for those sweet, sweet metrics, and then running a massive bundle of deferred JS to make it do anything. Google is pulling that rug with Time to Interactive, First Input Delay and (coming soon) Interaction to Next Paint, so now devs are trying to write the same website but have the server strip out the code they wrote (eg Remix.run). Everyone wants a fast website. No one wants a heap of fragile complex build tooling. The answer to the first problem is to stop trying to solve the second problem with MORE TECH. Go back to fundamentals. Just make something that works with with HTML and CSS alone, and enhance it with JS. You don't need to be clever about it, especially if the level of interactivity on your website amounts to basically a form.

michaelchisari 4y ago
Simplicity is almost always best, but the hardest part is pushing back on management and product that often only care whether feature requests are possible and aren't as concerned with what goes on under the hood.
- jeffy90 4y ago
  Speed and uptime are also features. If customers like speed/uptime (they do) we need to make sure management prioritizes them and understands how certain features will work against speed/uptime.
  - jozzy-james 4y ago
    been a juggling act for me for some time, and always comes down to - they'd rather take a performance hit vs. harm the branding/interactivity. tho we're in a very niche market that doesn't seem to mind (i do my best to make it as efficient as can be)
    - epolanski 4y ago
      This. We have a very slow eshop, worst than any competitor, yet the priority is always new features that will make the life of users even worse.
- galaxyLogic 4y ago
  Cool-looking things appeal to customers, and also to developers. It's a bit like your car. It takes you from place to place and could drive much faster than speed-limits or traffic-jams allow. But getting from place to place is not all you want. You want to pay extra for the coolest looking fastest wheels you can afford. When you work with an app or app-development tool that looks cool your self-image improves. You are a cool dude because you work with a cool-looking application. Seriously, it does have an effect on me.
andrewmcwatters 4y ago
If you try and tell inexperienced employees this in an interview for a job when you have well over a decade or more of experience—you’re not getting the job. I agree with you, but there’s some sort of complexity agreement in corporate environments, because people aren’t willing to accept that you don’t need a large build process, or any at all these days, maybe outside of a build pass for JSX.
- azangru 4y ago
  > If you try and tell inexperienced employees this in an interview for a job when you have well over a decade or more of experience—you’re not getting the job. Good. An interview is as much you assessing your potential employer as your potential employer assessing you.
  - andrewmcwatters 4y ago
    True! Just a sort of unfortunate aspect of our field.
deleted 4y ago
[deleted]
pupppet 4y ago
I've had clients and self-professed SEO gurus carve out useful content in order to chase that 100 pagespeed score. I wish Google would just come out and state how content vs speed is weighted.
user3939382 4y ago
See also https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law
diceduckmonk 4y ago
> Time to Interactive, First Input Delay and (coming soon) Interaction to Next Paint Having worked on one of the most bloated SPAs at Google and doing an SRE rotation to optimize exactly these metrics, I couldn’t agree more on the hypothesis that this is where complexity, jank and fragility arises. This is why our startup set out to build the best-in-class frontend for cloud computing and making a bet on SSR. I’m from a JavaScript background and personally think hate for the language is undue. V8 is also a marvel of engineering. We elected Go for our application language. It’s faster for our purposes but with SSR the domain language isn’t as important. We could use Haskell if it was fit for the problem domain. We empathize with how ideas such as “user-perceived latency” came about but SSR is a much simpler model and our philosophy is that “simpler is faster is faster”.
- boredtofears 4y ago
  What is SSR exactly in the context that you're describing? I thought if you're using server side rendering you'd be serving HTML directly from your application.
  - diceduckmonk 4y ago
    The difference is more heuristical than technical. Render the entire page in one go, rather than have the server render small chunks at a time and have the client patch the DOM. I.e. not having to think about below the fold, adding event handlers to pre-empt and preload. In practice, you’ll need to sprinkle in JavaScript interactivity, but the point is keep this to a bare minimum. See Craigslist or HackerNews.
- strongpigeon 4y ago
  > Having worked on one of the most bloated SPAs at Google [...] Let me guess. Google Ads?
  - readams 4y ago
    I would say gmail is the most bloated SPA pretty much in existence much less at Google.
tsimionescu 4y ago
> Just make something that works with with HTML and CSS alone, and enhance it with JS. You don't need to be clever about it, especially if the level of interactivity on your website amounts to basically a form. A big problem with this is that html is extraordinarily limited as a widget framework. You only have a handful of widgets available, and many of them offer very little (if any) customizability from CSS. For example, say you wanted a checkbox, but you wanted to use a custom shape (Edit: shape - color is more easily controlled today) instead of the browser default. Well, tough luck. From HTML you'll have to put the checkbox inside a label, add an empty span next to it, and from CSS make the checkbox invisible and then get creative with drawing some boxes that look like a checkbox [0] (or, more realistically, load some custom graphics). So, if you're doing all of this effort anyway, why go through the effort of using the HTML input checkbox at all? I always find it fascinating just how barebones and bad HTML+CSS is as a GUI framework. I really don't understand why people insist it's in any way superior to using a JS toolkit for anything requiring more than the simplest interaction (say, more than a newspaper article). [0] https://www.w3schools.com/howto/howto_css_custom_checkbox.asp https://www.w3schools.com/howto/howto_css_custom_checkbox.as...
- Karellen 4y ago
  > For example, say you wanted a checkbox, but you wanted to use a custom color instead of the browser default. Well, tough luck. From HTML you'll have to put the checkbox inside a label, add an empty span next to it, and from CSS make the checkbox invisible and then get creative with drawing some boxes that look like a checkbox [0] (or, more realistically, load some custom graphics). So, if you're doing all of this effort anyway, why go through the effort of using the HTML input checkbox at all? What the fuck? Just use the actual goddamn checkbox. You can set colors with CSS, but also, it will work in exactly the same way as all the other checkboxes on the user's system. It will respond to keyboard and other input shortcuts the same way as all the other checkboxes they use. It will work with any accessibility devices the user has in the same way as all the other checkboxes they use. Don't reinvent standard controls just because they're not "customizable" enough. Function is more important than form, and the standard control has a lot more function than you're probably aware of. Also, the user already knows how the one on their system works, because they've already used one hundreds of times. And the same goes even more so for controls which are more complex than the checkbox. Which is, uh... checks notes... all of them. Just stop.
lhorie 4y ago
One story that comes to mind was when I was still relatively early in my career and the COO of the company came to me asking for some help getting some jquery ui tab widget thingie to work. And as if the words "COO" and "jquery ui" in the same sentence weren't enough to raise eyebrows, what came next was probably one of the most mind bending software engineering episodes I'd ever witness. It turned out he was trying to put together a web UI for displaying a number of reports from some computationally intensive data warehouse query crunching. We're talking visualization of tables and tables full of data. Conventional wisdom would dictate that implementing this the traditional way would involve query optimizations, various layers of caching, separation of concerns, a framework to manage all the complexity, etc, etc, etc. His approach? Just do the naive queries (slow as they were), print directly to HTML old school PHP style, then save the HTML file to disk. He was a bubbly happy type of guy and you could see the child-like joy on his face when he showed me how lightning fast the thing would load from navigating from one page to another because it was effectively looking at a static website once the pages had been generated once. I distinctly recall feeling a mix of confused feelings at seeing the guy break every rule in the "programming best practices" book and the undeniably good performance results from the sheer dumb simplicity of the solution.
- dntrkv 4y ago
  The purpose of the more complicated solutions is to build something that will be maintained for a long time where complexity will grow, and usually, require multiple contributors. I can bang out a basic landing page site in a few hours that will be extremely performant while pulling in zero libraries. But I would never want to maintain that over any extended period of time or added complexity.
  - anotheracctfo 4y ago
    The purpose of more complicated solutions is to prevent devs from becoming bored and leaving. In my experience, KISS results in the easiest solution to maintain. Then I get a litany of complaints from devs that "this isn't programming" or "this is a dead end to my career" and then they leave. Which paradoxically makes it more difficult to maintain, as I have no maintainers lol.
RickHull 4y ago
https://htmx.org/ https://htmx.org/
wruza 4y ago
Go back to fundamentals … if the level of interactivity on your website amounts to basically a form What if it doesn’t? I mean by requirements from various departments/analysts and user’s common sense.
- dmitriid 4y ago
  In 99% of cases your website will still be basically a form.
  - Existenceblinks 4y ago
    People forget that a form submit is a function call with parameters. The bone of programming; calling functions. Also something something state transfer.
paulirish 4y ago
Speaking as the TL of Lighthouse and PageSpeed, I can comfortably say that adding complexity is antithetical to our goal. Quality UX and a reliably performant web is what we want for all users. Ideally, folks would use a thinner stack with _less_ JS, as that's rewarded across all the metrics. But in recent years, many teams build a "site" by building a SPA. As they're entrenched in that dubious decision, the only path to making it performant is adding SSR complexity. ¯\_(ツ)_/¯ Perhaps its the apparent conflict between UX and DX that leads to tooling complexity? And to nitpick: Core Web Vitals debuted with 3 metrics, one of them being FID. The focus on runtime/JS performance has been there from the start. Regardless, I hard agree on your last paragraph.
- solardev 4y ago
  The whole idea of a "site" full of "pages" doesn't really suit a lot of modern use cases. What do you do when your "app" isn't really a "site" to begin with? Like most of the apps in Google Workspace, or Maps, Earth, etc. It's not their URL structure that gives them value, but the buttload of realtime clientside interactivity enabled by JS. How are you supposed to "less JS" your way out of that?
  - wpietri 4y ago
    If something isn't expressible as a site full of pages, why are you worrying about Google's metrics for sites and pages?
    - deleted 4y ago
      [deleted]
    - sroussey 4y ago
      Agreed. If you must login, for example, then that part of the site is not indexed, so googles metrics are not relevant. Indeed, I’ve seen higher NPS scores when it’s slower… the user feels like they are paying for more.
  - OJFord 4y ago
    The vast majority of SPAs are not 'Maps, Earth, etc.'. I thought the 'if the level of interactivity basically amounts to a form' of top-level comment sums it up nicely. Many are SPAs for the sake of it, similarly to packaging a website as an 'app' but not doing anything native, offline, or that really warrants it being its own app at all other than getting homescreen space on iOS. (Totally off-topic: I can't believe Apple still doesn't let you organise that however you want. It's sort of a small thing, but also so in your face, by far the most immediate turn-off to me of iOS.)
solardev 4y ago
And what do you do for more complex, stateful apps? I don't think it's fair to dismiss this problem as "just use HTML and CSS and a sprinkling of vanilla JS". What happens when you need to build anything more complex than a basic form? A dashboard, or web map, or Figma, or Slack, or Gmail, or Gsheets... everything from state to AJAX (and other async) to persistence to URL routing, etc. becomes insanely complex. I feel like "don't use tooling/frameworks" is the web dev version of "you don't need Java or .NET or WPF or WinForms, just use assembly and gfx drivers and draw pixels on the screen". HTML and ECMAscript evolve very slowly relative to the needs of software businesses, and it would take 30x (if not 300x) as long to write complex apps in those alone. Having a "build and bundle" step is just the webdev version of compiling developer-friendly code (React and frameworks) into the "lowest common denominator" code of browser-parseable HTML + JS. It's not about "cleverness", but being able to do your job in a reasonable amount of time and effort, vs going back to a 90s-style internet where every page is basically a dumb terminal and all the actual interactivity has to happen on the backend. I think is a better option is to know your target audience, their expected device and connection speed (metro desktop? rural mobile?) and not to worry about over-optimization. Nobody cares if your website loads in a second if it's so hard to use that it takes THEM more time to do what they need. Better to take 5 seconds to load, and then be actually usable as an app. FWIW I don't think web apps are getting slower because developers are getting worse, but because the newer frameworks are enabling new use cases that weren't before possible. Photo editing? You used to have to download and install Photoshop, which can take minutes or days depending on your network and connection. Now you can run Photopea in a browser window in a few seconds and do most of the same things. As for core web vitals? It's not a bad thing to use a performance arms race to get websites to be faster. It forces frameworks to evolve their delivery, caching, loading, hydration mechanisms. But that doesn't have to mean "give up on frameworks and complex apps". It can also just mean keep up with their latest performance improvements, and/or hope that ECMAscript evolves faster, that things like Web Components or PWAs etc. become more commonplace.
- fleddr 4y ago
  The examples you give are a 100% fit for the SPA model. Nobody would build Google Docs or a game from server-side HTML. That's not the discussion. The discussion is everything except that. The typical example being a CRUD app. A bunch of cards, filters on the left, search box on top, logged in user. It usually isn't much more than that. Which means its low state and lowly interactive.
ratorx 4y ago
Frontend frameworks often have better developer experience. I want to use one because it’s less annoying to do thing like template HTML with editor completions, than using HTML. Another theoretical advantage is that you can get better colocation of content, style and functionality. Basic JS is pretty annoying to write. It reminds me of using goto for control flow. It’s a lot cleaner to be able to put functionality alongside the document structure. Of course, you can use HTML + CSS + JS but you can also use Assembly for all code. But the end solution here is not Frontend frameworks. I think it’s time browsers give us a better abstraction to HTML + CSS + JS. Webassembly and friends are nice, but I think the 3 fundamentally need to be replaced together in a performant way such that the simple case of no client side code is well optimised. Frontend frameworks are just a symptom of the problem which is that Web devs have to use the only abstraction creation mechanism available to get nicer development properties.
- qudat 4y ago
  > Frontend frameworks often have better developer experience. I want to use one because it’s less annoying to do thing like template HTML with editor completions, than using HTML. Agreed. As I've been developing a service (https://prose.sh https://prose.sh) with no javascript and only go templates, the biggest downside is autocomplete.
bot41 4y ago
> Just make something that works with with HTML and CSS alone, and enhance it with JS If you do this and have a sufficiently complex application... you will end up where the modern frameworks are. They exist for a reason.
zemnmez 4y ago
> Make something that works with with HTML and CSS alone, and enhance it with JS. Hydration is... an automated system to do this? Am I missing something
deleted 4y ago
[deleted]
likortera 4y ago
Meanwhile I'm having a ton of fun (and better metrics) by just rendering html from the server and using Unpoly for interactivity and "old style ajax" dynamic updates. And still building the entire application in JavaScript, end to end.

michaelchisari 4y ago

Simplicity is almost always best, but the hardest part is pushing back on management and product that often only care whether feature requests are possible and aren't as concerned with what goes on under the hood.

jeffy90 4y ago
Speed and uptime are also features. If customers like speed/uptime (they do) we need to make sure management prioritizes them and understands how certain features will work against speed/uptime.
- jozzy-james 4y ago
  been a juggling act for me for some time, and always comes down to - they'd rather take a performance hit vs. harm the branding/interactivity. tho we're in a very niche market that doesn't seem to mind (i do my best to make it as efficient as can be)
  - epolanski 4y ago
    This. We have a very slow eshop, worst than any competitor, yet the priority is always new features that will make the life of users even worse.
galaxyLogic 4y ago
Cool-looking things appeal to customers, and also to developers. It's a bit like your car. It takes you from place to place and could drive much faster than speed-limits or traffic-jams allow. But getting from place to place is not all you want. You want to pay extra for the coolest looking fastest wheels you can afford. When you work with an app or app-development tool that looks cool your self-image improves. You are a cool dude because you work with a cool-looking application. Seriously, it does have an effect on me.

andrewmcwatters 4y ago

If you try and tell inexperienced employees this in an interview for a job when you have well over a decade or more of experience—you’re not getting the job. I agree with you, but there’s some sort of complexity agreement in corporate environments, because people aren’t willing to accept that you don’t need a large build process, or any at all these days, maybe outside of a build pass for JSX.

azangru 4y ago
> If you try and tell inexperienced employees this in an interview for a job when you have well over a decade or more of experience—you’re not getting the job. Good. An interview is as much you assessing your potential employer as your potential employer assessing you.
- andrewmcwatters 4y ago
  True! Just a sort of unfortunate aspect of our field.

deleted 4y ago

[deleted]

pupppet 4y ago

I've had clients and self-professed SEO gurus carve out useful content in order to chase that 100 pagespeed score. I wish Google would just come out and state how content vs speed is weighted.

user3939382 4y ago

See also https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law

diceduckmonk 4y ago

> Time to Interactive, First Input Delay and (coming soon) Interaction to Next Paint Having worked on one of the most bloated SPAs at Google and doing an SRE rotation to optimize exactly these metrics, I couldn’t agree more on the hypothesis that this is where complexity, jank and fragility arises. This is why our startup set out to build the best-in-class frontend for cloud computing and making a bet on SSR. I’m from a JavaScript background and personally think hate for the language is undue. V8 is also a marvel of engineering. We elected Go for our application language. It’s faster for our purposes but with SSR the domain language isn’t as important. We could use Haskell if it was fit for the problem domain. We empathize with how ideas such as “user-perceived latency” came about but SSR is a much simpler model and our philosophy is that “simpler is faster is faster”.

boredtofears 4y ago
What is SSR exactly in the context that you're describing? I thought if you're using server side rendering you'd be serving HTML directly from your application.
- diceduckmonk 4y ago
  The difference is more heuristical than technical. Render the entire page in one go, rather than have the server render small chunks at a time and have the client patch the DOM. I.e. not having to think about below the fold, adding event handlers to pre-empt and preload. In practice, you’ll need to sprinkle in JavaScript interactivity, but the point is keep this to a bare minimum. See Craigslist or HackerNews.
strongpigeon 4y ago
> Having worked on one of the most bloated SPAs at Google [...] Let me guess. Google Ads?
- readams 4y ago
  I would say gmail is the most bloated SPA pretty much in existence much less at Google.

tsimionescu 4y ago

> Just make something that works with with HTML and CSS alone, and enhance it with JS. You don't need to be clever about it, especially if the level of interactivity on your website amounts to basically a form. A big problem with this is that html is extraordinarily limited as a widget framework. You only have a handful of widgets available, and many of them offer very little (if any) customizability from CSS. For example, say you wanted a checkbox, but you wanted to use a custom shape (Edit: shape - color is more easily controlled today) instead of the browser default. Well, tough luck. From HTML you'll have to put the checkbox inside a label, add an empty span next to it, and from CSS make the checkbox invisible and then get creative with drawing some boxes that look like a checkbox [0] (or, more realistically, load some custom graphics). So, if you're doing all of this effort anyway, why go through the effort of using the HTML input checkbox at all? I always find it fascinating just how barebones and bad HTML+CSS is as a GUI framework. I really don't understand why people insist it's in any way superior to using a JS toolkit for anything requiring more than the simplest interaction (say, more than a newspaper article). [0] https://www.w3schools.com/howto/howto_css_custom_checkbox.asp https://www.w3schools.com/howto/howto_css_custom_checkbox.as...

Karellen 4y ago
> For example, say you wanted a checkbox, but you wanted to use a custom color instead of the browser default. Well, tough luck. From HTML you'll have to put the checkbox inside a label, add an empty span next to it, and from CSS make the checkbox invisible and then get creative with drawing some boxes that look like a checkbox [0] (or, more realistically, load some custom graphics). So, if you're doing all of this effort anyway, why go through the effort of using the HTML input checkbox at all? What the fuck? Just use the actual goddamn checkbox. You can set colors with CSS, but also, it will work in exactly the same way as all the other checkboxes on the user's system. It will respond to keyboard and other input shortcuts the same way as all the other checkboxes they use. It will work with any accessibility devices the user has in the same way as all the other checkboxes they use. Don't reinvent standard controls just because they're not "customizable" enough. Function is more important than form, and the standard control has a lot more function than you're probably aware of. Also, the user already knows how the one on their system works, because they've already used one hundreds of times. And the same goes even more so for controls which are more complex than the checkbox. Which is, uh... checks notes... all of them. Just stop.

lhorie 4y ago

One story that comes to mind was when I was still relatively early in my career and the COO of the company came to me asking for some help getting some jquery ui tab widget thingie to work. And as if the words "COO" and "jquery ui" in the same sentence weren't enough to raise eyebrows, what came next was probably one of the most mind bending software engineering episodes I'd ever witness. It turned out he was trying to put together a web UI for displaying a number of reports from some computationally intensive data warehouse query crunching. We're talking visualization of tables and tables full of data. Conventional wisdom would dictate that implementing this the traditional way would involve query optimizations, various layers of caching, separation of concerns, a framework to manage all the complexity, etc, etc, etc. His approach? Just do the naive queries (slow as they were), print directly to HTML old school PHP style, then save the HTML file to disk. He was a bubbly happy type of guy and you could see the child-like joy on his face when he showed me how lightning fast the thing would load from navigating from one page to another because it was effectively looking at a static website once the pages had been generated once. I distinctly recall feeling a mix of confused feelings at seeing the guy break every rule in the "programming best practices" book and the undeniably good performance results from the sheer dumb simplicity of the solution.

dntrkv 4y ago
The purpose of the more complicated solutions is to build something that will be maintained for a long time where complexity will grow, and usually, require multiple contributors. I can bang out a basic landing page site in a few hours that will be extremely performant while pulling in zero libraries. But I would never want to maintain that over any extended period of time or added complexity.
- anotheracctfo 4y ago
  The purpose of more complicated solutions is to prevent devs from becoming bored and leaving. In my experience, KISS results in the easiest solution to maintain. Then I get a litany of complaints from devs that "this isn't programming" or "this is a dead end to my career" and then they leave. Which paradoxically makes it more difficult to maintain, as I have no maintainers lol.

RickHull 4y ago

https://htmx.org/ https://htmx.org/

wruza 4y ago

Go back to fundamentals … if the level of interactivity on your website amounts to basically a form What if it doesn’t? I mean by requirements from various departments/analysts and user’s common sense.

dmitriid 4y ago
In 99% of cases your website will still be basically a form.
- Existenceblinks 4y ago
  People forget that a form submit is a function call with parameters. The bone of programming; calling functions. Also something something state transfer.

paulirish 4y ago

Speaking as the TL of Lighthouse and PageSpeed, I can comfortably say that adding complexity is antithetical to our goal. Quality UX and a reliably performant web is what we want for all users. Ideally, folks would use a thinner stack with _less_ JS, as that's rewarded across all the metrics. But in recent years, many teams build a "site" by building a SPA. As they're entrenched in that dubious decision, the only path to making it performant is adding SSR complexity. ¯\_(ツ)_/¯ Perhaps its the apparent conflict between UX and DX that leads to tooling complexity? And to nitpick: Core Web Vitals debuted with 3 metrics, one of them being FID. The focus on runtime/JS performance has been there from the start. Regardless, I hard agree on your last paragraph.

solardev 4y ago
The whole idea of a "site" full of "pages" doesn't really suit a lot of modern use cases. What do you do when your "app" isn't really a "site" to begin with? Like most of the apps in Google Workspace, or Maps, Earth, etc. It's not their URL structure that gives them value, but the buttload of realtime clientside interactivity enabled by JS. How are you supposed to "less JS" your way out of that?
- wpietri 4y ago
  If something isn't expressible as a site full of pages, why are you worrying about Google's metrics for sites and pages?
  - deleted 4y ago
    [deleted]
  - sroussey 4y ago
    Agreed. If you must login, for example, then that part of the site is not indexed, so googles metrics are not relevant. Indeed, I’ve seen higher NPS scores when it’s slower… the user feels like they are paying for more.
- OJFord 4y ago
  The vast majority of SPAs are not 'Maps, Earth, etc.'. I thought the 'if the level of interactivity basically amounts to a form' of top-level comment sums it up nicely. Many are SPAs for the sake of it, similarly to packaging a website as an 'app' but not doing anything native, offline, or that really warrants it being its own app at all other than getting homescreen space on iOS. (Totally off-topic: I can't believe Apple still doesn't let you organise that however you want. It's sort of a small thing, but also so in your face, by far the most immediate turn-off to me of iOS.)

solardev 4y ago

And what do you do for more complex, stateful apps? I don't think it's fair to dismiss this problem as "just use HTML and CSS and a sprinkling of vanilla JS". What happens when you need to build anything more complex than a basic form? A dashboard, or web map, or Figma, or Slack, or Gmail, or Gsheets... everything from state to AJAX (and other async) to persistence to URL routing, etc. becomes insanely complex. I feel like "don't use tooling/frameworks" is the web dev version of "you don't need Java or .NET or WPF or WinForms, just use assembly and gfx drivers and draw pixels on the screen". HTML and ECMAscript evolve very slowly relative to the needs of software businesses, and it would take 30x (if not 300x) as long to write complex apps in those alone. Having a "build and bundle" step is just the webdev version of compiling developer-friendly code (React and frameworks) into the "lowest common denominator" code of browser-parseable HTML + JS. It's not about "cleverness", but being able to do your job in a reasonable amount of time and effort, vs going back to a 90s-style internet where every page is basically a dumb terminal and all the actual interactivity has to happen on the backend. I think is a better option is to know your target audience, their expected device and connection speed (metro desktop? rural mobile?) and not to worry about over-optimization. Nobody cares if your website loads in a second if it's so hard to use that it takes THEM more time to do what they need. Better to take 5 seconds to load, and then be actually usable as an app. FWIW I don't think web apps are getting slower because developers are getting worse, but because the newer frameworks are enabling new use cases that weren't before possible. Photo editing? You used to have to download and install Photoshop, which can take minutes or days depending on your network and connection. Now you can run Photopea in a browser window in a few seconds and do most of the same things. As for core web vitals? It's not a bad thing to use a performance arms race to get websites to be faster. It forces frameworks to evolve their delivery, caching, loading, hydration mechanisms. But that doesn't have to mean "give up on frameworks and complex apps". It can also just mean keep up with their latest performance improvements, and/or hope that ECMAscript evolves faster, that things like Web Components or PWAs etc. become more commonplace.

fleddr 4y ago
The examples you give are a 100% fit for the SPA model. Nobody would build Google Docs or a game from server-side HTML. That's not the discussion. The discussion is everything except that. The typical example being a CRUD app. A bunch of cards, filters on the left, search box on top, logged in user. It usually isn't much more than that. Which means its low state and lowly interactive.

ratorx 4y ago

Frontend frameworks often have better developer experience. I want to use one because it’s less annoying to do thing like template HTML with editor completions, than using HTML. Another theoretical advantage is that you can get better colocation of content, style and functionality. Basic JS is pretty annoying to write. It reminds me of using goto for control flow. It’s a lot cleaner to be able to put functionality alongside the document structure. Of course, you can use HTML + CSS + JS but you can also use Assembly for all code. But the end solution here is not Frontend frameworks. I think it’s time browsers give us a better abstraction to HTML + CSS + JS. Webassembly and friends are nice, but I think the 3 fundamentally need to be replaced together in a performant way such that the simple case of no client side code is well optimised. Frontend frameworks are just a symptom of the problem which is that Web devs have to use the only abstraction creation mechanism available to get nicer development properties.

qudat 4y ago
> Frontend frameworks often have better developer experience. I want to use one because it’s less annoying to do thing like template HTML with editor completions, than using HTML. Agreed. As I've been developing a service (https://prose.sh https://prose.sh) with no javascript and only go templates, the biggest downside is autocomplete.

bot41 4y ago

> Just make something that works with with HTML and CSS alone, and enhance it with JS If you do this and have a sufficiently complex application... you will end up where the modern frameworks are. They exist for a reason.

zemnmez 4y ago

> Make something that works with with HTML and CSS alone, and enhance it with JS. Hydration is... an automated system to do this? Am I missing something

deleted 4y ago

[deleted]

likortera 4y ago

Meanwhile I'm having a ton of fun (and better metrics) by just rendering html from the server and using Unpoly for interactivity and "old style ajax" dynamic updates. And still building the entire application in JavaScript, end to end.