The concept of "owning your app" in the Javascript community is a lost art in 2024, and I'm here to explain why it's bad and why it matters

Ownership: the act, state, or right of possessing something.

In recent years, there's been a growing trend in Javascript land where, by default, core functionality and infrastructure is offloaded to third-party services and dependencies. Setting up a new project generally involves deeply coupling your database and user management to third-party services, deploying to a proprietary hosting provider, and running an app containing code from tens or hundreds of NPM packages - sometimes even for functionality like checking if a value is a number.

In a sense Javascript is a victim of its own success. Being extremely popular, the space moves fast, arguably too fast, which leaves little breathing room that would allow for standards and winners to emerge like you see in Python with Django or Ruby with Rails. Even if things moved slower, I don't think the community would accept a winner because sooner or later a new shiny thing would come along and become the new state of the art. Long gone are the days of jQuery and MooTools being the "one true way" to write Javascript apps.

The reason I think this is bad is it results in a lack of ownership.

Let me clarify that I am not suggesting that you write all functionality from scratch every time you write an app. Some usage of third-party services, packages and hosting providers are an essential part of writing a Javascript app in 2024 and I think abundance of options in these areas are one of the ecosystem's strengths.

My issue lies with the willingness of the Javascript community, spurred on by VC-backed DevRels and other influencers, to default to reaching for an off-the-shelf solution for functionality that could be easily written and owned within your app code.

Every time you choose to add a dependency for something you could have written yourself, you're making a bet. A bet that the library maintainer won't sabotage the package you use due to a lack of funding, a bet that your VC-backed database provider won't rug-pull their free tier so they can focus on enterprise, a bet that your app hosting provider wont get hacked and request you change all of your secrets, or that your auth provider won't ship a critical security vulnerability.

By delegating too much ownership to external vendors, you're not only risking security and stability but you also lose the agility to pivot and adapt your app as needed. The end-game of this approach is being so locked into proprietary database features, platform-specific APIs, and third-party dependencies that any significant change can become a major overhaul rather than a manageable update.

The path to regaining control of your Javascript app doesn't mean rejecting all third-party services altogether, rather carefully choosing which parts of your app you should own outright. In the upcoming series, I'll dig deeper into the specifics of owning various parts of your app. Specifically, I'll focus on what I feel are the areas where ownership is the most important

• Authentication
• Infrastructure
• Code

By taking a critical look at these areas and figuring out where it makes sense to maintain ownership, you can write Javascript applications that are built for the future. If this is something you'd be interested in, please sign up for the newsletter or follow me on Twitter