People can write bad things in every language. "It takes a lot of skill to write Java in any language." is a pithy quote for a reason.
The issue is usually frontend pedagogy or the lack of it. Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky". I've never met anyone who learned frontend anything in school to a degree that matters, so everyone is either learning from other junior devs on the job, from blog posts that are often wrong, or from a backend engineer who was pressed into learning frontend.
Yes, JS has a very tortured history coming from the fact that it was not intended to be the long-term development language for web interactivity from the start, but we also don't really teach how to do it properly.
> Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky"
Here's a secret nobody told you: You don't need to learn frontend specifics. All the same lessons from business software engineering apply.
I not-graduated comp sci in 2012 and have been building webapps since before jQuery was cool. It's nothing special. The biggest problems are always the same: data and domain modeling, managing complexity, teamwork, and state consistency.
If your comp sci degree didn't teach you how to apply solutions to those problems in any context – frontend, backend, iOS, firmware, desktop app, Android, or data pipeline – then it was a worthless degree and you should get your money back. The point of comp sci is to learn about the ideas behind the scenes, not about specific frameworks.
Data modelling and managing complexity (or I prefer to say knowledge organization) is a prerequisites for every software program ever.
I'd add one more: System design.
Basically dealing with many asynchronous moving parts, managing entities' lifetime, separating and categorizing domain/data, and understanding what-is-important-to-whom. It is a knowledge that's applicable whether you are programming a kernel scheduler or managing people and projects
Yep and nowhere seems to teach this in practice other than job sites. I’m building a team right now with two mid level engineers and a junior. They’re great and I couldn’t ask for better guys to be clear; but your point stands.
They don’t understand this (subsystems architecture and the the living data model.) It’s like they think I have a giant list of existing solutions to every problem that they haven’t memorized yet so when hit with a problem needing a subsystem they were basically useless until I slowly started teaching it to them. I’m talking Ivy League kids with degrees I only ever dreamed of getting. There brains just aren’t trained to architect systems the way I expected junior/mid level engineers to be as a self taught engineer.
Also the data model stuff has been a real painpoint for me. We were set up with graphql and Postgres so of course the MVP forwent any working data store other than react states.
Eh, to some degree you do get a starting point in uni for various things. You’ll learn basic models for systems or databases as part of core requirements. If a web course exists, it’s most likely optional and out of date.
Web is certainly a different context, and some people struggle to pick it up. There’s no authoritative book like the C Programming Language, and the web is full of wrong information that sometimes comes above more authoratitve sources like MDN in Google results.
This is absolutely correct from the perspective of a senior developer. Junior devs generally haven't completed enough language/framework hype cycles to develop the required experience (or cynicism really) to look past the bullshit to this very simple fact.
how we present has changed a lot, though. And we reap the rewards of not teaching.
As a general example, part of why accessibility on the web is so poor is because we don't teach anything about it. It's become this mythical scary thing, when in reality a lot of the pain is avoidable with a little bit of thinking. We just don't teach any of it.
If we're talking language level (even in C, you'd usually be using other libraries and APIs even if it's just POSIX or curses), I'd argue that "JavaScript: The Good Parts: The Good Parts" is probably the most authoritative book out there.
This isn't that. My hostile working definition of a framework is something that
. breaks core assumptions about a language or system
. limits what a user is permitted to do
. increases complexities by adding new abstractions
. has non-specific specifications by using unclear and imprecise language
At the end you are hardly writing software. Instead you're deep into a world of new abstractions and are fundamentally limited by these abstractions.
Frameworks work at a subconcious level. They permit the users to be constantly busy as they chaperone codebases which would otherwise have long term stability all while staking the claim that it's the fastest and easiest solution.
Because frameworks exist primarily in a product space it's worth looking at their value proposition. Frameworks essentially act as a modern facilitator to what Frederick Winslow Talor called "Soldiering" in the text "Scientific Management". Essentially this means "the evasion of work or duty", the workers you wish to provide to have a vested interest in their own well-being and do not benefit from working above the defined rate of work when it will not increase their remuneration.
Normally a manager would have every reason to dismiss these programmers. To combat this natural inclination, a proper framework makes sure this is impossible by making them unfirable.
Given a product:
. Systems should not continue to function without the programmer
. Code has to constantly be rewritten in order to achieve the same ends
Also it permits the users to go on constant employer funded vacations to conferences and training sessions.
From a professional programmer's point of view, the primary goals of any framework are to provide the users with the following:
. Job security by ensuring brittle applications
. Endless tasks by ensuring endless complexity
. A sense of elitism and entitlement
. No expectations of deliverables
. Be vague enough so blame can get shifted if things break
By making every project asymptotically impossible to deliver vaporware, the ideal framework ensures that people are always doing something while at the same time nothing ever gets done.
The old is dying and the new cannot be born; in this interregnum they're on salary so they make it last as long as possible.
In trades where there's no guilds or unions, there's a tendency to create career protection through other forms of tribal qualification systems or arcane knowledge. Making things intentionally complicated so that only a select few people can comprehend them is a common way to capture and exercise power.
People adopt the patterns because they want to have the perceived protective properties of the obscurities.
Worlds of irrelevant relations and materially meaningless abstractions are essentially how fields such as fortune telling and astrology continue unabated. The form becomes the function and the elaborations its aesthetic.
...
Btw, this is a collections of excerpts from a 40 page document I have on the psychology and function of frameworks on how the most popular ones service human emotion that I've been working on off and on for a while.
That reads like a parody to me - the cynical engineer that uses conspirational thinking patterns to create a narrative of the world when emergent outcomes are the causes.
Look for counterexamples where your cause incentives don’t exist yet the same outcomes still do: that is scientific thinking.
> Job security by ensuring brittle applications
> Endless tasks by ensuring endless complexity
> A sense of elitism and entitlement
> No expectations of deliverables
> Be vague enough so blame can get shifted if things break
The last thing many programmers desire is a millstone of old code they are responsible for. Perhaps you posit that they subconsciously desire to make complex code to give them job security? I suggest you watch (or ideally become) a founder engineer, who’s incentives are the opposite of all the above, yet the founder still ends up with the same problems.
All these things are tools and you can wrestle with tools or have them make life easier.
The question is about in what direction this tools assuage the creative process.
I've had the luck of seeing and being involved in codebases to both billion dollar successes and million dollar moneypits.
There's certainly patterns and difference I've seen.
The most notable one is successes seen to use a lot of boring unexciting old software with ugly websites.
Like say emacs, that's got an ugly old site. Or what about GCC? How about the Apache site? It doesn't even hype up how amazing and easy your life is with their simple and elegant efficient masterpiece. What about debian.org? FFTW? PCRE? Sqlite? imagemagick?
Now compare this with react and vue.
One is "we have this tool" and the other makes lofty emotional pleas about your relationship with your work. They're fundamentally different approaches and thus have fundamentally different outcomes.
One accomplishes a goal while the other accomplishes an affectation.
The premise is how to write a successful framework. The cynical takes are presented as advice.
It's structured like those guru business books like "Blue Ocean Strategy" or "Little Bets".
That genre requires an additional separate focus and some further work. It's by a bunch of narcissists who ran multiple businesses into the ground who pivoted to being a guru and offer acronyms, charts, and X-point frameworks in tidy books with a bunch of business examples, most of which catastrophically collapse within 12 months of publication.
And then the books sell 5 million copies, the authors get Ted Talks, it's the same mechanism at play. People pass around their Clayton Christensen of Geoffrey Moore diagrams and crib paragraphs quoting them like they're bible passages. And people eat it up. It's wild.
I remember looking at the Appendix of one of Jim Collins books for the first time about 10 years ago where he talks about his methodology with his team. When you start cross-referencing and see the omissions, mistakes, and misrepresentations, it's wild. I was like "wow this thing is nonsense".
You've got Sutherland's Scrum, Collins BHAGs, and you burn through $20,000,000 in Series A without releasing shit. Alright, I guess that's what we do.
This is a great reply and something I've noticed IME as well. I'm sure there is an economic term for it, but it's like perverse incentives coupled with unconsciousness.
Echoing the other replies that we want to read more of your thoughts (book, articles, blog). Is your site in your profile the best way to follow you?
This is easily the most accurate description of what a frameworks are and the consequences of their adoption I have come across in my 25 years of experience in industry. A not so minor quibble: I think most end users of frameworks approach framework selection with good intentions, likely from a position of naivete, rather than from some sociopathic desire to build a bunker for themselves in their workplace. This of course doesn't change the outcomes.
> Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky"
And rightly so, because frontend web development is not Computer Science.
The issue is usually frontend pedagogy or the lack of it. Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky". I've never met anyone who learned frontend anything in school to a degree that matters, so everyone is either learning from other junior devs on the job, from blog posts that are often wrong, or from a backend engineer who was pressed into learning frontend.
Yes, JS has a very tortured history coming from the fact that it was not intended to be the long-term development language for web interactivity from the start, but we also don't really teach how to do it properly.