[igorbark]

you don't need to send 100kb+ of JS over the wire to build a static site in react: for example 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.

[turtlebits]

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]

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]

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]

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]

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]

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.

[lmm]

> HTML/CSS is native and understanding it is a requirement for React.

It's not necessary and the ROI is poor IMO, especially for CSS. Better to just use React for everything and not worry about the implementation details; yes those details will sometimes help you debug, just like knowing machine code will occasionally help you debug your compiled code, but it's not something to put a lot of your learning budget into.

> It also doesn't require Node and a build step.

The point is assuming you already have node and a build step. You already know React. So just use it for everything. Everyone who thinks they can "just write HTML/CSS" ends up introducing Hugo or Gatsby or whatnot (or, worse, writing their own "simple" Makefiles and shell scripts) and gradually adding more and more features until it's just as complex as React. Just use React.

[satvikpendem]

> It's not necessary and the ROI is poor IMO, especially for CSS. Better to just use React for everything and not worry about the implementation details; yes those details will sometimes help you debug, just like knowing machine code will occasionally help you debug your compiled code, but it's not something to put a lot of your learning budget into.

...what? What are you writing in React if not HTML tags and CSS classes? How can you even write anything in React without that? React doesn't do anything CSS specific either, so I don't understand how you'd even style anything if HTML and CSS were not a "necessity."

[lmm]

> What are you writing in React if not HTML tags and CSS classes?

UIs made of React components. I try to avoid having to know or care about the underlying implementation details.

[KronisLV]

> I try to avoid having to know or care about the underlying implementation details.

This feels quite ignorant. I'm not sure, in some ways I understand it, for example, when running software on the JVM, I typically don't think about how it's implemented, so I share some of that ignorance.

At the same time, specializing to just knowing one technology (e.g. React) and not caring about up or down the stack can also be limiting - both for any career moves (Vue? Angular? working with how the resources are packaged and deployed?) as well as just debugging things in more detail (since one can feasibly imagine cases where you need to look at both the output HTML/CSS/JS to understand why certain things are happening, not just a React plugin in DevTools).

You don't have to learn things that are of no value right now, but you probably shouldn't go out of your way to not learn things. Staying curious is generally pretty nice!

[lmm]

I mean, sure, I do actually know a bunch of the details and it's occasionally useful for debugging. But I look for ways to work at the React level if possible (e.g. using the React dev tools to debug the component hierarchy rather than using the raw browser dev tools where possible). IME it's better to fully specialise in a small set of technologies than to dabble across a wider range.

[satvikpendem]

And what are in those components? Divs with a className property I assume? Or are you literally only using components other people have made in UI libraries with no changes of your own?

[lmm]

I generally use preexisting components, there's not a lot of value add in creating my own date picker or dropdown box or whatever. Obviously I put my own content in, and compose together existing components to make bigger new components if the component I want doesn't exist (e.g. if I couldn't find an address entry component I might make one out of individual text entry components). I think some of the components I use might actually be or correspond to "basic" HTML tags, but that doesn't make any difference at the point of use.

If a component doesn't have built-in styling support (i.e. configurable via React properties) then I'll use Tailwind so I can at least ignore all the selectors and cascading nonsense of CSS. (I remain hopeful that the world will eventually see that inline styling is the way to go; with Tailwind I meet them halfway)

[owebmaster]

> 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)

[danabramov]

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.

[perilunar]

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

[danabramov]

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]

It's still half a megabyte with JS turned off. For page of text. With no images.

[azemetre]

Wow this is a great metric to use.