I'm glad I learned React during the time when React.createClass was the only way. It was simple and intuitive. At that time the docs included a very lengthy discussion of what should be put inside the class and what should be passed via props. It was very helpful when it comes to teaching newcomers to architect their app. It also carried over the years of intuition by the typical dev working with OOP. Much better than the current trend of using hooks for everything.
I disagree. With classes, everything was stateful (because, y'know, classes). People were doing all sorts of crazy thing with the lifecycle methods and it was always a pain to have to remember the "this scope" and bind your event handlers. I saw so many bugs written by people who lost track of what "this" was.
Both paradigms have foot guns but having used both I much prefer the hook version.
Aye. Sign of the times. You're 20+ years in, so I'm preaching to the choir and old-man-yelling-at-cloud here.
Cargo culting + AI are the culprits. Sucks to say, but engineering is going downhill fast. First wave of the shitularity. Architects? Naw, prompt engineers. Barf. Why write good code when a glorified chatbot could do it shittier and faster?
Sign of our times. Cardboard cutout code rather than stonemasonry. Shrinkflation of thought.
Peep this purified downvote fuel:
Everything is bad because everyone is lazy and cargo cults. Web specifically. Full-stop. AI sucks at coding and is making things recursively worse in the long run. LLMs are nothing more than recursive echo chambers of copypasta code that doesn't keep up with API flux.
A great example of this is the original PHP docs, which so, so many of us copypasta'd from, leading to an untold amount of SQL injections. Oopsies.
Simalarily and hunting for downvotes, React is a templating framework that is useful but does not even meet its original value proposition, which is state management in UI. Hilariously tragic. See: original example of message desync state issue on FB. Unsolved for years by the purported solution.
The NoSQL flash is another tragic comedy. Rebuilding the wheel when there is a faster, better wheel already carefully made. Postgres with JSONB.
GraphQL is another example of Stuff We Don't Need But Use Because People Say It's Good. Devs: you don't need it. Just write a query.
-
You mention a hugely important KPI in code. How many files, tools, commands, etc must I touch to do the simplest thing? Did something take me a day when it should have taken 30s? This is rife today, we should all pay attention. Pad left.
Look no further than hooks and contexts in React land for an example. Flawed to begin with, simply because "class is a yucky keyword". I keep seeing this in "fast moving" startups: the diaspora of business logic spread through a codebase, when simplicity and unity is key, which you touch on. Absolute waste of electricity and runway, all thanks to opiniation.
Burnt runways abound. Sometimes I can't help but think engineering needs a turn it off and then on again moment in safe mode without fads and chatbots.
> Everything is bad because everyone is lazy and cargo cults.
It’s an interesting series of events that led to this (personal theory). Brilliant people who deeply understood fundamentals built abstractions because they were lazy, in a good way. Some people adopted those abstractions without fully comprehending what was being hidden, and some of those people built additional abstractions. Eventually, you wind up with people building solutions to problems which wouldn’t exist if, generations above, the original problem had been better understood.
The road is paved with good intentions, it's not they were lazy but they had intent to distill wisdom to save time. Then yes, the abstractions were adopted without fully comprehended what was hidden, and those people then naively built additional layers of abstractions.
So yes, if the original problem had been better understood, then you wouldn't have a generation of React programmers doing retarded things.
Having watched many junior developers tackle different problems with various frameworks, I have to say React is conducive to brainrot by default. Only after going through a fundamentals-first approach do you not end up with one kind of spaghetti, but you end up with another kind because it's fundamentally engineered towards producing spaghetti code unless you constantly fight the inertia of spaghettification.
It's like teaching kids about `GOTO`... That is, IMO, the essence of React.
> it's not they were lazy but they had intent to distill wisdom to save time.
Yes – I was referring to lazy in the sense of the apocryphal quote from Bill Gates:
“I choose a lazy person to do a hard job, because a lazy person will find an easy way to do it.”
> Only after going through a fundamentals-first approach do you not end up with one kind of spaghetti, but you end up with another kind because it's fundamentally engineered towards producing spaghetti code unless you constantly fight the inertia of spaghettification.
I’ve been guilty of this. Thinking that a given abstraction is unnecessary and overly-complicated, building my own minimal abstraction for my use case, and then slowly creating spaghetti as I account for more and more edge cases.
Very cool article. Semantics are important and key. Article nails it.
Reduce, reduce, and then reduce farther.
I'll add my 2c: Ditch the cargo cults. Biggest problem in software dev. I say this 30 years in.
Hard lesson for any young engineers: You don't need X, Y, or Z. It's already been invented. Stop re-inventing. Do so obsessively. You don't GraphQL. You don't need NoSQL. Downvote away.
Pick a language, pick a database, get sleep.
Never trust the mass thought. Cargo culting is world destroying.
Isn't that... ironic? You can Postgres -> GraphQL pretty much without code (pg_graphql). And then link your interfaces with the GraphQL endpoints with little code. Why re-invent with REST APIs?
I need somewhere for my objects to live. Objects are not relations.
Scattering their data across five tables, to fit the relational model, so I can later JOIN them together again, has to be the biggest example of cargo culting in the whole field.
Time spent on "incidental complexity" (new features, key fixes, performance) versus time spent on "accidental complexity" (anything and everything else).
Easy metric to understand, easy metric to teach, just remember that it applies to teams and not individuals.
CTEs are extremely useful mechanisms for writing modular and easily maintainable queries, particularly around anything to do with ETL, graphs, and timeseries data. Highly recommend.
reply