title: Put the knife down and take a green herb, dude. |
descrip: One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com Using 89% of the same design the blog had in 2001. |
FOR ENTERTAINMENT PURPOSES ONLY!!!
Back-up your data and, when you bike, always wear white. As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green. |
|
Thursday, January 09, 2020 | |
I don't recall when I signed up for it, but I routinely get a newsletter from Baldur Bjarnason about software development with a focus on web development. 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.)
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.
Then he has a few points that serve as a sort of manifesto for the non-enterprise developer.
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.
Anyhow, it's a good, thought provoking post, and worth a full read. Labels: development, enterprise, javascript, npm, web, web 2.0 shiite posted by ruffin at 1/09/2020 10:06:00 AM |
|
| |
MarkUpDown is the best Markdown editor for professionals on Windows 10. It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support. Features you won't find anywhere else include...
You've wasted more than $15 of your time looking for a great Markdown editor. Stop looking. MarkUpDown is the app you're looking for. Learn more or head over to the 'Store now! |
![]() |
|
|