HACKER Q&A
📣 blackbrokkoli

How do you build minimalist, future-proof, user-facing software?


Hi HN,

I want to ask your for a tech-stack/paradigm recommendation:

So I am a frontend web developer by trade and I am currently grappling with the following two observations:

* The deterioration of most "modern" software (especially in the web) is incredibly quick. As in, half my browser bookmarks from three years ago just straight up don't exist anymore. GitHub repos that are unmaintained for 8 months usually can't be run/build/executed anymore, or only with a long session of hotfixing and dependency issues. Even "simple" projects of my own (like a jekyll site) can't be ran anymore after a year w/o endless dependency- and deprecation-related struggle.

* When trying to solve simple problems ("I wish I had a program making this easier"), a painful amount of development time is spent working on what The Mythical Man-Month calls "Accidental Complexity". Configs, boilerplate, libraries. Making Heroku play nice with Docker, and make that play nice with Namecheap, and make that play nice with Stripe, and Tailwind, and LetsEncrypt...and so on.

So with these (maybe obvious) observations in mind, what is your recommendation for a tech-stack or paradigm better suited for small problems, MVPs, side projects, and so on?

I am really happy open for anything (languages, paradigms, tech, concepts, ...), the only requirements are simplicity, longevity and ability to build user-facing stuff nicely (doesn't have to be via GUI, though).

Thanks a lot!

  👤 rgbrgb Accepted Answer ✓
I think this is a great question to keep asking, but unfortunately I don't have a good answer. I pose it as, "How can we make 1000 year software?" My observation is that as the rate of change of software accelerates, the maintenance burden for applications accelerates because the environments that your programs run in changes more often. It's kind of like the core problem of big slow orgs (too much communication/alignment work) but encoded in software -- a macro version of Conway's Law [0].

Some quick ideas I've been brewing on...

## Product strategy ##

- Keep it simple and focused. Each line of code and each dependency is a maintenance burden.

- Building open source is not necessarily an antidote to this. Other devs might help develop but opening the floodgates to community dev can also introduce feature complexity that your app perhaps doesn't actually need.

- Minimize service dependencies. Only use services that are commodity (e.g. 3rd party SMTP provider but not GPT-3).

## Software stack ##

- Choose tools that have a big community and multiple corporate users funding them.

- Choose stacks that are established. I often fail here because I want to live on the bleeding edge, but there's a reason it's called that.

- Choose tools that are open source (one company dying will not kill it).

- Choose tools that are cross-platform (the complexity of making a change to the tooling because of the diversity of clients is actually a pro for you, it won't change quickly). Also you want your tools to do as much of the heavy lifting around platform compatibility as possible. An iOS app written today will not work in 4 years without changes. A web app almost certainly will.

- Use as few tools as possible.

- When in doubt, go with the lindy option [1].

[0]: https://en.wikipedia.org/wiki/Conway's_law [1]: https://en.wikipedia.org/wiki/Lindy_effect

👤 ale_jacques
Answer: boring tech. These days I'm going with Django and Unpoly. Some go with htmx and AlpineJS. In both cases, frontend is backend agnostic. These JS are 1-file dependencies.

Django is being actively mantained for 17 years now.

👤 Leftium
If you commit the [package-lock.json] file, it ensures the same versions of the dependencies are installed.

Another option is to [containerize] your project.

[package-lock.json]: https://docs.npmjs.com/cli/v9/configuring-npm/package-lock-j...

[containerize]: https://www.docker.com/resources/what-container/