4 ms·

I think the author understands that just fine (I follow him on Mastodon and this is something he is very passionate about). To me his argument is that this shou

I think the author understands that just fine (I follow him on Mastodon and this is something he is very passionate about). To me his argument is that this shouldn't—and doesn't need to—be the case. The vast majority of sites out there would be just fine, and in many cases much better, as traditional server-rendered pages with a thin layer of JS on top for enhancements and for islands of interactivity. That massively reduces the complexity and cost of creating and maintaining a build. Most of us aren't working on anything that requires the entirety of every page and the entire navigation model to be implemented on the client.

lucsky 2y ago
So he's basically publishing a 20 pages philosophical logorrhea to make the simple point that developers should pay more attention to the difference between a web SITE and a web APP and choose their stack accordingly, which is a totally fair point to which I 100% agree with. What I fail to see is how React is responsible for any of this because this sort of reads like his wife left him for one of the React engineer or some shit.
- ht85 2y ago
  Another thing is that almost every complaint I see about React (except bundle size maybe, but who cares?) exists in the APP context. If your use case is a simple website, React is just a nice templating lib and you won't need to use any of the things people generally dislike about it. That AND your experience when you inevitably have to add some interactivity is going to be 100x better than vanilla JS. As for the build step, there are many turn key solutions nowadays that "just work". And isn't a small build step a plus, compared to being at the mercy of a typo breaking everything? To me that piece of mind if worth a lot, compared to whatever manual testing you'd have to do if you work with "text" files.
  - hasanhaja 2y ago
    > is just a nice templating lib Are these templates only used on the server-side to generate the HTML upfront? Or is it being generated on the client? > experience when you inevitably have to add some interactivity is going to be 100x better than vanilla JS I don't believe this can quantified. How are you measuring DX improvements? Are you also able to continue to measure these improvements as your application/codebase scales?
    - andrewaylett 2y ago
      It's certainly possible to generate the HTML up-front. Tooling like Next.js even sets things up so it's easier to render the HTML for the first page load on the server than to push it to the client. I have a website. It's not great, it doesn't get much traffic, but it's mine :). If you disable JS, it works: links are links, HTML is loaded for each page view. If you enable JS, it still works: links will trigger a re-render, the address bar updates, all the nice "website" stuff. If I write enough (and people read enough) then enabling JS also brings performance benefits: yes, you have to load ~100kB of JS. But each page load is 4kB smaller because it doesn't contain any boilerplate. Obviously I could generate the HTML any way I choose, but doing it in React is nice and composable.
    - flimsypremise 2y ago
      If you really want to, you can have a react app that is just static templates with no interactivity with a simple Node server that just called renderToString and all of a sudden react is just a backend templating framework. If you want to get really fancy you can then re-render specific components on the client side without re-rendering the entire page. You don't need NextJS to do this either, its very simple and straightforward and lets you use an entirely frontend toolchain to do everything.
flimsypremise 2y ago
Building a web application with a UI in a professional context without a frontend build is borderline malpractice. Even a "thin" layer of JS on top requires some degree of dependency management, and I personally have no desire to go back to the days of vanilla CSS, so you need a SASS/SCSS transpiler. Then there's a lot of handy things that frontend builds do, like normalizing SVG icon formats, automatic organization of static assets etc. The fact is the "islands of interactivity" model still requires two builds.
- hasanhaja 2y ago
  > Building a web application with a UI in a professional context without a frontend build is borderline malpractice. Why do you think that? What problem is a build tool solving for you that without it you think you're being irresponsible for not doing it by hand?
- deergomoo 2y ago
  Nowhere in my comment did I say abandon a build step? I’m saying—if you do not have high interactivity requirements, which I would claim is most things on the web—you will encounter a lot less overall complexity shipping mostly server-rendered pages with isolated, self contained JS bundles where you need them. I was using multi-entrypoint build steps outputting separate per-page or per-feature CSS and JS bundles long before I ever worked on an SPA, it’s hardly a good reason to move your entire UI and routing to the client-side.
  - flimsypremise 2y ago
    What's rendering the pages on the server? Because if its not javascript, and you still have a frontend build, you have a repository with two separate builds, and builds are expensive to maintain. If your containerizing, you need two different containers, each with a dependency management system, a runtime, probably a separate workflow for development and production. There are many ways to render pages on the server using a single JS builds, most template rendering engines have a node implementation, and most javascript frontend frameworks have a mechanism to render components statically to a string. If we're talking about a simple, mostly-static website, the content is going to be cached so the performance of the backend isn't a huge factor. So just use JS for the whole thing, and save yourself a build.

lucsky 2y ago

So he's basically publishing a 20 pages philosophical logorrhea to make the simple point that developers should pay more attention to the difference between a web SITE and a web APP and choose their stack accordingly, which is a totally fair point to which I 100% agree with. What I fail to see is how React is responsible for any of this because this sort of reads like his wife left him for one of the React engineer or some shit.

ht85 2y ago
Another thing is that almost every complaint I see about React (except bundle size maybe, but who cares?) exists in the APP context. If your use case is a simple website, React is just a nice templating lib and you won't need to use any of the things people generally dislike about it. That AND your experience when you inevitably have to add some interactivity is going to be 100x better than vanilla JS. As for the build step, there are many turn key solutions nowadays that "just work". And isn't a small build step a plus, compared to being at the mercy of a typo breaking everything? To me that piece of mind if worth a lot, compared to whatever manual testing you'd have to do if you work with "text" files.
- hasanhaja 2y ago
  > is just a nice templating lib Are these templates only used on the server-side to generate the HTML upfront? Or is it being generated on the client? > experience when you inevitably have to add some interactivity is going to be 100x better than vanilla JS I don't believe this can quantified. How are you measuring DX improvements? Are you also able to continue to measure these improvements as your application/codebase scales?
  - andrewaylett 2y ago
    It's certainly possible to generate the HTML up-front. Tooling like Next.js even sets things up so it's easier to render the HTML for the first page load on the server than to push it to the client. I have a website. It's not great, it doesn't get much traffic, but it's mine :). If you disable JS, it works: links are links, HTML is loaded for each page view. If you enable JS, it still works: links will trigger a re-render, the address bar updates, all the nice "website" stuff. If I write enough (and people read enough) then enabling JS also brings performance benefits: yes, you have to load ~100kB of JS. But each page load is 4kB smaller because it doesn't contain any boilerplate. Obviously I could generate the HTML any way I choose, but doing it in React is nice and composable.
  - flimsypremise 2y ago
    If you really want to, you can have a react app that is just static templates with no interactivity with a simple Node server that just called renderToString and all of a sudden react is just a backend templating framework. If you want to get really fancy you can then re-render specific components on the client side without re-rendering the entire page. You don't need NextJS to do this either, its very simple and straightforward and lets you use an entirely frontend toolchain to do everything.

flimsypremise 2y ago

Building a web application with a UI in a professional context without a frontend build is borderline malpractice. Even a "thin" layer of JS on top requires some degree of dependency management, and I personally have no desire to go back to the days of vanilla CSS, so you need a SASS/SCSS transpiler. Then there's a lot of handy things that frontend builds do, like normalizing SVG icon formats, automatic organization of static assets etc. The fact is the "islands of interactivity" model still requires two builds.

hasanhaja 2y ago
> Building a web application with a UI in a professional context without a frontend build is borderline malpractice. Why do you think that? What problem is a build tool solving for you that without it you think you're being irresponsible for not doing it by hand?
deergomoo 2y ago
Nowhere in my comment did I say abandon a build step? I’m saying—if you do not have high interactivity requirements, which I would claim is most things on the web—you will encounter a lot less overall complexity shipping mostly server-rendered pages with isolated, self contained JS bundles where you need them. I was using multi-entrypoint build steps outputting separate per-page or per-feature CSS and JS bundles long before I ever worked on an SPA, it’s hardly a good reason to move your entire UI and routing to the client-side.
- flimsypremise 2y ago
  What's rendering the pages on the server? Because if its not javascript, and you still have a frontend build, you have a repository with two separate builds, and builds are expensive to maintain. If your containerizing, you need two different containers, each with a dependency management system, a runtime, probably a separate workflow for development and production. There are many ways to render pages on the server using a single JS builds, most template rendering engines have a node implementation, and most javascript frontend frameworks have a mechanism to render components statically to a string. If we're talking about a simple, mostly-static website, the content is going to be cached so the performance of the backend isn't a huge factor. So just use JS for the whole thing, and save yourself a build.