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?
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.
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.
It worked as in react is the de facto frontend choice.
It didn't work as in if I were to ask for the router, state management, etc library, there would be a combinatorial explosion of react "frameworks", all sucking in different ways.
I am (and supposedly grandparent also) on the option that react leaves out way too much that would still be well in the scope of a 'UI framework', and while modularity can be a good thing in certain things, more modular, more moving parts does increase complexity.
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.
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.
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.
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.
> 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.
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.
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
It's been like this for a while, the top results for a lot of known apps are scam impersonators.
So much for the so called "safety" of the appstore.
In fact, they had so many ChatGPT fake apps showing as top results that they had to do something as users couldn't find the real one and it reached the news.
> In fact, they had so many ChatGPT fake apps showing as top results that they had to do something as users couldn't find the real one and it reached the news.
This is after claiming for many years that the walled garden is a necessity to protect users, and their app store is a safely curated utopia which justifies the 30% fee cut.
I love your optimism. What you'll see is return to 2000s where you may have had "Symbian" as the operating system, but the phones weren't compatible between themselves and apps broke and didn't work across manufacturers (or even product lines) because there was noone enforcing compatibility.
I wonder if you forgot that or you're too young to remember what kind of bizarre hell mobile development was at that time.
Heck, even early Android was really hard to develop for because CTS suite didn't cover enough and all of us spent hours upon hours (and many dollars) trying to reproduce and fix Samsung, Huawei, HTC and other bugs.
I never said it's going to be smoother than it is right now, just that Google will lose control.
8 of the top 10 manufacturers are Chinese, the last two are Samsung (which definitely isn't going to side with Google) ... and Google themselves.
If Google doesn't publish AOSP anymore, Pixels will be the only phone with their software on it, Samsung might attempt something alone and the rest will pick up the development from a Chinese government consortium which will be the de-facto default mobile platform instead of the Google one.
Personally I get a +5% productivity in a good day with AI.
I do double my productivity on personal projects but they aren't entreprise style jobs.
I really hope for those AI companies that my situation isn't too common because burning billions to make dev hobbies more productive doesn't sound too good of a business plan.
But there is a cap: you can only bring down trade with a country to zero. This might inflict some pain in the immediate, but eventually trade is simply directed elsewhere - and you lose any leverage you have.
...which is why when comparing countries per capita emissions is the correct measure for deciding which countries are doing a better or worse job of addressing the problem.
I think the trouble with arguments about AGI is that they presume we all have similar views and respect for thought and human intelligence, while the scale is maybe wider than most would imagine. Its also maybe a bit bias selecting to make it through academia systems with high intellectual rigor to on average have more romantic or irrational ideas about impressive human intelligence and genius. But its also quite possible to view it as a pattern matching neural networks and filtering where much of it is flawed and even the most impressive results are from pretty inconsistent minds relying on recursively flawed internal critic systems, etc.
Looking at the poem in the article I would be more inclined to call the end human written because it seemed kind of crap like I expect from an eighth grader's poem assignments, but probably this is the lower availability of examples for the particular obsessions of the requestor.
I'm afraid he might be a true believer. The more money and/or power one gets, the fewer people push back against fanciful ideas or simply being wrong, and one can believe one is right about everything.
Safari's problem has never been the lack of supported standards, more that the support is buggy. You'll find that yes the feature is there but it throws a nonsense exception in a weird case and same in CSS.
It's also the last non-evergreen browser so bugs take longer to fix than Firefox or Chrome, compounding the problem.
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?
reply