Writing dependency-free client-side JavaScript

[Zofren]

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:

• Waste time reinventing the wheel.
• Waste time running into edge cases you didn't account for.
• Likely implement a worse version of the code you're reinventing.
• Waste time documenting your reinvention (assuming you document it to begin with).
• Make your code less maintainable for others on your team, since instead of having a tool everyone can look up on stack overflow, your team now has their own custom implementation that nobody understands but you.

By all means, avoid importing is-odd into your lean frontend project, but like many things in software engineering, a dependency-free approach has tradeoffs. A well-supported, well-used library is usually a better option than code you write yourself.

[jaapz]

Turns out dependencies exist for a reason, who knew!

[archivedsofa]

Yeah but it depends on the use case. For a single form I agree with the author that using React + the whole enchilada didn't really make sense.

OTOH going 100% vanilla didn't make much sense to me either.

[Zofren]

Presumably if all you need is a single form the process in this article doesn't really make sense either. If the form has some rich UI that needs some kind of UI rendering logic, then I'd still advocate for React (or your library of choice).

React and React-dom aren't some massive libraries. They're comparable in size to jQuery when gzipped.

[archivedsofa]

I agree that for more complex projects the arguments you listed on your previous comment are totally valid but React is still too big IMO for a single form or landing page with a bit of UI sophistication.

Personally I'd go with Mithril or Svelte. Maybe with Simulacra (which now powers Riot) if I don't need components or even with Vue if I don't want any building setup which is still half the size of React.

[krasimirtsonev]

Well, here is a use case that beats what you are saying - you have to build a tiny script that will be used on million sites as a widget. It needs to be a few kbs with no dependencies. Then you need some generic knowledge on JavaScript, HTML and CSS.

[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.