buildless evergreen

How One Programmer Broke the Internet By Deleting a Tiny Piece of Code - an article on the history that led to the trivial "left-pad" module being removed and causing all those problems by the removal a while back. Obviously raising the question, how much is too much when it comes to depending on modules and additional libraries to do all the heavy lifting?

I'm getting better at framing the divide between my work for Enterprise, and my personal project work. That rift of technologies used has grown wider over the years, though my personal project stuff - having to take on the full stack and the complete UX/UI experience - is still a huge boon to what I bring to the table for "real jobs"

Two buzzwords for one-person-shop, long term side project works that don't apply to most enterprise efforts: "buildless" and "evergreen". Sticking with tech that is likely to stay well-supported, you minimize dependencies on third parties. For me, that means - HTML/CSS/JS that the browser supports natively (browsers are truly impressive in advancing in power at a stately pace while maintaining brilliant backwards compatibility), often it means static HTML or PHP - while some people scoff, sticking with core PHP allows me to keep just one business relationship for deploying my code and maintaining my legacy sites, and the scripting paradigm PHP uses - a clean start every time - is very amenable to thinking in terms of functional programming, despite the ugliness of its APIs.

Again, Enterprise usually finds it better to invest in good toolkits and libraries and build systems, they can take on the cost of hiring people to make a code base an ongoing concern, and it's generally worth the complexity to make sure developers are meeting the company's needs by answering the basic problems in idiomatic ways. But when I want to write code that just works for my needs reliably over years and is usually pretty easy to edit when it some functionality needs to be added, the rules of "KISS" really apply.