4 ms·

99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps.

by pjmlp 1mo ago

thataccount 1mo ago
>99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps. That is because the latest framework always fixes everything that wasn't broken before.
- w29UiIm2Xz 1mo ago
  There is no good technical solution for rendering on the server and upgrading to an interactive experience on the client.
  - pjmlp 1mo ago
    Most websites don't need an interactive experience on the client, for what is static content.
  - sgift 1mo ago
    Ignoring for a moment that most websites don't need any interactivity: Even for those that need it, for almost any of them something JQuery-like is more than enough. You really, really, really don't need the latest super big framework.
    - w29UiIm2Xz 1mo ago
      The jQuery spaghetti of the past seems worse than the React spaghetti of today. Too many unpredictable side effects. Changing one thing breaks something else. On business-scale timeframes, you can't clean it up. React enjoyed its spot in the limelight. Then, unskilled people wrote bad React and the framework, not rank-and-file developers, took the credibility hit. It is more difficult, I suppose, to make a user-perceived slow webpage in jQuery.
    - stickfigure 1mo ago
      > most websites don't need any interactivity I dispute this. I don't have any statistics either, but my subjective experience is that most websites are not like newspapers or blogs. Even shopping websites have pretty heavy interactivity these days. Also, most boring pure-information-presentation problems are mostly solved by ancient technologies like wordpress. If you're working in web development in 2026, you probably aren't making static websites or blogs. You're doing something novel that probably has much higher interactivity demands.
      - pjmlp 1mo ago
        There is hardly anything novel in Web other than catching up to Flash or native apps.
  - john01dav 1mo ago
    If you can tolerate the (fairly minor) SEO consequences, just render on the client exclusively and fetch data via http calls. I've made small but quite interactive websites with entirely static Svelte + some router (routify/sveltekit/etc.) SPA that just uses http calls for whatever the server needs to be involved in. It's not the right choice for everything, but for some things it works excellently. With a relatively lightweight frontend like Svelte, as well as splitting the SPA into multiple bundles (so it's in some ways not an SPA anymore) makes it perfectly usably snappy even over 200+ms latency, and very fast over a normal connection.
paulddraper 1mo ago
Bad take. HTML is abysmally lacking for any interactive (which is what this article is about). Decades later, even something as common as a combobox is unsupported. EDIT: Downvotes but no argument.
- Spivak 1mo ago
  It comes down the web browser being used for two different use cases and two camps arguing past one another. Documents vs Programs The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. You are rightfully pointing out that VanillaJS is insufficient to build software in the browser. Where I imagine you lose some people is that comboboxes can be done natively with the datalist attribute.
  - locknitpicker 1mo ago
    > The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. Where does that html come from, then? Do you honestly believe all pages could be static html+css served from some bucket? Or do they need to be rendered by a programm running on a server? Because once you start talking about servers generating pages then all this talk about JavaScript frameworks boils down to arguing where the complexity should be in place A or B.
    - pjmlp 1mo ago
      It comes from a server designed at CERN.
    - Spivak 1mo ago
      Yes? Users often prefer a nice GUI but CMSs are effectively what you describe and run the majority of content oriented sites. Static site generators are just the dev-centric version of that. The more common situation is that you're generating pages on the server and shipping a massive JS bundle just to display what could have been rendered once. But even given your position you see no difference between shipping the user a binary and shipping source code plus a compiler in terms of the user's experience? Surely the existence of server side react points to the server doing the initial lift being an improvement.
locknitpicker 1mo ago
> 99% of the time those sites could be plain HTML and CSS Some of that css and html doesn't run reliably and consistently on all browsers. A visit to sites such as canIuse helps build up an idea of the extent of the problem. Also, you seem to ignore the fact that JavaScript frameworks use said html and CSS extensively, and provide the necessary abstractions to bridge the unreliability gap in addition to introducing features that html and css do not support. What I really find funny about this issue is the fact that this type of claim implies that virtually all software engineers who for some reason aren't html+css purists are utterly incompetent and completely unable to assess any technical tradeoffs. Imagine yourself walking around with the belief that an entire field is manned by people who don't have a clue about what they are doing.
BobbyTables2 1mo ago
I expect soon each website will have its own browser, compiled as WASM which will be launched in order to render the JavaScript and HTML on the website.
- gavinsyancey 1mo ago
  This is actually plausible as a way to prevent adblock.
- pjmlp 1mo ago
  Basically Flash 2.0.

99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps.

by pjmlp 1mo ago

99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps.

thataccount 1mo ago

>99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps. That is because the latest framework always fixes everything that wasn't broken before.

w29UiIm2Xz 1mo ago
There is no good technical solution for rendering on the server and upgrading to an interactive experience on the client.
- pjmlp 1mo ago
  Most websites don't need an interactive experience on the client, for what is static content.
- sgift 1mo ago
  Ignoring for a moment that most websites don't need any interactivity: Even for those that need it, for almost any of them something JQuery-like is more than enough. You really, really, really don't need the latest super big framework.
  - w29UiIm2Xz 1mo ago
    The jQuery spaghetti of the past seems worse than the React spaghetti of today. Too many unpredictable side effects. Changing one thing breaks something else. On business-scale timeframes, you can't clean it up. React enjoyed its spot in the limelight. Then, unskilled people wrote bad React and the framework, not rank-and-file developers, took the credibility hit. It is more difficult, I suppose, to make a user-perceived slow webpage in jQuery.
  - stickfigure 1mo ago
    > most websites don't need any interactivity I dispute this. I don't have any statistics either, but my subjective experience is that most websites are not like newspapers or blogs. Even shopping websites have pretty heavy interactivity these days. Also, most boring pure-information-presentation problems are mostly solved by ancient technologies like wordpress. If you're working in web development in 2026, you probably aren't making static websites or blogs. You're doing something novel that probably has much higher interactivity demands.
    - pjmlp 1mo ago
      There is hardly anything novel in Web other than catching up to Flash or native apps.
- john01dav 1mo ago
  If you can tolerate the (fairly minor) SEO consequences, just render on the client exclusively and fetch data via http calls. I've made small but quite interactive websites with entirely static Svelte + some router (routify/sveltekit/etc.) SPA that just uses http calls for whatever the server needs to be involved in. It's not the right choice for everything, but for some things it works excellently. With a relatively lightweight frontend like Svelte, as well as splitting the SPA into multiple bundles (so it's in some ways not an SPA anymore) makes it perfectly usably snappy even over 200+ms latency, and very fast over a normal connection.

paulddraper 1mo ago

Bad take. HTML is abysmally lacking for any interactive (which is what this article is about). Decades later, even something as common as a combobox is unsupported. EDIT: Downvotes but no argument.

Spivak 1mo ago
It comes down the web browser being used for two different use cases and two camps arguing past one another. Documents vs Programs The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. You are rightfully pointing out that VanillaJS is insufficient to build software in the browser. Where I imagine you lose some people is that comboboxes can be done natively with the datalist attribute.
- locknitpicker 1mo ago
  > The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. Where does that html come from, then? Do you honestly believe all pages could be static html+css served from some bucket? Or do they need to be rendered by a programm running on a server? Because once you start talking about servers generating pages then all this talk about JavaScript frameworks boils down to arguing where the complexity should be in place A or B.
  - pjmlp 1mo ago
    It comes from a server designed at CERN.
  - Spivak 1mo ago
    Yes? Users often prefer a nice GUI but CMSs are effectively what you describe and run the majority of content oriented sites. Static site generators are just the dev-centric version of that. The more common situation is that you're generating pages on the server and shipping a massive JS bundle just to display what could have been rendered once. But even given your position you see no difference between shipping the user a binary and shipping source code plus a compiler in terms of the user's experience? Surely the existence of server side react points to the server doing the initial lift being an improvement.

locknitpicker 1mo ago

> 99% of the time those sites could be plain HTML and CSS Some of that css and html doesn't run reliably and consistently on all browsers. A visit to sites such as canIuse helps build up an idea of the extent of the problem. Also, you seem to ignore the fact that JavaScript frameworks use said html and CSS extensively, and provide the necessary abstractions to bridge the unreliability gap in addition to introducing features that html and css do not support. What I really find funny about this issue is the fact that this type of claim implies that virtually all software engineers who for some reason aren't html+css purists are utterly incompetent and completely unable to assess any technical tradeoffs. Imagine yourself walking around with the belief that an entire field is manned by people who don't have a clue about what they are doing.

BobbyTables2 1mo ago

I expect soon each website will have its own browser, compiled as WASM which will be launched in order to render the JavaScript and HTML on the website.

gavinsyancey 1mo ago
This is actually plausible as a way to prevent adblock.
pjmlp 1mo ago
Basically Flash 2.0.