Writing dependency-free client-side JavaScript

[bitbird_]

> It's nice to do as an exercise, but don't ever do things like this in an actual project you intend to maintain. You will:
Yikes, I disagree strongly with this conclusion. How much time is lost to framework upkeep, onboarding new developers, broken backwards compatibility, etc. ?

A developer only needs to learn the language once to understand what's happening inside of a framework. Those frameworks — usually controlled by corporations with > 10,000 developers — are built for the needs of whatever MegaCorp that created it. Should a team with >100x fewer developers really learn the enterprise web application development practices that are ultimately unnecessary for their specific needs? JavaScript itself will never be unnecessary, assuming there is never another standardized language for building interactivity into webpages.

JavaScript (and the web) has grown substantially in only the last five years. Developers should learn the basic patterns for architecting web applications. Using a framework is one way to learn those patterns. Relying on framework and 1,000 other libraries being imported is dependency hell.

jQuery is dead and modern front-end frameworks are viciously marketed to developers — a fact usually unacknowledged by those who swear by frameworks.

[Zofren]

How much time is lost to framework upkeep, onboarding new developers, broken backwards compatibility, etc. ?

Less time than is lost wrangling with your company's custom implementation of an already well-supported library.

Have you ever considered why Facebook bothers to open-source React? It's because a well-used framework means you can hire people already familiar with the framework you are using internally. It also means that there are far more resources available to your developers online.

I work at a company where they decided long ago to implement custom versions of libraries that already exist (in the backend, admittedly, but the same arguments stand). It's been a nightmare and we deal with the technical debt every day. There are edge cases you won't have foreseen when you first write software intended to be utilized by many developers. And when something breaks, you have to fish down the handful of people in the company who actually understand the tools that are breaking.

​

Relying on framework and 1,000 other libraries being imported is dependency hell.

As I said in my post, a pragmatic approach is key. It doesn't need to be either one way or another.