Every time I try to do something with modern JS I'm reminded of this blog post (https://peterxjang.com/blog/modern-javascript-explained-for-...)
And also every time I end up giving up because it's so damn complex
I’m currently fixing a React app for client. I’m convinced the previous “Dev Team” had no idea how it all actually worked.
It’s all so fragile they seemed to never be able to change anything with breaking something.
You can't expect React to do that. It's just a tool.
React takes a developer from zero to one very quickly, but the rest is the craft.
Build scripts? LOL! Learn FTP sucka, and copy those files manually.
Wait… now I'm on a Windows server? What in the hell is ISAPI?
Now you want to send an email from that contact form on your site? Better learn how to set up sendmail servers. (WTF is m4? I need a macro language to generate the config file for my email server?!)
document.write("Hello World!");
Fast forward to 2004. Firefox (or was it Phoenix?) is hoping to slowly wrench dominance away from IE, but for now frontend devs gotta know ActiveX (insecure), Java applets (slow as molasses), and Macromedia Flash (you've got a DSL connection, right?). Don't forget JS has competition in VBScript. And oh, those .htc behavior files. All the old <font color=red> and table-based layouts are passé, and folks are demanding they be rewritten in that cool CSS now that Netscape 4 usage is officially dead. Still gotta fit those PDFs in sometimes though.
HTML is looking drab compared to that XML hotness. Better get on board with XHTML! Scratch that! All the XML flavors: XSLT, XSL:FO, SOAP, XML Schema (or RelaxNG for the cool kids), XPath, SAX, X-Force! (Okay, maybe not that last one.)
Firefox is getting better so much faster than IE, so don't forget to polyfill all the things.
Jump to 2010. We've got more browser engines than we know what to do with and they all render differently. Maybe not a lot in this one case, but different enough. Bring on the JSON! The rise of JS libraries brings us the choices of Prototype (the OG, but already obsolete), YUI, Jquery, and a new entry every month at least. Tree shaking? CI/CD? What crazy talk are you spouting now? I'm just barely handling minification and manual image optimization.
-----
Thank [deity] things today aren't as complex as they were back then!
To quote BSG: "This has all happened before. And it will happen again."
If you stay on the same version of the init script, you're still marginally better than rolling your own.
On the other hand, if you learn it once and then allow updates to occur, you'll still understand the process in the abstract. You'll just have to let go of the notion of knowing all details of your stacks from top to bottom. This is why we have teams and specializations. Computing long ago exceeded typical human capacity for complete knowledge. Now we learn as much as we can including the wisdom of who to trust when the solution is bigger than we can individually muster.
We trust compilers and browsers and libraries and frameworks all the time. When they break, hopefully the broken area is in our wheelhouse or at least well-documented. But the issue of complexity isn't going away if we want to continue making forward progress.
My frontend dev setups perform auto reload on save in my IDE within a second, have clean integration with testing suites and CI/CD, and do so much beyond my ability to build on my own. Even if I were dedicated to dev build environments and had the sufficient skill to make a stable and complete solution, I will have incurred the opportunity cost of not actually solving my initial frontend problems the clients are paying me for.
Change happens.
"Dr. Strangedevelop" or "How I Learned to Stop Worrying and Love the Vite"
Also, things seem to be converging towards simplicity in a positive way, comparing e.g. Vite to Webpack.
But without any disagreement: the churn is real.
Not upgrading is only an option if you
1) are sure you don't run vulnerable code on a server (e.g. through SSR) - if any code is public-facing, ignoring most "npm audit" reports ceases to be an option. 2) don't need new packages to change your build setup that are significantly newer than your previous setup.
To repeat, I don't disagree and I prefer the spirit of your comment to my critique.
Almost all of the time it is a good idea to settle on versions and evaluate when upgrading is worth it.
Update costs can also vary a lot depending on the project.
In other words, preserving behavior while fixing dependency conflicts, breaking changes etc after updating major versions.
If one avoids to do clever stuff with the bundler and if the project requirements are simple, it can be easy upgrade or even swap tools (e.g. Webpack for Vite).
This rings very true for me, bravo:
> My frontend dev setups perform auto reload on save in my IDE within a second, have clean integration with testing suites and CI/CD, and do so much beyond my ability to build on my own. Even if I were dedicated to dev build environments and had the sufficient skill to make a stable and complete solution, I will have incurred the opportunity cost of not actually solving my initial frontend problems the clients are paying me for.
> Change happens.
> "Dr. Strangedevelop" or "How I Learned to Stop Worrying and Love the Vite"