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

58 points by loh ↗ HN
I'm curious about what most professional developers are using these days, from languages to deployment, and what they're building with it.

There's a lot to choose from and it seems like a few are really taking the lead. Maybe I'm biased but I prefer TypeScript, React w/ 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'll probably try Render next.

If you'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'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'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.

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've decided to provide it as a sort of "Foundation as a Service". Maybe there's a better way to classify it, but it isn't really a framework. It'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.

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.

70 comments

[ 5.6 ms ] story [ 96.3 ms ] thread
My preferred stack is:

- Linux OS

- TCP Cubic

- nftables

- BPF

so i can host my Suricata, Zeek, and Snort.

C++ for shared mobile libraries, though the more recent projects are going the way of Rust.

Objective C and Java on clients, some Kotlin.

JVM in other places with Java for services, and Scala for EMR/Spark jobs.

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).

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.

Day to day tools involve Omnigraffle, Omnifocus, and iTerm2. Yes, everything on a MacBook Pro with a 1440p 120hz monitor.

What, no Alfred?
Checkout Raycast, it's the new Alfred yo!
Looks interesting...but I think I'll hold off for now. Too used to Alfred 3 to even upgrade to Alfred 4.

Interesting pricing model, though. I wonder whether they'll succeed with it. In my experience, people love the idea of Alfred, but I've never had success getting anyone on my team to adopt it. (Maybe because of the "pay individually" nature of the good stuff (powerpack)? I'm not sure.)

They seem like a very bright team capable of tackling it to me. Alfred was cool 10, or like 5y ago, but like last time I got into packal (alfred community marketplace) it was all errors over the place, which didn't inspire much confidence to a casual user...

I don't know, I just like what they're doing, The new Extensions api looks really powerful. I ported an alfred script to raycast in like 2min...

YMMV

I don't care about the paid/team offerings honestly, I use it myself, my teammates can use whatever they want. But hopefully they will have enough enterprise customers to make the company thrive

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't have preferred stacks so much as stacks I dislike less that are prescribed for my consistent employment.

My least disliked stack is the one that doesn't make me obscure, keeps my future career progression options sub-/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.

i.e. JS, React, Express, Docker, AWS

Sounds like we're on the same page.

I think TypeScript will actually overtake JavaScript eventually. It's just so nice to work with. JavaScript will of course always be supported and a prerequisite, but in terms of professional web and Node.js development on a broader scale, it's hard to imagine going back to writing plain JavaScript when TypeScript provides so much value for relatively little effort.

Also, I've updated the original title in light of your comment.

I don't know why this was downvoted, but I agree fully regarding Typescript, and was going to post the same thing. I've read good arguments against it by some people, and I agree, it does slow things down a lot.

But if you're not able to write things bug-free on the first try already, Typescript can bring a lot of value as well.

"It depends" 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?

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.

Data access method (middleware): GraphQL, because it's a spec rather than an implementation. My preference all things being equal is the database-driven solution Postgraphile, but I'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/requirement is AWS AppSync; I don't consider it fully baked yet as a general purpose data access solution from dev perspective.

Authorization: JWT, because I don't have to do an extra lookup, especially in a serverless environment with an API Gateway in front. Row-level security if I'm using PostgreSQL.

Authentication: Typically AWS Cognito, because most of my dev work is on AWS, and after you'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.

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.

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.

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.

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's just cheaper to scale up the instances/provisioning and move on. Developer time is almost always more expensive.

If you want to sell on premise enterprise software then Java is a big plus.

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.

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.

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.

Ruby on Rails, Hotwire, StimulusJS, SCSS, slim, Postgres, Redis, on Heroku or Render.

Solid, mature, innovative, productive and pleasant to work with. 80% of SPA speed and reactivity with 5% of the effort.

If I need complicated interactivity in a specific area, I use vuejs.

i thought Hotwire was supposed to give us js without the js, but it seems like it needs stimulusjs and/or a mix of at least three other libraries and html-polluting attributes and code snippets.

i def don't understand that world yet, but i'm thinking...is there even enough of a payoff to step down from Vue?

slim looks cool. guess i have to check out laravel lumen, too. i thought lumen was just api support, so maybe slim is the same? i have to watch a youtube.

https://www.slimframework.com/

I meant http://slim-lang.com/

Never close another HTML tag again, never type or read a single character while writing clean compliant solid html.

so, slim is, in this case, a templating language/tech similar to blade, jinja, etc.
It's fine to ask for feedback on your prototype, but that's probably better off as a standalone Show HN. Better for both sides -- you're probably not going to get as much feedback on your project as you'd like since it isn't the actual topic at hand.
Yeah. I submitted it as a "Show HN" last Friday and received feedback from one person.
I also primarily use TypeScript/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.

In the past I’ve worked extensively in Clojure/ClojureScript. I really like the FP aspects and I came to really appreciate lisp generally, but I much prefer FP style 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.

> I’m eager to use Deno more, there’s a lot that appeals to me more than Node.

Like what? I’m genuinely curious.

1. Its API tends to be much closer to browser/web standards. This appeals to me because it’s easier/more productive to learn and reference one thing than multiple, similar things. It also appeals to me for portability, and potentially large improvements for “isomorphic” UI.

2. TypeScript in ESM is supported out of the box without a build step. There are solutions to this in Node, but they all have trade offs: ts-node is correct, but slow; ESBuild solutions are incorrect/incomplete (both because ESBuild itself lacks some TypeScript features and because the ESM loaders miss a variety of edge cases; ESM loaders are still experimental and there are large API changes coming in Node 17 (and presumably Node 18 which will be in LTS alongside the older APIs).

3. Performance: in terms of TypeScript (Deno uses SWC, which is nearly as fast as ESBuild and IIRC more correct), as well as heavy investment in Rust internals and third party extensibility.

4. Package management is both more standard (just import URLs) and more flexible (built in support for import maps, etc).

5. Related to #1 and #2, but a separate point: Deno can be expected to evolve faster while remaining relatively stable. Node has many legacy APIs that will likely never be deprecated in favor of even the standards it does adopt, and supporting those APIs already makes adopting newer standards more challenging.

6. There’s something refreshing to me about the fact that Deno’s creator was also Node’s, and that Deno is explicitly an admission of mistakes/warts in Node’s original design.

That's a great overview, thanks!

The only thing missing for me here is having a permission model similar to WASI, where we could potentially have sandboxing per module/dependency. IIRC in Deno this is done on the application level. I wish it was a bit more granular.

I'm not too fussed about esbuild not supporting TS as well as SWC does, e.g. I don't care about enums. But your comment made me realise that I should probably give it another shot. Cheers

Django / Postgres

which might evolve to

React / Django+DjangoREST / Postgres / Redis / ES / RabbitMQ

I agree, although I would swap out React for Vue.js V3.

Also, from experience RabbitMQ (with I assume Celery) is probably overkill for most projects and introduces more moving parts especially if you already have Redis. So I would go for Python RQ with Redis as the broker. (You can use Celery with a Redis broker but it has strange bugs and again probably overkill)

Finally, Ionic framework and Capacitor for mobile apps.

Oh, and increasing falling for TypeScript.

Supper quick stack to build anything.

Why Vue over React?
It’s as simple as I have more experience with it.
Backend: Django, DRF, Postgres, Redis, Ray Serve

Frontend / Mobile: React, React Native, MobX, TypeScript

ML: Pytorch

Ops: GCP, K8s

what do you think about react native? i hear a lot of bad things
backend:golang, sqlite

frontend:html,bulma css, cash js

deployment:terraform

Boring old LAMP stack here. Sure, it's not fancy, but it gets the job done, and it's fast to develop, deploy, and debug without all the fancy abstractions.

One of the reasons we're vanilla is to make it much easier to find people to hire.

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.

Nothing wrong with good old LAMP. Best kept secret is how good PHP has become over the years
Linux/JVM/Postgres - the "boring tech" stack.
Yet solves probably 99% of use cases!
The CPU stack, it's much preferable over the heap for memory management and passing data around ;)
Backend: Phoenix + Postgres

Frontend: Fairly variable, plain/embedded HTML or React

Deployment: PAAS first then terraform if it ever needs to be fine tuned

Laravel, livewire, Unpoly and tailwind. Never been this productive in my life.
I also find Laravel very productive for side projects. Unpoly looks interesting!
For web apps, Svelte + Hasura + Postgres.

I try for as as minimal as a backend as I can get away with. Sometimes none, or couple of serverless functions.

No backend is entirely possible. The less tools you need, the less room for complexity, bugs, and slowness.

I've recently started an app with Vite+TypeScript and Supabase and it's exactly what I've been looking for:

- Fast development: I make a change to the webpage and it automatically reloads instantly (like 0.02sec). Starting the dev server or installing deps takes 1sec. The site itself is fast. IntelliJ inspection is fast. This might just because my site is still small, but given the insane speed I'm hoping it will hold up when I add more code

- Good integration with tools and linking: If the code is wrong the browser / console instantly shows a detailed stacktrace that actually makes sense. The Firefox dev server doesn't de-sync. So far I haven't had any issues looking into obfuscated JavaScript. Only issue is I haven't gotten IntelliJ debugging (in-browser debugging works fine though)

- Low boilerplate: I create a new table on the database, add a 4-line GET function on the frontend, add a 10-line view, and now I've added blog posts to my application. Authentication is absurdly easy, I can authenticate with Google/Facebook/Github in a single call. I don't have to write useless boilerplate. Supabase can even generate TypeScript types for database objects

I've worked on sites where reloading took a full minute (meteor); there were bugs in babel-js, bugs in the npm libraries we used, and every bug involved looking through obfuscated JS to find what code "actually" triggered an error; and every small schema change took so long as I literally had to code the database schema / ORM schema / migration / REST endpoint / fetching from the endpoint / updating from the client etc.

Those were all worst cases, but they basically made me flat-out give up and accomplish barely anything. They're what make me skeptical of 1000+libs and complex build systems in the first place. Sometimes all you need is a 100% static site and a few static ES-module dependencies, and that will take 0 seconds to compile and (provided you can actually find un-minified ES-module deps) you'll never get obfuscated JavaScript or linking errors.

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.

When it comes to FE, I don't touch that anymore. I did some react and old angular in the past, but it was more like an obligation... I don't "feel" the community, or how complicated things have become.

For programs that are closer to the hardware or operating system, I feel quite comfortable in C (not C++).

For scripting, data visualization, and anything math related I use python. I usually end up having one big script, terrible written that works.

When it comes to databases, I pick mariadb because I have the biggest experience with it and it didn't disappoint me. From the NoSQL land I've tried the most popular ones, and I had good interreactions with redis, and the elk stack.

I've tried to love Go and Rust... I still try, because some companies I follow and have interesting projects are using them. But it's more like a long term goal to learn rust.

I believe my stack is boring, if not boring conservatory.

The best choice is what you are already familiar with. And it you aren't familiar with anything, any one of the popular frameworks will work.
Scala, Akka, Postgres (or sqlite for smaller projects).

Dash/python for frontend.

Backend: FeathersJS (typescript) + postgresql + nginx

Frontend: Angular + Bootstrap + nginx

Landing Page: Bootstrap + JQuery + nginx

Automation: Ansible

Edit: formatting

Bash, Emacs, C.

Deployment: GitHub Actions and Pages

No databases, hashtables are good enough and around 1000x easier and faster.

What type of systems are you building where hashtables are good enough?

Can you provide examples of a range of apps you've worked on with this stack?

See my github. Mostly system stuff: languages, libraries.

https://github.com/rurban/

E.g. I preferred hashtables as database in phpwiki. There I needed sorted pagination, but even without btree's the simple server-less hashtable architecture was 20x faster than mysql/sqlite with its overhead. Also, why logarithmic btree's when you can have constant lookup. Not everything needs to be sorted.

For web apps:

F# + .NET + ASP NET on the backend F# + Fable on the frontend

Otherwise just F# + .NET - basically runs everywhere and is good for anything.

Backend: TypeScript, Node

Frontend: TypeScript (no frameworks)

Lint: TypeScript-Lint

Linux: Bodhi Linux

Database: no preference

I tend to build most everything else myself, the cost of low abstraction high performance execution.

LAMP with Dart+Flutter. Less and less C/C++ on backend these days.
Are you using D+F for the web or mobile?

If web, how would you say its production ready?