npm ruin dev

“Don’t get me wrong—I totally understand why complicated pipelines are necessary for complicated websites. If you’re part of a large team, you probably need to have processes in place so that everyone can contribute to the codebase in a consistent way. The more complex that codebase is, the more technology you need to help you automate your work and catch errors before they go live.”

“But that set-up isn’t appropriate for every website. And all those tools and processes that are supposed to save time sometimes end up wasting time further down the road. Ever had to revisit a project after, say, six or twelve months? Maybe you just want to make one little change to the CSS. But you can’t because a dependency is broken. So you try to update it. But it relies on a different version of Node. Before you know it, you’re Bryan Cranston changing a light bulb. You should be tweaking one line of CSS but instead you’re battling entropy.”

Dans Cheating Entropy with Native Web Technologies, billet écrit par Jim Nielsen et cité par Jeremy dans npm ruin dev:

“In my experience, authoring vanilla CSS using selectors that largely repeat is easier than more tersely authoring nested selectors but having to maintain Sass over time.”

“Similarly, authoring vanilla JS without language transpilation, bundling, etc., is easier than building and maintaining something like Babel + Webpack over time.”

“Take a moment and think about this super power: if you write vanilla HTML, CSS, and JS, all you have to do is put that code in a web browser and it runs. Edit a file, refresh the page, you’ve got a feedback cycle. As soon as you introduce tooling, as soon as you introduce an abstraction not native to the browser, you may have to invent the universe for a feedback cycle. No longer writing CSS and instead writing Sass? Now you need a development server with a build process to watch your files and compile your changes just to develop and test your project. You’ve just added a giant, blocking dependency for your project to work. And if you can’t get that dependency working, your project is dead in the water until you can—both now and in the future.”