> people know it is a problem but ideologically they really disagree about what to do about it
Can we really say this is true about individuals in the US?
I think it's pretty clear the propaganda machine has successfully privatized health care to the great detriment of the populace and have the clamps on it.
After all, if you told everyone you had a solution where insurance rates would be cheaper, their healthcare system would cost less overall, and the health outcomes would be superior, they would all be like "sounds great". Then, when you reveal this solution is the complete destruction of the insurance "industry", insurance payments are "tax", and the health provider is the government, they would balk, scream about socialized healthcare, and say how they don't trust the government.
Can you give some examples? I feel like React is still pretty much just React, having developed with it for a decade now. Hooks was the only meaningful API (surface) change, no?
I think this is the reason why React feels normal to you. But as someone coming into it fresh, React felt like there were always 4 different ways to do the same thing and 3 of them are wrong because they built a new API/there are more idiomatic ways to accomplish the same thing now. If you have a decade of experience, then you probably do most things the right/obvious way so don't even notice all the incorrect ways/footguns that React gives you.
If you're coming into it in 2025, it's even simpler. Just ignore the SSR stuff which Vercel are pushing and you're good. A lot of the path has been smoothed out over the years to make it an ideal place to start today.
You claim that React offers me multiple incorrect ways/footguns to do things, but you can't list a single meaningful API surface change besides Hooks when that was the point of my comment?
Saying React is a "bloated monster" and then not being able to provide a single example of ways it has bloated is a joke. The article we're looking at shows that the bundle size can be a bit bigger but the speed to render is equivalent to all these other frameworks.
If you really love minimal bundle sizes, go off, but bundle size is not how I would define bloat in a framework
I feel like the introduction of React Compiler was a pretty big change, too?
The article seems to make the bloat self-evident by comparing the load times of identical apps and finding React magnitudes slower.
To be fair, I haven't written in React for a few years now. I reached for Svelte with the last two apps I built after using React professionally for 4 years. I was expecting there to be a learning curve and there just... wasn't? It was staggering how little I had to think about. Even something as small as not having to write in JSX (however normalized I was to writing in it) really felt meaningful once I took a step back and saw the forest for the trees.
I dunno. I just remember being on the interview circuit and asking engineers to tell me about useCallback, useEffect, useMemo, and memo and how they're used, how something like console.log would fair in relation to them, when to include/exclude arguments from memoization arrays, etc.. and it was pretty easy to trip a lot of people up. I think the introduction of the compiler is an attempt to mitigate a lot of those pains, but newer frameworks designed with those headaches in mind from the start rather than mitigating much later and you can feel it.
> I feel like the introduction of React Compiler was a pretty big change, too?
React 19 required almost no code changes in my multiple production apps so unless I missed something, I would say the API surface was virtually unchanged by it
> The article seems to make the bloat self-evident by comparing the load times of identical apps and finding React magnitudes slower.
What are you talking about? Next.js != React, that's your own fault if you bought into their marketing. TanStack / React looks to be a slightly larger bundle size but I'm seeing FCP differences from 35ms to 43ms (React being 43ms), how is that orders of magnitude slower?
Bad faith or bad reading, I can't help you either way here
> asking engineers to tell me about useCallback, useEffect, useMemo, and memo and how they're used
What are you even trying to say? Are you implying that other web frameworks don't come with any state management, or that they are reactive, or that you don't need the concepts from React in them?
"People got confused sometimes" isn't really a defense when the alternative is a framework you only ever use on solo greenfield projects that you've never talked to another engineer about their core concepts.
Seriously, you are just peddling groupthink, there isn't a single legit criticism of React.
Next.js, on the flip side, we should all go off on those clowns, but I wouldn't touch that with a 10 foot pole so I don't see how it's even relevant.
I rolled my eyes when hooks came out and never used it again besides for work, so not really. All the frameworks on the planet and facebook is still a heaping pile of dog shit. I was spoiled by Vue's lifecycle methods and then Svelte and it was impossible to go back.
Maybe hooks are cool but the same code written in react vs vue vs svelte or something else is always easier on the eyes and more readable. Dependency arrays and stale closures are super annoying.
Sorry but I really hate React. I've dealt with way too many shit codebases. Meanwhile working in vue/svelte is a garden of roses even if written by raw juniors.
This is going to sound selfish, but I liked being a solo React Typescript developer. My colleagues worked on UI/UX, back-end, DB, specs, etc, but I was responsible for the React code and I could just iterate and iterate without having to submit every change as a pull request.
Now with Laravel, Blade and JQuery the IDE support is low but everything is easy enough and we work as a team and do merge requests and it's a chill job even if it's full stack.
Hilarious its come full circle again. React was a breath of fresh air for fe's back in the day, and now we're back at jQuery! Why the switch from React to Laravel/Blade/JQuery?
>I liked being a solo React Typescript developer.
Being a solo FE rocks. Everyone thinks you're a magician. The worst is FE-by-committee where you get 'full-stack' devs but really they're 99% postgres and 1% html.
Congrats, it's the most popular framework, no doubt there are abuses out there.
I highly doubt raw juniors are actually writing beautiful vue/svelte code, if obviously emotionally charged anecdotes are your only arguments here, I think you can just admit you see "Facebook" and crash out...
react now needs you to declare what you are not using, using a language "feature" that does not exist. It is crazy how people keep denying reality wrt React.
No. Browser dev tools are available, and make it pretty easy to do performance profiling, and get a flamegraph etc..
Just seems like the reality of things is that the number of extensions or widgets or whatever has remained low enough that this extra sorting isn't actually that punitive in most real-world use cases. As a long-time developer working mainly in VSCode, I notice no difference between performance/snappiness in VSCode compared to JetBrains Rider, which is the main other IDE I have meaningful experience with these days.
The em dash thing seems weird to me. The writing style guide for the college I attended as a freshman was big on them, and I never shook the habit. Not being able to easily conjure one was one of the biggest annoyances when I was forced to switch from macOS to windows.
> Not being able to easily conjure one was one of the biggest annoyances when I was forced to switch from macOS to windows.
I always install AutoHotkey if I have to use Windows for long periods of time. Interestingly, the bindings are so intuitive that I had actually come up with the _exact same_ bindings as macOS without knowing they existed. Imagine my surprise when I switched to a mac and found out they were there natively!
I find the em dash thing weird as well. I bunch of people who didn’t know what an em dash was a couple of years ago decided that it’s a signature LLM move.
It depends where you find it. If it's a comment, it's highly unlikely it would include careful punctuation such as semicolons, whereas for em-dash you need to do something extra as it's not available on the keyboard as a single keystroke by default, so everybody is using a hyphen instead of em-dash or en-dash.
However, a magazine article, or even a blog where the author cares might include all: printer quotes instead of straight ones, en/em dashes, ellipsis as as single character and many more. If suddenly half of the web is filled with shallow content dressed up in certain styling, people are right to feel something is not right.
OK, that macOS. On Windows you had to remember the arcane Numpad combination (provided you had a numeric keyboard). That makes it uneven - the hyphen is just universal.
Very few humans go to the effort of using a true em dash in Internet comments (almost everyone just uses a hyphen), so it's a pretty good LLM indicator when paired with a certain writing style.
Until LLMs came around, I rarely saw other people use interrupting/parenthetical clauses at all, em dash or not. Kind of the same with semi-colons even. Or bold or subtle italics.
I’ve always enjoyed the style that em dashes and semi-colons add to a piece of writing and it was what made me start using them. It was always notable to me when I noticed them in someone’s else’s writing, which was always rare.
But definitely not none— I use them in comments all the time, and have for decades. I find asinine observations conveyed with repetitive, circular wording to be a better indicator.
It just contrasts expectations of the unwashed masses with more professional writing.
If most people are used to reading social media and texts from their friends and maybe subtitles for movies, an em dash is practically never going to appear, and so when everyone and their dog start using them, well, it’s obvious something is up.
Whereas the more literate individual used to consuming writing for pleasure will have seen them regularly, and may even have employed them while writing.
One of my first jobs was as the programmer/IT/graphics guy at a newspaper. Everybody there was required to use em-dashes properly and regularly, and followed other esoteric rules from the Associated Press Stylebook that also regularly appear in LLM output.
This highlights just how much unlicensed copyrighted material is in LLM training sets (whether you consider that fair use or not).
Re: GQL - Explain to me what abstraction layer should exist between the data model and what data is loaded into the client? I’ve never understood why injecting arbitrary complexity on top of the data model is wise.
Perhaps unfettered write access has its problems, and GQL has permissions that handle this issue plenty gracefully, but I don’t see why your data model should be obfuscated from your clients which rely on that data.
In my view the abstraction layer should be in the domain of the application.
Let's say your software is HR software and you can add and remove employees. The abstraction is "Add an employee with these details". The data model should be completely independent of the abstraction. I.e. nobody should care how the model is implemented (even if in practice it's maybe some relational model that's more or less standard). Similarly for querying employees. Queries should not be generic, they should be driven by your application use cases, and presumably the underlying implementation and data model is optimized for those as well.
But I get it the GQL can be that thing in a more generic schema-driven thing. It still feels like a layer where you can inadvertently create the wrong contract. Especially if, as I think the case is, that different teams control the schema and the underlying models/implementation. So what it seems to be saving teams/developers is needing to spell out the exact requirements/implementation details of the API. But don't you want to do that?
How do people end up use GQL in practice? what is the layer below GQL? Is it actually a SQL database?
For instance, while I work in small teams, I’ve relied on Hasura GraphQL-Engine a lot for my api. This is a full GQL API automatically generated from your SQL schema, Postgres being the best supported DB. GQL relations are available across foreign keys (or manual joins which I never use), so a well defined normalized schema can have deeply nested queries executed easily with full type safety for the consumer.
Taking an HR example, you could query for an employee, their PTO status and accrual history, their manager, and their reports all in one nice easy query that no one has to write any business logic for, just a schema set up with employees, manager, reports, and PTO tables joined on ID keys.
And in such a case, what abstraction does the backend team need to put in front of the schema? I can’t motivate what this means myself. A well designed DB schema is truly a beautiful contract, and with table and column comments you can even get intellisense docs in the IDE for the front end team building the client.
On the flip side, I agree the write operation should be done thru an API when there is complexity and requirements beyond just writing one row to one table, but read operations are much more graceful and speedier to define in GQL than REST.
I mean, Canada has had a tepid response to the implosion of their neighbour and relations - I think they have done little outside some retaliatory tariffs and “committing” to a 10 year plan to double trade with non American partners.
Is that really such a bold set of accomplishments that Ford should be shutting his mouth and falling in line behind? Trump could change his mind because Putin or Miller or Vought tell him to, no need to act like precarious progress is precious from my perspective
I think the title undersold it. I would call it "a nonexhaustive set of abuses of casting in TypeScript"
I actually thought that calling out the `is` operator was useful, I have a generic utility method I call `filterFalsy` which takes `T | undefined | null` and returns `arg is T`, which seems decently safe, but it's interesting how it would fail when asserting between two types.
Unconvention 2 made me vomit, inlining a function like that would never pass code review, indeed if you remove the mutator from being declared inline it restores type soundness as you would expect
Unconvention 3 is important to learn, TS "duck typing" is not resilient to usage of spread/Object.(keys|values|entries)
Unconvention 4 is why I argue to use `callback: () => unknown` whenever you won't use the return type, it is the least restrictive and also implies to stay the hell away from that return value.
Please, bundling React with Next is completely foolish. React is open, battle-hardened, type safe, and well-documented, while Next is... a vendor lock-in trojan horse targeting low-knowledge developers with concepts that seem beginner-friendly.
I can understand making legit criticisms of React, no doubt the hooks transition had some issues and the library has a high level of complexity without a clear winner in the state management domain, but pretending React is peddling shit like "use workflow" is frankly low effort.
Just shows you how absolutely little people know about the web ecosystem - most people heard something once or twice from someone else and just assume its true - to make matters worse, you have the typical HN "vanilla html and js only!!!" bandwagon which, if you try to use for any serious web application will only lead you down a path of much pain and suffering. I've commented many times in many other threads that I just don't get it; I probably never will.
Mate, don't get mad at us just because you can't code without a framework.
React was created to make low skilled people capable of shipping low quality code. If that is the only thing you can do, I'd be careful about calling yourself fullstackchris
Can we really say this is true about individuals in the US?
I think it's pretty clear the propaganda machine has successfully privatized health care to the great detriment of the populace and have the clamps on it.
After all, if you told everyone you had a solution where insurance rates would be cheaper, their healthcare system would cost less overall, and the health outcomes would be superior, they would all be like "sounds great". Then, when you reveal this solution is the complete destruction of the insurance "industry", insurance payments are "tax", and the health provider is the government, they would balk, scream about socialized healthcare, and say how they don't trust the government.
That's a trained response, not a real thought.
reply