I also have the same somewhat controversial opinion, the frontend community wasn't ready and (still isn't) to organise a functional codebase.

The second problem is that React has a "draw the rest of the owl" mindset. Sure you have nice frontend components but now what about caching? data transfers? static rendering? bundle size & spliting? routing?

▲

strogonoff 5 hours ago | parent | next [-]

The reason for React’s “draw the rest of the owl” (which is a great way to describe it) mindset is that it’s born not as a framework but as a library, and to this day self-identifies as such. It by design tells you nothing about and is agnostic with respect to how you organise your code, where to put tests, what bundler to use, etc.

IIRC React itself doesn’t even know anything about the Web or DOM, as that integration is supplied by the pluggable reconciler, which lives in a separate library (ReactDOM).

One could argue that with the amount of batteries included perhaps it ought to undergo a grand status change, but until then it’s hard to blame on the authors of a library that they are not delivering a framework.

▲

realusername 5 hours ago | parent [-]

Indeed but while being a library is okay for math tools or pdf generation, it evidently didn't work well for building UI components.

▲

strogonoff 4 hours ago | parent [-]

Did it not work? Many successful and complex sites and apps use React—whether directly or via a framework (Next, Astro, or something homegrown)—and indeed many frameworks are built on React.

> math tools or pdf generation

In this case the original scope of the library was “reactive rendering”, which sort of makes sense.

▲

realusername 4 hours ago | parent [-]

I've been there since the early days of React and I haven't seen a single React codebase which isn't a pile of duck-taped random packages, often leading to poor user performance.

Maybe it can be done, maybe not, but the average front-end dev doesn't have the insights to fill the gaps that React has left.

	▲	strogonoff 4 hours ago \| parent [-]
		Some codebases are better than others, more mature open-source projects tend to be more polished, closed enterprisey things can be nightmare fuel, but that’s all probably universal to a degree and not specific to whether you’re using React or not. (OK, dependency mess is at least somewhat specific to JS.) My real development experience started with Django—arguably one of the best-documented proper frameworks out there even before it reached 1.x—and let me tell you: the kind of garbage I have seen once I started doing it professionally still makes me shudder[0]. I agree with you in the sense that the choice to forgo a framework and use only a bunch of libraries directly should be very carefully considered. Frameworks exist for a reason. The decision should be made with the full understanding that one would implicitly undertake a task to create a framework (even if it is a narrowly specialised one just for that project). A lot of what you do if you go with raw React will not actually be front-end development: prepare to be vetting dependencies for (or implementing yourself) very basic functionality, fighting bundlers, trying to get TS to use correct global typings for the context, managing version hell to get all of the above to interoperate, etc. (By the way, any mistake you make will be on you. Picked a test runner that was discontinued? Some transitive dependency got hijacked? There is no one else to blame. There’s no BDFL and expert core dev team vetting things, knowing when and how to write from scratch if there’s no trustworthy third-party implementation, orchestrating working version combinations, or writing migration guides.) [0] Indeed it would be hubris to claim I myself have never ever architected something I would later call a monster held together with bits of duct tape.

▲

jcgl 5 hours ago | parent | prev [-]

Yeah, as a solo dev quite new to frontend, that made me nope out of React almost immediately. Having to choose a bunch of critically important third-party dependencies right out of the gate? With how much of a mess frontend deps seem to be in general? No thanks.

I settled on Svelte with SvelteKit. Other than stumbling block that was the Svelte 4 -> 5 transition, it's been smooth sailing. Like I said, I'm new here in the frontend world and don't have much to judge by. But it's been such a relief to have most things simply included out of the box.

▲

Tade0 5 hours ago | parent [-]

I've been doing frontend since 2012 and I still don't understand why React became so popular.

No two React projects are the same. Like, even the router has at least three different mainstream options to choose from. It's exhausting.

▲

jcgl 5 hours ago | parent | next [-]

That router thing seems crazy. I'm all for having options that are available. But not having, at the minimum, some blessed implementations for basic stuff like routers seems nuts. There is so much ecosystem power in having high-quality, blessed implementations of things. I'm coming from working primarily in Go, where you can use the stdlib for >80% of everything you do (ymmv), so I feel this difference very keenly.

▲

Tade0 2 hours ago | parent [-]

> There is so much ecosystem power in having high-quality, blessed implementations of things.

Indeed. I work mainly in Angular because while it's widely regarded as terrible and slow to adapt, it's predictable in this regard.

Also now with typed forms, signals and standalone components it's not half bad. I prefer Svelte, but when I need Boring Technology™, I have Angular.

90%+ of all web apps are just lists of stuff with some search/filtering anyway, where you can look up the details of a list entry and of course CRUD it via a form. No reason to overthink it.

	▲	LocalPCGuy an hour ago \| parent [-]
		> widely regarded as terrible and slow to adapt I know you are saying you do work mainly in Angular, but for others reading this, I don't think this is giving modern Angular the credit it deserves. Maybe that was the case in the late 20-teens, but the Angular team has been killing it lately, IMO. There is a negative perception due to the echo chamber that is social media but meanwhile, Angular "just works" for enterprise and startups who want to scale alike. I think people who are burned on on decision fatigue with things like React should give Angular another try, might be pleasantly surprised how capable it is out of the box, and no longer as painful to press against the edges.

▲

realusername 5 hours ago | parent | prev [-]

Even when it's the same router package, these things break backward compatibility so often that different versions of the same package will behave differently