The article is certainly shallow, and its title is clickbait, and it says things that will make some web developers roll their eyes, and of course LLMs are now available to anyone — but what makes you think this particular article was written by an LLM? What are the telltale signs?
It’s more of a vibe, as they say :) Things that cumulatively feel off: overly descriptive headers, overuse of flowery language (“we’re entering a new age where A is B, where X coexist peacefully with Y”). Lots of “isn’t X but Y”, “not X, just Y”. In general the rhythm and the tone is a tell (authoritative and scoldy but vapid and bland at the same time).
Since LLMs emulate human writing, what is it about that sentence that gives away that it was written by an LLM rather than human? Haven't we seen plenty of hollow-sounding self-aggrandizing marketing copies like this one pre-LLMs? What is it that is wrong with this sentence?
It sounds like corporate meaningless drivel. Everyone is dogging on it because it's no different than when startups of yore would say "making the world a better place." As if the meaningless platitude was some incantation you had to whisper or the funding wouldn't close.
...is a loaded question, with a complex and nuanced answer. Especially when you continue:
> it's worth paying the React complexity/page-weight tax
All right; then why do we code in React when a smaller alternative, such as Preact, exists, which solves the same problem, but for a much lower page-weight tax?
Why do we code in React when a mechanism to synchronize data with tiny UI fragments through signals exists, as exemplified by Solid?
Why do people use React to code things where data doesn't even change, or changes so little that to sync it with the UI does not present any challenge whatsoever, such as blogs or landing pages?
I don't think the question 'why do we code with React?' has a simple and satisfactory answer anymore. I am sure marketing and educational practices play a large role in it.
My cynical answer is that most web developers who learned their craftsin the last decade learned frontend React-first, and a lot of them genuinely don't have experience working without it.
Which means hiring for a React team is easier. Which means learning React makes you more employable.
> most web developers who learned their craftsin the last decade learned frontend React-first, and a lot of them genuinely don't have experience working without it
That's not cynical, that's the reality.
I do a lot of interviews and mentor juniors, and I can 100% confirm that.
And funny enough, React-only devs was a bigger problem 5 years ago.
Today the problem is developers who can *only* use Next.js. A lot can't use Vite+React or plain React, or whatever.
And about 50% of Ruby developers I interviewed from 2022-2024 were unable to code a FizzBuzz in Ruby without launching a whole Rails project.
My job during the hiring process is to filter them.
But that's me. Other companies might be interested.
I often choose to work on non-cookie-cutter products, so it's better to have developers with more curiosity to ask questions, like yourself asked above.
These people ganging up on you, felt really bad because I support your claim.
Let me help you with a context where LLMs actually shine and is a blessing. I think it is also same with Karpathy who comes from research.
In any research, replicating paper is wildy difficult task. It takes 6-24 months of dedicated work across an entire team to replicate a good research paper.
Now, there is a reason why we want to do it. Sometimes the solution actually lies in the research. Most of research is experimental and garbage code anyway.
For each of us working in research, LLM is blessing because of rapid prototyping it provides.
Then there are research engineers whose role is to apply research to production code. We as research engineers really don't care about the popular library. As long as something does the job, we will just roll with it.
The reason is simple because there is nothing out there that solved the problem.
As we move further from research, the tools we build will find all sort of issues and we improve on them.
Idk about what people think about webdev, but this has been my perspective in SWE in general.
Most of the webdevs here who are coping with the fact that their react skill matters are quite delusional because they have never traversed the stack down to foundation. It doesn't matter how you render the document as long as you render it.
Every abstraction originates from research and some small proof of concept. You might reinvent abstraction, but when the cost of reinventing it is essentially zero then you are stilfing your own learning because you are choosing to exploit vs choosing to explore.
There is a balance and good engineers know it. Perhaps all of the people who ganged up on you never approached their work this way.
> No, nothing this simple should really be a web component
...he writes about a custom checkbox.
This is one of the things I've been having problems with. Because the way many frontend developers have been trained by react and other component-based libraries is that a custom checkbox should absolutely be its own component that encapsulates the styles and behaviors that are specific to it. It's painful if this now goes against the grain of the web platform.
> And I had to highlight the incredibly talented team I worked with and the amazing managers that taught me so much.
I wonder what it was that the amazing managers taught him. I've never had an experience with managers that would leave such an impression on me. Fellow developers, sure; but not managers.
I haven't looked into this deeply; but for several years now Jen Simmons has been posting stats in which Safari is either the top scorer for interop, or is very close to the top. For example: https://front-end.social/@jensimmons/115749303356986835
I do not know enough to tell whether this means that modern Safari has finally stopped being the new IE6, or that she is just doing marketing that misleadingly focuses on some features, while other, more frustrating and more deeply rooted, issues remain.
You want to work on your house and prep your food? I am the complete opposite. I would rather work on building a website, and eat in a canteen, than work on my house or my food.
Been building websites for 20 years, and writing code, studying math, building electronics since the 80s. Along with building homes from foundation up, rebuilding cars... Hedonic treadmill; individually, none of those things are enough anymore.
For me having to put so much time into riding a tightly focused job escalator is hell.
I can relate to this... I've been supporting myself for 30 years building apps and websites by the hour, for hourly wages, while working on my own years and years long projects on the side which make no money. I count 8 of them which took at least a year to code, and only 2 which made a small amount of profit. But I think this is actually a pretty great arrangement. I consider myself lucky to work in a kitchen all the time and still have the spare time to try building my own restaurant. I don't look at it as getting paid to waste my time, I look at it as getting paid to improve my skills, and to see the things that other people are missing, the gaps I might be able to improve upon.
Don't tell me you don't have time to do your daily web job and also work on your house. That's a first world problem if I've ever heard one.
Why does a site even need a light/dark toggle, when you can just use prefers-color-scheme in CSS, and the user can select that in their browser settings?
Because being able to switch from light to dark mode by clicking a single button is a useful feature, and while it would be nice if operating systems provided this out of the box, many (e.g., Windows) do not.
> Why does a site even need a light/dark toggle, when you can just use prefers-color-scheme in CSS, and the user can select that in their browser settings?
Good question, especially since the Ruby site already does this by default. Perhaps the argument is that one of the two color schemes may be designed so poorly that the user may want to manually switch to the other one.
Because as a user, I want to change the light/dark of your site, not every set, and not my OS. If you don't have a toggle, you are making assumptions that aren't accurate.
I am assuming that if the user selected a specific brightness mode, they want sites they visit to respect that theme. Call me crazy but this seems like common sense.
I know some web developers think that that’s true, but looking at the average people I know, they tend to want different settings depending on the site. People don’t generally want computer-wide settings for darkmode.
This is true, also for people immersed in this world. Sometimes the dark mode of a site is ass, and it's better to set a preference for that site to use light mode to make it more usable.
It could be done with :indeterminate state (so key in a cookie would be absent or removed when switching), but I'd probably would do it with radios instead
Note that a checkbox's indeterminate state can only be set via JavaScript, so that lessens the elegance of a CSS-based approach.
I agree that using radios would be better. Or just prefers-color-scheme, which sidesteps the FOUT issue that often occurs when storing theme settings in localStorage.
reply