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.
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)
That's a crap:content ratio of 256:1
Also I’m not a framework creator.
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.
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).
And I'm sure you do it as well as other delusional backend-only coders
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.
...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."
UIs made of React components. I try to avoid having to know or care about the underlying implementation details.
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)
And AI really can do a lot of work nowadays. I met a founder who built their entire mvp with v0.dev. 5 pages, multiple flows, modals with photo taking/uploading and working color picker. They only needed to add the api-calling logic.
Must be a case of the midwit meme, or https://cspages.ucalgary.ca/~robin/class/449/Evolution.htm . Intermediate programmers satisfy their ego by writing everything themselves; a real experienced professional knows that custom code or a complex technology stack is a liability, and delivers the functionality the business needs in the way that will impose the smallest maintenance burden.
> it's not accurate to say that HTML and CSS are not "necessary" unless you're doing what seems to be very basic work.
Disagree. You need to be able to lay things out, compose components, and hook up behaviour. But you don't need to use the lowest level languages to do that, any more than you need to write all your programs in machine code. You need to understand the DOM, but that doesn't mean you need to express it in HTML, and similarly for layout.
> Tailwind is still CSS, again, so without knowing what things like flex actually do, you can't use Tailwind either.
You need to understand layout and styling properties, sure. But you can skip the things that make CSS CSS - selectors, cascading, and the like - which the industry is ever so gradually starting to recognise for the failures they are.
> I'm beginning to suspect you may just use AI to build much of your code for you.
LOL. Is this projection, or just reaching for any possible way to smear me? The AI fanboys are happy to mix a dozen technologies in their project because the AI "understands" all of them equally well - mix React and CSS and HTMX and what have you, why not? I'm actually genuinely curious about your thought process here (if you had one), can you talk through what lead you to this bizarre idea?
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!
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.
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.
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).
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.