This past decade has seen a historic rise for project starters in the JavaScript ecosystem. Sometimes they're called templates, boilerplates, or scaffolds just to name a few, but regardless of what they're called, at the end of the day, they all exist for the same reason—they give developers quick and easy access to all the modern conveniences brought to us by all these new libraries and tools that ironically require time-consuming and troublesome setup processes to get them up and running.
Today, Vite, Epic Stack, and Create React App are some of the more popular options in the JavaScript ecosystem, and Lean JS App Starter (LJAS) is yet another competitor in the field. While each has their own advantages, LJAS has a few of its own that gives it unique value in the current ecosystem and may make it the right option for your project.
Most project starters successfully accomplish their goal of keeping the setup process simple and kickstarting projects quickly. However, one potential problem is that most project starters obfuscate their underlying configurations, making it difficult to understand how everything works and perform changes on your own. Sometimes it can be difficult to even know what tools you're working with under the hood. While this will never be a concern for people who will never need to make customizations, it will be an issue for those that need complete control in order to meet project requirements that are not supported out-of-the-box.
Lean JS App Starter takes a more "classic" approach where nothing is hidden. It makes working with the configs as straightforward as possible. There is no need to do anything like eject just so you can tinker under-the-hood, and none of the configs are doing anything out of the ordinary. Most of it is written similarly to what you'd write on your own if you were following each tool's getting started guides, so if you understand the basics of a tool—e.g., webpack, Babel, ESLint, VS Code—then you will be able to easily understand how LJAS uses it and consequently be able to make changes easily.
That also means that if you encounter a tool you're unfamiliar with, going through its getting started guide or skimming through its docs should be adequate enough for you to make customizations. In addition, LJAS's documentation does its best to explain how things are configured out-of-the-box and will direct you to additional external resources if needed.
While project starters have been embraced by frontend web development, they haven't seen the same level of adoption elsewhere in the JavaScript ecosystem. LJAS brings the developer experience provided by "frontend"-style project starters to Node.js and Electron, and a lot of that is enabled by relying on build tools like webpack and Babel.
Some might argue that adding a bundler like webpack is unnecessary for something like backend code because they claim that build size is not a concern there like it is for frontends. However, there are some scenarios where build size can still be an issue for developers. For instance, long deployment times can be a problem for larger projects, and bundlers can save a significant amount of time by eliminating unnecessary files and code while reducing the overall build size through other means. Bundlers are also valuable for serverless application development where they can be used to manage and stay under strict build size limits.
Compilers like Babel provide a lot of value for Node.js-based projects too. They can be used for syntax transformations so you can utilize ECMAScript features unsupported for your project's Node.js version, just like how they're used for browsers. They can also be used to deal with a lot of the interoperability issues between CommonJS and ECMAScript modules, a plight foreign to most frontend developers. Adding Babel into the workflow isn't far of a deviation from common practices too because these days many non-frontend developers rely on some kind of compilation step in their development process thanks to the popularity of TypeScript.
On top of all this, non-frontend developers can improve their developer experience by gaining access to all the benefits frontend developers have already been living with like import aliasing, code splitting, Babel plugins, webpack loaders and plugins, optimized bundling for production, etc.
For those working on multiple projects targeted for different platforms at the same time, LJAS can be particularly useful for them by providing a consistent development environment across all projects. For example, when working in your source code, you don't need to worry about differing ECMAScript versions because all projects use the same version. LJAS's webpack and Babel setup will deal with transforming the code for you so it can run properly for the target, so you only need to think in terms of "bundler-style modules" which are essentially ECMAScript modules with support for extensionless import declarations (which was popularized by Create React App and webpack). LJAS also uses the same dependencies across the board as much as possible, so you'll mostly be coding with the same technologies like Jest, Playwright, etc. whether or not you're in a project for a browser app or a project for a desktop app. These factors result in a much smoother experience when it comes to working across source code for multiple projects at one time.
LJAS offers an optional Docker-based developer environment for all projects that do not target Electron. This drastically simplifies the setup process because it cuts down the amount of prerequisites you need to just Docker. Containerized dev environments help to reduce the "but it works on my machine" problem as everything the app needs to execute will be running in a container.
If a developer has previously worked on other projects, their new LJAS-based project could encounter version conflicts when working natively with dependencies that exist outside of node_modules/ like Node.js, PostgreSQL, and MongoDB. The Docker dev environment circumvents this by having all dependencies exist in an isolated containerized environment, so you won't need to deal with the hassle of managing multiple versions and instances of each technology on a single machine.
LJAS also provides a specialized end-to-end (E2E) Docker test environment for frontend-related projects that runs the app in the production environment. This is useful for executing Playwright tests as they will perform under conditions that are as close as possible to the end-user experience, giving more value to the test results. And because it's just another containerized environment, it can be run alongside the standard Docker dev environment at the same time with no conflicts.