4 ms·

I dont get it. Yes it's a static site, but it's only text and you're sending 100kb+ of JS over the wire. Is there any reason why you need React?

igorbark 1y ago
you don't need to send 100kb+ of JS over the wire to build a static site in react: for example https://vike.dev https://vike.dev supports static HTML-only output for a site built with React. as for "why React", speaking just for myself it's really nice to just have one tool that can do everything (static HTML-only, static with JS, SPA, SSR) and not have to context switch or potentially even have to split my site into two projects just because I want to hop between one or the other approach. and React has the biggest mindshare and ecosystem.
- owebmaster 1y ago
  > you don't need to send 100kb+ of JS over the wire to build a static site in react It is telling that the blog of the fw creator ships 500kb of JS/CSS/HTML to display text on a screen. > it's really nice to just have one tool that can do everything (static HTML-only, static with JS, SPA, SSR) WebComponents (+lit-html)
  - perilunar 1y ago
    Yep. 411 KB of JS (126 KB minified). 525 KB of fonts! 40KB of HTML. 1.1MB (704 KB minified) total for approximately 4.3 KB of actual text. That's a crap:content ratio of 256:1
    - azemetre 1y ago
      Wow this is a great metric to use.
    - danabramov 1y ago
      Disable JS and see that my site loads just fine. Fonts are nice-to-have. Interactive examples (on other pages) are nice-to-have. None of this is render-blocking.
      - perilunar 1y ago
        It's still half a megabyte with JS turned off. For page of text. With no images.
  - danabramov 1y ago
    Pretty much none of that is blocking first paint. Disable JS and see that my site works just fine. I have interactive examples on some pages but all the extra stuff is just “nice-to-have”. Also I’m not a framework creator.
- turtlebits 1y ago
  I think you just proved the point by introducing yet another frontend framework to learn. And you absolutely don't want one tool to do everything. HTML/CSS is native and understanding it is a requirement for React. It also doesn't require Node and a build step.
  - nsonha 1y ago
    I think all software engineers in the world who know HTML/CSS (like who doesn't?) beg to differ Really funny how some devs think they know the secrets of engineering simplicity and everyone else is a fool for not knowing what they know (HTML/CSS).
    - owebmaster 1y ago
      Read this thread. There are some comments about using React components for everything and never touching HTML tags and CSS. And they probably call themselves senior frontend engineers.
      - nsonha 1y ago
        If not React it's just another abstraction (including whatever you come up with) that is arbitrary and shitty in a different way. Front-end/mobile is so boring and unimportant that it absolutely makes sense to just pick a thing and use it everywhere, and save your brain capacity for interesting problem solving. I say this as someone who's been doing front end for 10 years.
        owebmaster 1y ago
        If frontend is boring and unimportant, what is exciting and important? saving records in a database? UX is what makes money and it is done through frontend.
        nsonha 1y ago
        Client side is only interesting in complex generic reactive programming problems, state machines, domain modeling in the client, local first patterns. The part about browser or mobile platform intricacies is very lame.
exiguus 1y ago
Think a about the case, that you have a shop, and you need the stock to disable the add to cart button. You can do a API request for every page visit. Or, use something like ISR to revalidate stock on the server and rerender the page every 10min.
_benton 1y ago
Basically at any time they could turn it into an SPA, but tbf you don't need RSC for that.
crummy 1y ago
If you load external content on build (e.g. external blog pages, prices from an external store, etc), then you'll need some way to template that into your HTML. I'm not a huge React fan but I do like JSX compared to other templating languages.
- notpushkin 1y ago
  Then use JSX without React?
  - hombre_fatal 1y ago
    What do you mean? JSX compiles to jsx(“div”, props, children) function calls so you need a runtime (which can be small) to render that into strings. At which point, who cares if you’re using react to do it? It’s a good zero dep implementation of a jsx fn.
    - notpushkin 1y ago
      Yeah, but this function needn’t run in the browser. Just generate HTML with it and save into a file! (I don’t have a link to npm handy, but I’m sure there’s a library that can do that already.) Alternatively, you can use Astro with React components, which will render them using React-DOM, but save them as static HTML by default (you can still choose some components to be hydrated, though).
      - ne8il 1y ago
        The article in question is specifically about using Next.js to do what you are saying (generate static HTML files from a set of React components). He also mentions using Astro for it.
        notpushkin 1y ago
        Good point, though the article mostly discusses static site generation (no server-side JS) and I think we can take it a step further and have no runtime / client-side JS as well. Next.js does usually have the runtime part, but I imagine it’s not too hard to disable (or you can strip all JS from the output). Astro, like I mentioned, strips JS by default (from island components, not from .astro components, though you can usually use those without any client-side JS, too). It is kinda roundabout way of generating HTML from JSX though.
danabramov 1y ago
First of all, this is not an argument against the model. I could easily remove all JS and it would still work. I’m keeping it as a choice, not as a consequence of the model. I have interactive examples on some pages. I’m planning to have more of them and more complex ones. Very little of the infra for this is actually render-blocking — try disabling JS and see that my site loads just fine. All data and interactive stuff is loaded after the text and doesn’t block the first paint. If anything, running a webpage test shows that the CSS requests are blocking the first render a bit. Maybe I should inline them or something.

igorbark 1y ago

you don't need to send 100kb+ of JS over the wire to build a static site in react: for example https://vike.dev https://vike.dev supports static HTML-only output for a site built with React. as for "why React", speaking just for myself it's really nice to just have one tool that can do everything (static HTML-only, static with JS, SPA, SSR) and not have to context switch or potentially even have to split my site into two projects just because I want to hop between one or the other approach. and React has the biggest mindshare and ecosystem.

owebmaster 1y ago
> you don't need to send 100kb+ of JS over the wire to build a static site in react It is telling that the blog of the fw creator ships 500kb of JS/CSS/HTML to display text on a screen. > it's really nice to just have one tool that can do everything (static HTML-only, static with JS, SPA, SSR) WebComponents (+lit-html)
- perilunar 1y ago
  Yep. 411 KB of JS (126 KB minified). 525 KB of fonts! 40KB of HTML. 1.1MB (704 KB minified) total for approximately 4.3 KB of actual text. That's a crap:content ratio of 256:1
  - azemetre 1y ago
    Wow this is a great metric to use.
  - danabramov 1y ago
    Disable JS and see that my site loads just fine. Fonts are nice-to-have. Interactive examples (on other pages) are nice-to-have. None of this is render-blocking.
    - perilunar 1y ago
      It's still half a megabyte with JS turned off. For page of text. With no images.
- danabramov 1y ago
  Pretty much none of that is blocking first paint. Disable JS and see that my site works just fine. I have interactive examples on some pages but all the extra stuff is just “nice-to-have”. Also I’m not a framework creator.
turtlebits 1y ago
I think you just proved the point by introducing yet another frontend framework to learn. And you absolutely don't want one tool to do everything. HTML/CSS is native and understanding it is a requirement for React. It also doesn't require Node and a build step.
- nsonha 1y ago
  I think all software engineers in the world who know HTML/CSS (like who doesn't?) beg to differ Really funny how some devs think they know the secrets of engineering simplicity and everyone else is a fool for not knowing what they know (HTML/CSS).
  - owebmaster 1y ago
    Read this thread. There are some comments about using React components for everything and never touching HTML tags and CSS. And they probably call themselves senior frontend engineers.
    - nsonha 1y ago
      If not React it's just another abstraction (including whatever you come up with) that is arbitrary and shitty in a different way. Front-end/mobile is so boring and unimportant that it absolutely makes sense to just pick a thing and use it everywhere, and save your brain capacity for interesting problem solving. I say this as someone who's been doing front end for 10 years.
      - owebmaster 1y ago
        If frontend is boring and unimportant, what is exciting and important? saving records in a database? UX is what makes money and it is done through frontend.
        nsonha 1y ago
        Client side is only interesting in complex generic reactive programming problems, state machines, domain modeling in the client, local first patterns. The part about browser or mobile platform intricacies is very lame.

exiguus 1y ago

Think a about the case, that you have a shop, and you need the stock to disable the add to cart button. You can do a API request for every page visit. Or, use something like ISR to revalidate stock on the server and rerender the page every 10min.

_benton 1y ago

Basically at any time they could turn it into an SPA, but tbf you don't need RSC for that.

crummy 1y ago

If you load external content on build (e.g. external blog pages, prices from an external store, etc), then you'll need some way to template that into your HTML. I'm not a huge React fan but I do like JSX compared to other templating languages.

notpushkin 1y ago
Then use JSX without React?
- hombre_fatal 1y ago
  What do you mean? JSX compiles to jsx(“div”, props, children) function calls so you need a runtime (which can be small) to render that into strings. At which point, who cares if you’re using react to do it? It’s a good zero dep implementation of a jsx fn.
  - notpushkin 1y ago
    Yeah, but this function needn’t run in the browser. Just generate HTML with it and save into a file! (I don’t have a link to npm handy, but I’m sure there’s a library that can do that already.) Alternatively, you can use Astro with React components, which will render them using React-DOM, but save them as static HTML by default (you can still choose some components to be hydrated, though).
    - ne8il 1y ago
      The article in question is specifically about using Next.js to do what you are saying (generate static HTML files from a set of React components). He also mentions using Astro for it.
      - notpushkin 1y ago
        Good point, though the article mostly discusses static site generation (no server-side JS) and I think we can take it a step further and have no runtime / client-side JS as well. Next.js does usually have the runtime part, but I imagine it’s not too hard to disable (or you can strip all JS from the output). Astro, like I mentioned, strips JS by default (from island components, not from .astro components, though you can usually use those without any client-side JS, too). It is kinda roundabout way of generating HTML from JSX though.

danabramov 1y ago

First of all, this is not an argument against the model. I could easily remove all JS and it would still work. I’m keeping it as a choice, not as a consequence of the model. I have interactive examples on some pages. I’m planning to have more of them and more complex ones. Very little of the infra for this is actually render-blocking — try disabling JS and see that my site loads just fine. All data and interactive stuff is loaded after the text and doesn’t block the first paint. If anything, running a webpage test shows that the CSS requests are blocking the first render a bit. Maybe I should inline them or something.