Link tags: dependencies

31

sparkline

Software can be finished - Ross Wintle

There’s quite a crossover between resilience and longevity:

  1. Understand the requirements
  2. Keep scope small and fixed
  3. Reduce dependencies
  4. Produce static output
  5. Increase Quality Assurance

How to Make Websites That Will Require Lots of Your Time and Energy - Jim Nielsen’s Blog

  1. Install Stuff Indiscriminately From npm
  2. Pick a Framework Before You Know You Need One
  3. Always, Always Require a Compilation Step

Build It Yourself | Armin Ronacher’s Thoughts and Writings

We’re at a point in the most ecosystems where pulling in libraries is not just the default action, it’s seen positively: “Look how modular and composable my code is!” Actually, it might just be a symptom of never wanting to type out more than a few lines.

It always amazes me when people don’t view dependencies as liabilities. To me it feels like the coding equivalent of going to a loan shark. You are asking for technical debt.

There are entire companies who are making a living of supplying you with the tools needed to deal with your dependency mess. In the name of security, we’re pushed to having dependencies and keeping them up to date, despite most of those dependencies being the primary source of security problems.

But there is a simpler path. You write code yourself. Sure, it’s more work up front, but once it’s written, it’s done.

Lived experience

I hold this truth to be self-evident: the larger the abstraction layer a web developer uses on top of web standards, the shorter the shelf life of their codebase becomes, and the more they will feel the churn.

The State of ES5 on the Web

This is grim:

If you look at the data below on how popular websites today are actually transpiling and deploying their code to production, it turns out that most sites on the internet ship code that is transpiled to ES5, yet still doesn’t work in IE 11—meaning the transpiler and polyfill bloat is being downloaded by 100% of their users, but benefiting none of them.

“Just” One Line - Jim Nielsen’s Blog

There’s a big difference between the interface to a thing being one line of code, and the cost of a thing being one line of code.

A more acute rendering of this sales pitch is probaly: “It’s just one line of code to add many more lines of code.”

And as Chris puts it:

Every dependency is a potential vulnerability

htmx ~ Why htmx Does Not Have a Build Step

The best reason to write a library in plain JavaScript is that it lasts forever. This is arguably JavaScript’s single most underrated feature. While I’m sure there are some corner cases, JavaScript from 1999 that ran in Netscape Navigator will run unaltered, alongside modern code, in Google Chrome downloaded yesterday. That is true for very few programming environments.

And yet:

Of course, most people’s experience with JavaScript is that it ages like milk. Reopen a node repository after 3 months and you’ll find that your project is mired in a flurry of security warnings, backwards-incompatible library “upgrades,” and a frontend framework whose cultural peak was the exact moment you started the project and is now widely considered tech debt.

Jack Franklin – Abstractions, complexities and off-ramps – All Day Hey! 2023 - YouTube

This is a terrific talk by Jack on how to deal with the tooling involved in modern front-end development:

  • Maintaining control,
  • Dependency awareness,
  • Lean on browser primitives,
  • Have an exit strategy.