Tell HN: A production-ready "Hello World" is now ~600 files
4 comments
The JS ecosystem is a hellscape. But there’s no reason you have to use it.
I’ll stick with straightforward Python frameworks and HTMX with a bit of vanilla JS sprinkled on top. Most importantly: no JS builds, no deps that can’t be included with a single CDN-loaded script tag.
I’ll stick with straightforward Python frameworks and HTMX with a bit of vanilla JS sprinkled on top. Most importantly: no JS builds, no deps that can’t be included with a single CDN-loaded script tag.
> Then there’s the DevOps and Quality layer. We have roughly 20-30 files for GitHub Actions workflows (lint, test, build, deploy, semantic release), Husky hooks (pre-commit, commit-msg), and pull request templates.
On that , I have created http://deadsimpleci.sparrowhub.io/doc/README trying to minimize code to just normal Python/bash scripts instead of tons of yaml files …
On that , I have created http://deadsimpleci.sparrowhub.io/doc/README trying to minimize code to just normal Python/bash scripts instead of tons of yaml files …
i did a similar audit and the worst offender was duplicated config and generated files across the Next.js frontend, NestJS backend, mobile wrapper and CI. make a tiny MVP baseline you can actually ship from: one Next app, one thin backend service with a single auth route, and move CI/mobile scaffolding into a separate repo or a generator so they don't come along to every new project. consolidate shared types and infra code into a single package, kill unneeded dev-tooling files, and change heavy codegen to on-demand scripts that run when you add a feature. build a tiny CLI that scaffolds a feature folder instead of including every possible file in the base. that cut my new-project file count from hundreds to a few dozen. fwiw i used a starter kit that had auth and payments preconfigured, Vibe Coding Starter Kit, to get a production-ready baseline without rebuilding all that infra.
IMHO, generally speaking it’s not just a JS. The declarative approach has its toll we end up having a lot of configurations files instead of having (one or two) normal imperative script
The count was roughly 600 files.
To be clear, I'm not talking about a `create-react-app` sandbox. I mean a compliant, scalable SaaS foundation: Next.js frontend, Node.js/NestJS backend, mobile wrapper, CI/CD pipelines, and enough security config to pass a SOC2 audit.
It sounds ridiculous (and honestly, it feels ridiculous), but when I broke it down, I couldn't find many files I was willing to delete.
Here is where the bloat comes from:
First, the "Configuration Hell" accounts for about 40-50 files alone. We aren't just dealing with `package.json` anymore. It's `tsconfig.json` (base), `tsconfig.build.json`, `tsconfig.spec.json`... multiplied across frontend, backend, and shared libraries. Then add `.eslintrc.js`, `.prettierrc`, `jest.config.js`, `vitest.config.ts`, `nodemon.json`, and the Docker-compose variants for dev, test, and prod.
Then there’s the DevOps and Quality layer. We have roughly 20-30 files for GitHub Actions workflows (lint, test, build, deploy, semantic release), Husky hooks (pre-commit, commit-msg), and pull request templates.
But the real multiplier is the separation of concerns. In a modern monorepo, a "Hello World" isn't just `console.log`. It’s: - A NestJS module (Controller, Service, Module, DTO, Entity, Unit Test, E2E Test). - A Next.js slice (Page, Component, Type definition, API client wrapper). - A shared library entry.
We found that adding a single "minimal" API endpoint usually touches 5-7 files just to maintain architectural standards.
The trade-off is painful. On one hand, this setup handles the things we used to forget: security headers, proper logging, consistent error handling, and type safety across boundaries. It prevents the "spaghetti code" distinct to startups that scale too fast.
On the other hand, the cognitive load of managing a 600-file "empty" project is massive. Updating dependencies becomes a chore because a major version bump in one tool (like ESLint) cascades through forty config files.
I’m curious how others are handling this "starting line" complexity.
Are you accepting the boilerplate as the cost of doing business? Or have you found a way to strip this down without sacrificing the compliance/safety guardrails that enterprise clients demand?
It feels like we've over-engineered the entry point of software development, but I’m not sure what the alternative is for a serious project. We tried going "lean" initially, but spent weeks retrofitting auth and testing harnesses later—which was worse.
Is there a middle ground I'm missing, or is ~600 files just the new normal?