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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Ask HN: What is your preferred/most commonly used stack and why?

58 点作者 loh超过 3 年前
I&#x27;m curious about what most professional developers are using these days, from languages to deployment, and what they&#x27;re building with it.<p>There&#x27;s a lot to choose from and it seems like a few are really taking the lead. Maybe I&#x27;m biased but I prefer TypeScript, React w&#x2F; Styled Components, and PostgreSQL, all of which seem to be pretty dominant. TypeDoc is also really nice for generating clean documentation from type definitions and comments, and Jest for both front-end and back-end unit tests. I usually deploy (static) progressive web apps to Netlify and APIs to Heroku, but I&#x27;ll probably try Render next.<p>If you&#x27;re like me, you probably like to keep things to a minimum, optimized for a specific purpose without any bloat or unnecessary loose ends. I&#x27;ve built many different apps over the years and found myself repeating the same core functionality for each of them, each with their own slightly different stack and implementation as tools and ecosystems have evolved. I&#x27;d imagine this is the case for most experienced developers who enjoy building things from the ground up, without becoming dependent on an elaborate framework.<p>Last Friday I launched a project called Molecule.dev which aims to provide developers (and professional teams especially) with the most solid foundation possible for full-stack apps, skipping all of the most common tedious core functionality. It was originally built for my own purposes, but I&#x27;ve decided to provide it as a sort of &quot;Foundation as a Service&quot;. Maybe there&#x27;s a better way to classify it, but it isn&#x27;t really a framework. It&#x27;s a highly specialized codebase designed for the task at hand, complete with thorough documentation, tests, and guides, something I wish I had readily available when building apps over the years, as it would have saved me thousands of hours and tens of thousands of dollars.<p>Sorry for the (not so) thinly veiled advertisement, but I absolutely need feedback to turn Molecule.dev into something people actually want, and HN is probably the best place to get it. I think there is a lot of potential here.

35 条评论

andrei_says_超过 3 年前
Ruby on Rails, Hotwire, StimulusJS, SCSS, slim, Postgres, Redis, on Heroku or Render.<p>Solid, mature, innovative, productive and pleasant to work with. 80% of SPA speed and reactivity with 5% of the effort.<p>If I need complicated interactivity in a specific area, I use vuejs.
评论 #29495407 未加载
评论 #29491132 未加载
aprdm超过 3 年前
Django &#x2F; Postgres<p>which might evolve to<p>React &#x2F; Django+DjangoREST &#x2F; Postgres &#x2F; Redis &#x2F; ES &#x2F; RabbitMQ
评论 #29491580 未加载
quickthrower2超过 3 年前
It depends on the problem but I stick with what I know.<p>Database: SQL Server at work, PostgreSQL at home (due to pricing but it&#x27;s also great!).<p>Backend: ASP.NET Core<p>Front End: As little as possible but it depends on requirements going from<p>1. None at all<p>2. Use JQuery in certain spots for UX<p>3. Use Typescript&#x2F;React (simple, no redux etc.) for a complex SPA-type app.<p>But 1 is the default because KISS.<p>No GraphQL or NoSQL DBs. Might use S3&#x2F;Azure blobs though for caching.<p>ASP.NET&#x2F;.NET&#x2F;C# is used because I&#x27;m used to it. However even with that bias, I argue it is a great sweet spot for back end languages. Good typing system but not too complex like Haskell. Garbage collection works has never been something I&#x27;ve had to worry about. Also performant and great tooling.
评论 #29493197 未加载
评论 #29492949 未加载
评论 #29493107 未加载
eyelidlessness超过 3 年前
I also primarily use TypeScript&#x2F;Postgres where I have the choice. For UI I do prefer JSX but not React, I prefer something lighter and ideally supporting or amenable to partial hydration. I’m eager to use Deno more, there’s a lot that appeals to me more than Node.<p>In the past I’ve worked extensively in Clojure&#x2F;ClojureScript. I really like the FP aspects and I came to really appreciate lisp generally, but I much prefer FP <i>style</i> in a statically typed language. I may look at Rust for some performance-sensitive stuff, and possibly Typed Racket for some DSL ideas I’ve been wanting to explore.
评论 #29489104 未加载
ozzythecat超过 3 年前
C++ for shared mobile libraries, though the more recent projects are going the way of Rust.<p>Objective C and Java on clients, some Kotlin.<p>JVM in other places with Java for services, and Scala for EMR&#x2F;Spark jobs.<p>Most of my back end runs through AWS though I moved some services on Azure now (mainly just to learn but it worked fine enough to move it for a couple production environments).<p>For storage I have my own Postgres instances. Way cheaper than any cloud. If I need regionalization and better redundancy, might move to AWS eventually.<p>Day to day tools involve Omnigraffle, Omnifocus, and iTerm2. Yes, everything on a MacBook Pro with a 1440p 120hz monitor.
评论 #29487592 未加载
flohofwoe超过 3 年前
The CPU stack, it&#x27;s much preferable over the heap for memory management and passing data around ;)
reaperducer超过 3 年前
Boring old LAMP stack here. Sure, it&#x27;s not fancy, but it gets the job done, and it&#x27;s fast to develop, deploy, and debug without all the fancy abstractions.<p>One of the reasons we&#x27;re vanilla is to make it much easier to find people to hire.<p>Instead of limiting the applicant pool to those who know a particular combination of the frameworks-of-the-day, we can hire from a much larger pool of candidates who are familiar with all of the basics.
评论 #29494441 未加载
apehx超过 3 年前
Backend: Spring boot with Kotlin, openapi-generator for server stubs, JOOQ for database interaction.<p>Frontend: React, antd as a component library, openapi-generator for api clients.<p>Database: PostgreSQL, flyway for migrations.<p>Out of all the stacks I&#x27;ve used over the years, this is the one I&#x27;m happiest with. It&#x27;s very stable, each tool has excellent documentation and active communities, and it&#x27;s just plain fun and productive to work with.
utf_8x超过 3 年前
Architecture - microservices mostly connected through GraphQL and gRPC (certificate based auth is the shit)<p>Languages - Java for backend, pure JS for frontend<p>Frameworks - Spring Boot on backend, pure React on frontend (I like to keep it simple)<p>Infrastructure - Mostly k8s (with helm to make life easier), Nix for more complex stuff<p>Databases - Postgres, Mongo, Redis, Elastic... Really depends on use-case...
jpgvm超过 3 年前
Linux&#x2F;JVM&#x2F;Postgres - the &quot;boring tech&quot; stack.
评论 #29492434 未加载
bhussai20超过 3 年前
I feel like this question is poorly formed in the age of resume-driven development. I prefer types of problems to tackle. But, I don&#x27;t have preferred stacks so much as stacks I dislike less that are prescribed for my consistent employment.<p>My least disliked stack is the one that doesn&#x27;t make me obscure, keeps my future career progression options sub-&#x2F;Pareto- optimally open, while still making my pay competitive. So in essence I align with whatever is the easiest to adopt and train others on with minimal supervision.<p>i.e. JS, React, Express, Docker, AWS
评论 #29487927 未加载
nomemory超过 3 年前
Kotlin with Vert.x or Spring Boot depending how complicated things are in the backend. Spring can boost your productivity if you really need it. Vert.x gives you more control, but you will have to write more code. Java is also an option, but Kotlin is simply nicer.<p>When it comes to FE, I don&#x27;t touch that anymore. I did some react and old angular in the past, but it was more like an obligation... I don&#x27;t &quot;feel&quot; the community, or how complicated things have become.<p>For programs that are closer to the hardware or operating system, I feel quite comfortable in C (not C++).<p>For scripting, data visualization, and anything math related I use python. I usually end up having one big script, terrible written that works.<p>When it comes to databases, I pick mariadb because I have the biggest experience with it and it didn&#x27;t disappoint me. From the NoSQL land I&#x27;ve tried the most popular ones, and I had good interreactions with redis, and the elk stack.<p>I&#x27;ve tried to love Go and Rust... I still try, because some companies I follow and have interesting projects are using them. But it&#x27;s more like a long term goal to learn rust.<p>I believe my stack is boring, if not boring conservatory.
turtlebits超过 3 年前
For web apps, Svelte + Hasura + Postgres.<p>I try for as as minimal as a backend as I can get away with. Sometimes none, or couple of serverless functions.
评论 #29490677 未加载
JaggerJo超过 3 年前
For web apps:<p>F# + .NET + ASP NET on the backend F# + Fable on the frontend<p>Otherwise just F# + .NET - basically runs everywhere and is good for anything.
Jugurtha超过 3 年前
<p><pre><code> Stack: - Application: - Flask - PostgreSQL - Nginx - Infra: - Google Cloud Platform - Monitoring: - Prometheus - Grafana - Sentry - Analytics: - PostHog - Containers: - Docker images on GitLab registry - Repository management: - GitLab: - Issue templates for: - Bugs - Features - Incidents - Communications: - Slack</code></pre>
boogywoogy超过 3 年前
Everyone goes through this phase of creating a “starter”.<p>Maybe they evolve it to a pluggable framework.<p>But nothing will last the test of time.<p>Things change too rapidly and developers usually need to understand everything themselves when they want to customize stuff.<p>The best is having small packages that do one thing well that do not involve buy-in to a particular framework.<p>It’s a really tough challenge. Making something flexible yet works out of the box.
评论 #29505366 未加载
ttfkam超过 3 年前
&quot;It depends&quot; is my preferred stack. First define the problem, then we can look at how to implement it. If you mean most websites with simple crud and maybe some user interaction?<p>Very simple model: DynamoDB, especially if it fits in the free tier to start. More complex model: PostgreSQL, especially for anything between a trivial model and 10 million users (which is most projects). Database migration with Sqitch.<p>Data access method (middleware): GraphQL, because it&#x27;s a spec rather than an implementation. My preference all things being equal is the database-driven solution Postgraphile, but I&#x27;ve had good experiences with other solutions like Hasura and Apollo Server depending on the problem. Hides complexity of DynamoDB access. Acts as an ORM layer for relational. The only GraphQL engine I avoid unless there is a good reason&#x2F;requirement is AWS AppSync; I don&#x27;t consider it fully baked yet as a general purpose data access solution from dev perspective.<p>Authorization: JWT, because I don&#x27;t have to do an extra lookup, especially in a serverless environment with an API Gateway in front. Row-level security if I&#x27;m using PostgreSQL.<p>Authentication: Typically AWS Cognito, because most of my dev work is on AWS, and after you&#x27;ve done it once, redoing is trivial. Google auth for general public access. Simple identity pool for cases with a finite set of users such as an internal tool. If Google Auth on Google Cloud is dead simple, so I give that an honorable mention.<p>Front end: Svelte, because I know HTML, CSS, and JS very well, and Svelte is little more than that while still allowing fast component-driven development, data binding, and other modern features. Svelte calls the GraphQL API. Once all queries are clarified, the GraphQL layer is given an allowlist of acceptable queries and authorized through the JWT.<p>I prefer PWAs to native mobile coding or frameworks like React Native. If a PWA is insufficient, my preference would be Ionic due to my stated earlier experience with HTML, CSS, and JS.<p>I prefer AWS to Azure or Google Cloud. I also prefer regions other than us-east-1. Between those big three, I find prices similar, but options on AWS to be more mature and cover a wider breadth. CDK, CDK Pipelines, and CDK Solutions Constructs is by far my preferred method of developing infrastructure as code. I prefer writing in TypeScript mostly because it allows homogeneous language development from UI on down.<p>If I ever run into a performance problem that is CPU bound (happens fairly rarely), optimizing the lambda or whatever in Rust would be enticing. Most of the time though, it&#x27;s just cheaper to scale up the instances&#x2F;provisioning and move on. Developer time is almost always more expensive.
hmmokidk超过 3 年前
Backend: Phoenix + Postgres<p>Frontend: Fairly variable, plain&#x2F;embedded HTML or React<p>Deployment: PAAS first then terraform if it ever needs to be fine tuned
moooo99超过 3 年前
Frontend: - NextJS - TailwindCSS + TailwindUI - react-query<p>Backend: - nestjs - PostgreSQL - docker on Hetzner or digital ocean for deployment<p>Im currently looking into Hasura&#x2F;PostGraphile as a possible substitute for large parts of my backend stuff. I mostly build fairly simple CRUD apps, so I’m confident I can reduce complexity by quite a bit
thiht超过 3 年前
Postgres, because it’s rock solid and usually a good choice.<p>Go for the backend because it’s really quick and painless to produce something robust and that will last.<p>React (with Typescript) for the frontend because I love it’s component model and am personally pretty productive with it. For styles I just use CSS modules.
notpachet超过 3 年前
It&#x27;s fine to ask for feedback on your prototype, but that&#x27;s probably better off as a standalone Show HN. Better for both sides -- you&#x27;re probably not going to get as much feedback on your project as you&#x27;d like since it isn&#x27;t the actual topic at hand.
评论 #29488108 未加载
nh2超过 3 年前
Backend: Haskell, Postgres, Ceph<p>Frontend: TypeScript, React<p>Scripting: Python with mypy (static type checking)<p>Deployment: nix, NixOS, nixops
m_ke超过 3 年前
Backend: Django, DRF, Postgres, Redis, Ray Serve<p>Frontend &#x2F; Mobile: React, React Native, MobX, TypeScript<p>ML: Pytorch<p>Ops: GCP, K8s
评论 #29489888 未加载
midrus超过 3 年前
Laravel, livewire, Unpoly and tailwind. Never been this productive in my life.
评论 #29493183 未加载
amanaplanablog超过 3 年前
Go &#x2F; HTML &#x2F; CSS &#x2F; Vanilla JS &#x2F; Postgres
austincheney超过 3 年前
Backend: TypeScript, Node<p>Frontend: TypeScript (no frameworks)<p>Lint: TypeScript-Lint<p>Linux: Bodhi Linux<p>Database: no preference<p>I tend to build most everything else myself, the cost of low abstraction high performance execution.
bjacobt超过 3 年前
Backend: FeathersJS (typescript) + postgresql + nginx<p>Frontend: Angular + Bootstrap + nginx<p>Landing Page: Bootstrap + JQuery + nginx<p>Automation: Ansible<p>Edit: formatting
rurban超过 3 年前
Bash, Emacs, C.<p>Deployment: GitHub Actions and Pages<p>No databases, hashtables are good enough and around 1000x easier and faster.
评论 #29492400 未加载
gompertz超过 3 年前
LAMP with Dart+Flutter. Less and less C&#x2F;C++ on backend these days.
评论 #29495284 未加载
atemerev超过 3 年前
Scala, Akka, Postgres (or sqlite for smaller projects).<p>Dash&#x2F;python for frontend.
bradwood超过 3 年前
React SPA<p>AWS API G&#x2F;W<p>AWS lambda running NestJS<p>AWS dynamodb<p>AWS SNS&#x2F;SQS<p>Managed with SLS and terraform via gitlab and gitlab-ci
egberts1超过 3 年前
My preferred stack is:<p>- Linux OS<p>- TCP Cubic<p>- nftables<p>- BPF<p>so i can host my Suricata, Zeek, and Snort.
winkv超过 3 年前
backend:golang, sqlite<p>frontend:html,bulma css, cash js<p>deployment:terraform
1cvmask超过 3 年前
If you want to sell on premise enterprise software then Java is a big plus.<p>Also if you plan on exiting the company to a strategic buyer then your stack will come up in the due diligence and if it is a stack they are not familiar with then they can call off the deal. That is another, minor, reason why enterprise software companies chose Java.<p>But stacks are always a moving target. Todays hipster stack might be tomorrows mainstream. Postgres was an obscurity compared to MYSQL in the early 2010s and it has picked up tremendous stream since then.<p>And getting product market fit is more important than choosing the right stack. You can always use duct tape if you get lucky enough to have problems with scaling.
vb6sp6超过 3 年前
The best choice is what you are already familiar with. And it you aren&#x27;t familiar with anything, any one of the popular frameworks will work.
评论 #29494353 未加载