TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

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

2 点作者 blackbrokkoli超过 2 年前
Hi HN,<p>I want to ask your for a tech-stack&#x2F;paradigm recommendation:<p>So I am a frontend web developer by trade and I am currently grappling with the following two observations:<p>* The deterioration of most &quot;modern&quot; software (especially in the web) is incredibly quick. As in, half my browser bookmarks from three years ago just straight up don&#x27;t exist anymore. GitHub repos that are unmaintained for 8 months usually can&#x27;t be run&#x2F;build&#x2F;executed anymore, or only with a long session of hotfixing and dependency issues. Even &quot;simple&quot; projects of my own (like a jekyll site) can&#x27;t be ran anymore after a year w&#x2F;o endless dependency- and deprecation-related struggle.<p>* When trying to solve simple problems (&quot;I wish I had a program making this easier&quot;), a painful amount of development time is spent working on what <i>The Mythical Man-Month</i> calls &quot;Accidental Complexity&quot;. 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.<p>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?<p>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&#x27;t have to be via GUI, though).<p>Thanks a lot!

3 条评论

rgbrgb超过 2 年前
I think this is a great question to keep asking, but unfortunately I don&#x27;t have a good answer. I pose it as, &quot;How can we make 1000 year software?&quot; 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&#x27;s kind of like the core problem of big slow orgs (too much communication&#x2F;alignment work) but encoded in software -- a macro version of Conway&#x27;s Law [0].<p>Some quick ideas I&#x27;ve been brewing on...<p>## Product strategy ##<p>- Keep it simple and focused. Each line of code and each dependency is a maintenance burden.<p>- 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&#x27;t actually need.<p>- Minimize service dependencies. Only use services that are commodity (e.g. 3rd party SMTP provider but not GPT-3).<p>## Software stack ##<p>- Choose tools that have a big community and multiple corporate users funding them.<p>- Choose stacks that are established. I often fail here because I want to live on the bleeding edge, but there&#x27;s a reason it&#x27;s called that.<p>- Choose tools that are open source (one company dying will not kill it).<p>- 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&#x27;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.<p>- Use as few tools as possible.<p>- When in doubt, go with the lindy option [1].<p>[0]: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Conway&#x27;s_law" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Conway&#x27;s_law</a> [1]: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Lindy_effect" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Lindy_effect</a>
评论 #34315761 未加载
ale_jacques超过 2 年前
Answer: boring tech. These days I&#x27;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.<p>Django is being actively mantained for 17 years now.
评论 #34315709 未加载
Leftium超过 2 年前
If you commit the [package-lock.json] file, it ensures the same versions of the dependencies are installed.<p>Another option is to [containerize] your project.<p>[package-lock.json]: <a href="https:&#x2F;&#x2F;docs.npmjs.com&#x2F;cli&#x2F;v9&#x2F;configuring-npm&#x2F;package-lock-json" rel="nofollow">https:&#x2F;&#x2F;docs.npmjs.com&#x2F;cli&#x2F;v9&#x2F;configuring-npm&#x2F;package-lock-j...</a><p>[containerize]: <a href="https:&#x2F;&#x2F;www.docker.com&#x2F;resources&#x2F;what-container&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.docker.com&#x2F;resources&#x2F;what-container&#x2F;</a>