His new year's email includes some points on JavaScript frameworks that I'm suspicious I like because they so closely match mine.
But what they so clearly indicate is that web development has become a field whose outward appearance and, all too often, local practice, has been completely co-opted by the needs of the largest of enterprise corporations.
(Words in bullets are his. All emphasis is mine.)
- Once you step outside of the social media bubble, however, vanilla JS and more ‘modest’ approaches like Svelte or Stimulus/TurboLinks seem to have reached critical mass in terms of sustainability.Irrespective of those newer trends, jQuery and PHP-driven, un-hydrated, old-fashioned server-side rendering still utterly dominate the web that people use.
- Web dev driven by npm packages, frameworks, and bundling is to the field of web design what Java and C# in 2010s was to web servers. If you work in enterprise software [npm, framework, and bundling-through-transpilation driven patterns are] all you can see. Web developers working on CMS themes (or on Rails-based projects) using jQuery and plain old JS—maybe with a couple of libraries imported directly via a script tag—are the unseen dark matter of the web dev community.
- What should worry you is that npm- and framework-driven web development feels just as painful as enterprise software dev because it is enterprise development.
He continues by comparing TypeScript -- and I think he means more specifically "enterprise TypeScript development", because there's lots to enjoy about TypeScript the language, nothing inherently evil about it -- to enterprise Java of 20 years ago.
- TypeScript smells like Java.
- The complexity of npm packages harkens back to painful Java packaging monstrosities.
- JavaScript build systems are about as much fun as Java build systems, even though they are doing very different things.
- Deployment, as implemented in the Kubernetes and Docker ecosystems, is exactly as hard to understand and use as its Java predecessors because those are their predecessors.
Then he has a few points that serve as a sort of manifesto for the non-enterprise developer.
- Some of use work exclusively with SMBs (Small-/Medium-sized Businesses) and shouldn’t need to run the enterprise anti-productivity gauntlet. Our needs in terms of frameworks, bundling, and packages are very different from those working in enterprises with hundreds or thousands of employees.
- It is not rational to expect [developers for small and medium-sized businesses] to be using enterprise-oriented tools and environments or to demand that we be happy about being saddled with your need for complexity.
I'd also ask people to take a close look at how they define what's an SMB project and what's an enterprise project. That is, defining projects by the size of the corporation that produces them isn't always -- heck, isn't usually -- the best metric.
Where something becomes "enterprise" is when you have hundreds of people working on the same project, in the same codebase. What npm/library-based bundling buys you is the ability to firewall smaller projects from each other. If someone writes a horribly inefficient page that no rendering library could solve without magic...
... your development process already includes a baked-in firewall to ensure that code doesn't adversely impact the rest of your system. You can stitch together completely independent projects easily, iff you really need to do that stitching.
But how big is your day-to-day work, really? How many of the problems "solved" by mass package import could have been solved reasonably well for your uses with a (think what's often derisively called a "NIH syndrome-induced") roll-my-own, homebrew solution?
Put another way, how many developers are really part of your specific product?
If it's not hundreds, ask yourself how much time you'd save on developer ramp-up, maintenance, and new development if you too used "jQuery and plain old JS—maybe with a couple of libraries imported directly via a script tag". Even in a team of "just" 20-30, the resource savings from going just 25% faster (a conservative cost of doing framework-style development in my experience) are unbelievable.
I'm not sure I know when going "full framework" is the best idea. At a conference, some friends of mine (coworkers) managed to corner a guy who was then working at Google on AngularJS (before Angular 2+). We talked to him a bit about AngularJS' pain points and how they solved problems of large DOMs, as our Knockout.js-based system was getting crushed in our more dynamic, feature-rich UIs.
His basic comment was that you can't fix these issues easily, and there was no silver bullet. Inefficient or complex UIs are trouble no matter where you build them.
The problem here was browser performance, which by definition isn't an SMB or enterprise problem. It's a client-side rendering one. Frameworks don't fix these issues. "Full framework" dev doesn't provide solutions to day-to-day problems, it provides the passive coordination that allows the amalgamation of code from hundreds of developers working at once.
Is that really the state your team finds itself in? Why would you want it to be?
And then here's a final comment from Bjarnason about how the thinkspace of development has been dominated by the enterprises -- he does a good job in the balance of his new year's points discussing how we see so much enterprise-specific information because those enterprises have a vested interest in making that come to be.
- The divide between what you read in developer social media and what you see on web dev websites, blogs, and actual practice has never in my recollection been this wide. I’ve never before seen web dev social media and forum discourse so dominated by the US west coast enterprise tech company bubble, and I’ve been doing this for a couple of decades now. The pre-2000 dot-com bubble comes close although that one came attached to an actual financial bubble and happened before social media had evolved into its current form.
Anyhow, it's a good, thought provoking post, and worth a full read.