JS development in 2025

Recently I talked to other software engineers looking to build some simple apps, and recommended RedwoodJS as a simple starting point (based on this earlier post). Since these folks haven't written production JavaScript in recent years, I realized that there were quite a few decisions to make and understand... many of which I didn't really understand myself either, despite working in JavaScript more seriously the last 5 years (and casually the 5 years prior).

So, this post is an attempt to summarize the state of JavaScript development (abbreviated JS below) going into 2025. Think of its target audience as any of these personas: a college new grad eager to jump into the industry; a vetern to programming who has been spared from needing to write JS thus far; or someone who, like me, has worked with JS for a while, but at this point feels too afraid to ask "why?"

If any of those descriptions sounds like you, read on! We'll explore the reason JS development can be summarized as a glorious and schizophrenic chaos.

Summary

1. Use nvm to install node
2. Run corepack enable to allow packages to specify their package managers and node versions
3. Read the rest of the table below

The Table

The table is divided up into 2 layers: run the code; write the code.

The "Recommendation" column assumes you can change that decision (for example, when you're starting a new project); in reality, if you're contributing to an existing codebase, it'll have a lot of decisions made already, so all recommendations go out the window.

⬇️ NOTE: "Recommendation" options denoted by (R) are supported out-of-the-box by RedwoodJS.

Explanations Elaborated

"Glorious and schizophrenic chaos" is neither praise nor critique for the language, but more a reflection of how JS has evolved in a distributed way over the years, and an explanation to brace yourself for its tradeoffs.

• The "Glorious": JS can run everywhere! Many other languages can be transpiled to run in browsers, but JS runs natively. So it can feel glorious to build an entire app using the same language... well, mostly, as explained below.
• "Schizophrenic" is an important reminder that working with fullstack JS means writing in two languages, one for the frontend and one for the backend. They just happen to have the same file extensions and use the same syntax!
• Finally, "Chaos" reflects the various configurations and decisions that arise from its rapid development over time.

The rest of the post will attempt to help you navigate through it all, and emerge with your sanity mostly intact.

Backend Server

Language choice for the backend is worth a post itself, so for brevity, we'll assume we want to use JS. While that is not necessarily the best deciding factor, having "one" language (ignoring the "target versions" consideration!) is a glorious simplification to make when starting out, before we see other factors like performance arise.

Within JS, several options exist today (node, deno, bun), and I recommend node purely from its long-established usage.

Node has different versions (just like Python, Rust, etc.), and the packages you want to use may target a minimum requirement that necessitates a higher one than what your machine currently has installed... or a lower one.

So, nvm helps quickly switch between versions. This also helps resolve seemingly random permission issues that may arise from otherwise installing node globally, as explained in this StackOverflow question.

Finally, the choice for node v22 in 2025 is simply because it's new enough to be officially well-supported (as the current Long Time Support edition), but not so new that there are still bugs to be ironed out.

Frontend Web Bundling

Unlike the execution of JS on the backend that has direct access to source files, frontend JS execution requires the code to somehow be delivered to users' browsers. This has evolved quite a bit over time, in both the way a programmer needs to separate their modules and how those modules will actually be assembled and delivered.

This article by Devlin Glasman on Modules and Bundling does a great job elaborating on the history over time.

The choice for vite is due to its speed and plugin system. I've also seen other options like webpack and esbuild, but vite seems to be the current widely preferred choice.

Target Version

JS's language specification is abbreviated ES for ECMAScript, whose namesake Wikipedia article elaborates on the history. To over-simplify a bit, we can think of these as synonymous for the purpose of the rest of this post:

• JS
• JavaScript
• ES
• ECMAScript

For a language like Python, it's both a language and an implementation: python.org defines the language specification and provides a default implementation CPython, elaborated in this Reddit thread. That allows for a more straightforward standardization process.

In contrast, JS is just a language standard, and there's no prescriptive implementation when you (or your users) open a browser or fire up a backend service. But over time, it inevitably had to evolve to fill in various gaps, like how to handle async processing (callbacks -> promises -> async functions) and what default functions exist on Array objects.

Put another way, JS has had a distributed evolution, from different engines implementing a language specification standard, that happened simultaneously with the evolution of that standard itself.

• Runtime engines include JavaScriptCore, SpiderMonkey, V8, each of which are used in some browser frontends and server backends
• The language specification has evolved as part of a committee called TC39. In theory, anyone can make recommendations and proposals to the committee; someone I knew from college added Array.prototype.includes!

Long story short, the choice of ES2022 is a balance between "new-enough" language specifications, and old-enough to have enough browser support. This is similar to the decision for the Backend Server, but can be more conservative and prefer an even older option if your app needs to run on older browsers.

Module Type

There are two considerations here:

• Type of the module for my own project, as defined by a Node project's package.json
• Type of the module I want to use/import

The earlier mentioned article by Devlin Glasman on Modules and Bundling is also a relevant read here that explains the difference between CommonJS and ES Modules.

The recommendation for ES Module is for the first consideration ("my own project"), since they can also easily import CommonJS modules,

The reverse was not true for a while: CommonJS projects could not easily reuse ES Modules. And today, many packages publish as ES Modules only, with many of them linking to this disclaimer. But there seems to be some good news: if you have to use CommonJS as the module system for yoru project, you may be able to take advantage of a relatively recent feature in node v22 by Joyee Cheung to use them as well.

Typing and TypeScript

Keep in mind that a required tradeoff is that Static Typing will reject some valid code by design, which may necessitate writing the code differently.

For the latest version of TypeScript: features tend to be additive, so picking whatever is the latest version should be safe. Just be sure to install at the project scope and not global scope!

Some helpful options are off by default, and need to be enabled from a configuration file called tsconfig.json. This article provides a good initial config file. I like it because it has noUncheckedIndexedAccess enabled by default, which passes my bar for a thoughtful starting point.

Linting

Linting is very closely related to typing. It helps maintain clean coding conventions. Similar to static typing, it will reject more buggy code at the tradeoff of also rejecting some benign code. This is usually still worth it!

Other considerations

The above considerations aren't the only decisions you may need to make. The chaos of JS development means there are even more rabbit holes you can dive into.

Here is a slightly simpler table, without the "why does this exist" column since all of them have the same reason: JS has a huge ecosystem with a lot of options!

I wrote down some current recommendations and explanations here too, but consider them "smaller" recommendations -- they may still turn out to be important considerations for your app building experience, but I expect them to be more framework- or project-driven decisions not always within your control.

Inspirations and References

If you enjoyed this post, please check out some of the inspirations and references that helped me write it!

• 2023.06: A History of JavaScript Modules and Bundling, For the Post-ES6 Developer
• 2024.12: Node.js 2025 Guide
• 2024.12: How to run TypeScript in 2025