Ah yeah, React doesn't make this any easier. You'll probably end up with a useState combined with className={clsx(selected[idx] && "selected")} or something. I don't think that's more complicated or even more LoC but it's definitely doing more work than vanilla so the performance difference is inarguable. You'd have to box off the state to its own component to avoid re-rendering the entire list.
> I don't think that's more complicated or even more LoC but it's definitely doing more work than vanilla so the performance difference is inarguable
It's not just the LoC,
- I don't need a build chain for this; there's no transpilation.
- I don't need an external library to download to the client to do this.
- I can get the HTML from anywhere. Rails, PHP, Node.js, ASP.NET, static bucket in S3. Anywhere; I have more flexibility on my backend to pick something that's fast.
- It's incredibly fast in the browser and SEO friendly *without any extra work* because all of the HTML is already sitting there.
- I didn't need any rehydration or complex data flow/data passing logic from server to client.
- It's easily debuggable even in production
You might be moving the goalposts slightly. The original comment said there were things you can do in a handful of lines in vanilla that it takes dozens of lines of React because you were concerned about complexity. Setting up the project should not be part of that complaint [if you guys have to set up the project every time you try to add a class to a selected item, I can understand why that would be cumbersome ;) ]. Vanilla JS tool chains being comparitively less complex and emitting smaller builds is not the line of discussion I thought I was engaging.
You don't have to set it up every time, but many features require that you tweak the setup and/or migrate your setup/configuration. I can't imagine having to tweak <script src="..." />
Rather than moving the goal posts, I'd proffer that you are missing the forest for the trees.
Case in point: Next 12 to Next 13. The architecture of layout pages, client vs server only components, new build chain (surely will have its own kinks and bugs to iron out). Then there will be a Next 14, TurboPack 2, React 19, etc. Migrating some remaining systems from Node 12/14 to Node 16/18 and updating our CI configurations, local dev environments, and praying that all the packages update without issue. Breaking changes in upstream NPM packages. React's shift from class components to functional components and hooks. Working on integrating InstantSearch into a Next.js app this week and the `useClearRefinements` hook can't be included on the server side (despite the fact that our SSR is broken right now). So I needed to use `next/dynamic` and exclude it from SSR to get it to build which seemed extra ridiculous because...
As I mentioned, this week, I noticed that our SSR pages were suddenly no longer generating any HTML on the server essentially turning our Next app into a full CSR app with server side API calls. I checked in with CTO and FE dev to see if this is intentional or accidental. Something errant with the toolchain, configuration, or change in how we are loading assets is now causing Next to misbehave (haven't figured this one out yet).
I will never, ever have to deal with this with those 15 lines of JS. Those 15 lines of JS will never need to be migrated into a different runtime, build process, tool chain, or stack. 10 years later, those 15 lines of JS are still going to work. Whatever migrations you need to do to modernize your toolchain and stack over the next two years is work and effort that you're not spending on creating value.
So the tool chain creates its own complexity that is secondary to the core development complexity. That's Alex Russell's point in the article: the complexity merchants have created an environment where there's so much unnecessary complexity and -- wouldn't you guess it? -- they have just the thing you need to solve it! They have you on a treadmill while they're feeding you doughnuts and chocolate.
Okay, I'm just saying this isn't the conversation I signed up for. I've heard people scream about react and tool chains and how much they hate js pretty much nonstop since I've been a user of this site. I am not interested. If I thought it would go this way, I wouldn't have engaged you.
Haha, I hope you don't feel attacked; apologies if it comes across that way. I am right with you on that treadmill and really appreciate the discussion and counter-perspective to help me think through my own. If anything, this interaction has helped me clear some fog around our stack so I appreciate that you were willing to engage in a discussion.
