Ask HN: Which stack for prototyping? | Hacker News Reader

Ask HN: Which stack for prototyping?

57 pointstbronchain99 comments

As a Devops engineer, I have seen a multitude of stacks used in the projects I helped deploying.

As a former developer, I have had countless of project ideas and choosing the tech it's going to be written in has always been a [unnecessary?] long topic, often leading to procrastinating and giving up on the idea.

I often hear (and claim) the argument that "one should use the stack they [the team] are the most comfortable with". While I strongly agree, I find my personal [developer] stack to be slightly outdated (as a system engineer, lots of Python, some Node with Express, and some irrelevant languages - C, scripting, ...).

Focusing only on the development side, what would be YOUR goto stack for very quick prototyping/MVP, say for a webapp/saas service?

Long term code support doesn't matter much here, the goal being able to bring ideas to life very quickly. Let's say 10k users max (or much less).

Some recommendations I've had:

- Node: Nest + Next.js - modern and popular stack with quick prototyping possibilities

- Elixir/Phoenix - attractive ecosystem, developer oriented

- PHP: Laravel + Livewire/Blade - very quick prototyping and social features

- Python: Django - because I'm already very comfortable with Python

View on HN

> As a former developer, I have had countless project ideas and choosing the tech it's going to be written in has always been a [unnecessary?] long topic, often leading to procrastinating and giving up on the idea.

And here you are, posted the question on HN and doing it all over again :)

The answer is the tech stack doesn't matter all that much.

All you care about is bringing ideas to life and python is versatile enough to do anything, so pick that.

After reading all the answers here, you probably sum it up very well!

The best stack for YOU to prototype is not the best stack for ME to prototype.

It's whatever you are most comfortable in, and can move the quickest.

It's the stack where you don't have to re-learn how to do things you know are possible.

So with that in mind, it's probably not the latest and greatest technology (except if you happen to have been living and breathing it for the past few years). It's probably got some warts that you don't like but for which you are also very competent at overcoming.

If you are leading a team and need to decide that for them, try to find out which stack each member has gotten the most done in (in current or previous job), and average it across the team. It might be helpful to set expectation that this is not the most glorious technological project of their lives but that the goal is a rapid developement project with the goal to replace parts with something more robust once they get validated on the product/user side.

Absolutely this. Prototyping a project in a new (to you) language/stack only serves one real purpose: to get comfortable in said language/stack. If your goal is to get a working product quickly, with as few hiccups as possible, your comfort zone is your friend.

That depends a lot on both the size of the project and the domain.

The OP acknowledged this and said they specifically want to hear what others like to use anyway

My pet peeve: Go on Youtube to search for camera reviews. At the end of the review "The best camera is the one that you have". Well, no shit, I came here to get your opinion.

Your answer would make sense if the OP were asking what stack to use for project X, but they're asking what stack _to learn_ and familiarise themselves with in preparation for whichever project next comes up.

This is some of the worst development advice I've ever received. Ten years ago, I was most comfortable with Flash, C and Objective C.

Wow am I glad I learned JavaScript in 2012/2013.

A few years later, I was most comfortable building web servers with Node/Express.

Once again, wow am I glad I learned RoR and then Elixir/Phoenix instead of halting my education and sticking with what I was most comfortable with back then.

It's been a huge productivity boost in multiple domains.

Thanks, this is exactly the point of this post!

My personal developer stack is getting slightly dated as my main focus over the past few years has been onto dev/sysops, seeing tons of new exotic tech being used now and then.

I am really open on learning something new today if it can help me be more efficient in building my ideas in the future!

I didn’t take that comment as “don’t learn” but rather use what you know well for prototyping

To clarify, using what I already knew well was a mistake that greatly slowed down my prototyping on many occasions.

There is a local maxima around what you already know due to the cost of learning something else, but it's much shallower one than many, including my past self would have guessed.

Interesting take. I’ll think about this for my next project!

With web there are a lot of transferable skills: http, DOM, chrome debugging, general problem solving etc. so there is that too. If I try nextjs and it does something odd I can still debug it.

Well then since, you have probably already familiar with Rust + asnync ... I mean it's even out of nightly by now, I guess it's time to start cracking on nim, zig and crystal.

I mean JavaScript pff... that's so last decade.

OK Flash died but you could have easily made a nice career going deep on C. Us devs need to find the right balance between remaining relevant and going deep enough in the tech we choose.

Whatever backend tech you are most comfortable with and https://htmx.org, which is backend agnostic and has almost no learning curve and requires very little code.

Thanks! I need to look into that. Looks like a very hacker approach of prototyping, i like the concept.

The examples are pretty good:

https://htmx.org/examples/

Blitz - (https://blitzjs.com/)

Blitz is built on top of Next.js and gives you postgres for free, in addition to auto-generating CRUD routes on schema changes. It's trying to be like Rails.

I've used Next.js with firebase for multiple prototypes.

For me? Just Go.

Building a service? Go.

Need a light UI for the service? Go + Go html templates.

Need a command line tool? Go.

Building an interpreter or transpiler? Go.

That’s just me though. The reason that’s my answer is I’ve been writing a lot of Go lately.

Answers I might’ve given at another point in my career:

- Rust - I’d still reach for this but I find it a little slower to work in for prototyping.

- C#

- F#

- Ocaml

- D

- Pascal

Interesting. If your evolution is anything to go by, I might be at an earlier point. Earlier I might have said perl or C#, nowadays I'd probably say F# or C# depending on what I'm looking to prototype. I find F# stimulates me to think about the kind of data and operations I want to support more than C# does. I would assume OCaml does the same.

I know JS/TS, I find they're generally counterproductive in dissecting the problem I'm trying to solve. I might use them for rapid UI prototyping, if it's a very simple app.

What made you pivot from .NET and Rust to Go? Is this a question of creature comfort, where you're just more accustomed to it nowadays and/or prefer the ecosystem? Does Go stimulate/force you to think about the problem differently and if so, how?

Well this is cheating, but I stopped working for Microsoft :).

I actually still quite like .NET on the whole. But the job I took after Microsoft had me writing Rust and Go.

I should note the list is in no particular order. If it were ordered newest to oldest, it’d be:

- Go

- Rust

- F#

- C#

- Ocaml

- D

- Pascal

Languages I’ve used heavily but wouldn’t for prototyping are C and C++. Most of my time at Microsoft was 67-75% C/C++ and the rest some form of .NET.

What web frameworks are there in Goland? Is there anything trying to be Rails or is Go meant for small services?

AFAIK laravel 8 -- the latest -- is the only stack to provide auth out of the box

As in

They give you a login screen

When you install an app 'starter kit'

Breeze -- the simplest -- in this example

Downside is you get stuck w vue and tailwindcss as defaults

  curl -s https://laravel.build/example-app | bash

  cd example-app

  php artisan migrate

  composer require laravel/breeze --dev

  php artisan breeze:install

  npm install

  npm run dev

  php artisan migrate

This really fits into the "getting something up and running quick" category. Thank you!

Django also provides auth out of the box. Granted the existing login page is for the admin, but that brings up another point.. it has a built-in admin portal which is super helpful!

If you want a user facing login page there are default login views, all you really need to do is make the template for the page.

Love using Django

I will second Laravel. Also PHP developers are cheaper, if one day your project turns into a business, you can hire for a lot less money.

Django (Python) also includes auth if I’m not mistaken. A good approach I’ve seen is using Django to create REST API’s while using the admin interface and ORM support as free bonuses.

Ah Laravel depends on Vue by default? I didn't know that.

but the default 'starter kits' do -- at least in the latest version (8.x).

if you're an expert in laravel/vue/mix/css/js/webpack/etc., it's prob 30 seconds to a few minutes to swap it out for...nothing, or something different (e.g. React).

also, there are now a paid boilerplate saas products that give you a login screen 'out of the box' -- and some other things.

e.g. https://www.saaspegasus.com/ for python/django

Be careful, prototypes sometimes become products. So, pick something comfortable for you, but that you could grow into a product with a good enough scale.

Yeah, I have never seen the prototype not get ported over somehow.

You need a lot discipline to throw away everything even if you knew going in that it was crap.

I like Rails on the back-end (or simpler Ruby-based frameworks like Sinatra) and Vue or Nuxt on the front-end. I have stuff in production with these and they progressed very well from prototype to production.

Right, I forgot to mention Rails. I've always been a bit turned off by Ruby's syntax, but always heard it's awesome in many ways. Thanks!

I love Rails, but if you like and already know Python, then Django is a better choice for you :)

On the frontend, buy a HTML theme on ThemeForest or similar. Your goal is very quick prototyping and visual design decisions will slow you down. These themes aren't the best code, but they look good and come with tons of layouts and components you can mix and match.

This is a very good advice.

For this part I've been recommended "tailwind ui" and it looks very promising!

Agree... also take a look at https://themes.getbootstrap.com/

They tend to be higher quality and less packed with loads of random JS libraries than the ones on the big theme marketplaces.

If you're already very comfortable with Python then that should be your first choice for the backend. You can be flexible with the framework though - Flask[0] is also popular, or you can try one of the new async ones like FastAPI[1].

For the frontend I would suggest htmx[2]. You will anyway need to do some html, and htmx will save you the trouble of learning a JS framework.

0. https://flask.palletsprojects.com/en/1.1.x/

1. https://fastapi.tiangolo.com/

2. https://htmx.org/

I put together a one-day hackathon project with Next.js on Vercel and Supabase. Supabase is a “firebase alternative” that gives you auth and a Postgres database in a single package in like two clicks. You use row-level security to define what permissions a user ID has using Postgres policies. If you’re a front end weighted developer this is great because you can pretend “there is no backend”, although with Next you can still write server side code that bypasses the row level security. Now, there’s issues with Nextjs/Vercel like “how do I run a job queue?” (Seems like you need an EC2 box somewhere else) that are unsatisfying, but for 1-hour productivity I don’t think you can do better.

Different stacks for different people.

I prototyped an app with a MERN stack. Mongo, Express, React (CRA) and Node. By no means was the backend performant, and for this app, I had no reason to use document database instead of relational, but because I know how to write with mongoose, I chose mongodb.

Now that the prototype is done, I'm looking at other languages and frameworks for the backend such as Phoenix, Hyper.rs or asp.net core. If I want to be lazy, I'll just convert the mongo queries to Postgres and be done with it, and then move my CRA React App to Next.JS.

If you are already comfortable with python then choose django. Learning a new framework will take time, which will be your case with django. You don‘t want to learn a new language too.

Personally I stick with Node (Express if it's a web server). Next.JS is cool but it's a bit too magical for my tastes, at least when hackability is the key priority.

Usually I end up adding TypeScript into the mix, even for prototypes. However, I'm pretty comfy with the configuration side of that (webpack, etc) so it isn't a huge time sink. If it is going to be a huge time sink, you might try Deno instead. It has Express-like libraries of its own.

The choices really do depend on exactly what it is you're making. I normally use some combination of python and htmx. I'd be using very different backends if I was building a distributed storage server, a chat server, a blog, or all kinds of other stuff. Mostly I'd be using htmx on the frontend though.

Is your project mostly database admin? The django admin can probably get you something useful fast. Is your app less database driven, or you need more flexibility? Flask is a good bet. Dealing with "live" data (chat apps, etc)? An asyncio project like quart or aiohttp might be best, coupled with a database that supports subscriptions/changefeeds. Alternatively flask with server-sent-events and redis might work better. If the project was mostly an API I'd likely use fastapi.

You can combine a lot of these servers in the same app with wsgi "application dispatching", although generally support for mixing asyncio frameworks and traditional frameworks isn't great.

Unfortunately there isn't a one size fits all solution right now, some frameworks will do some stuff better then others.

For web stuff, my personal go to choice is Node.js and some templating engine, like Handlebars. I used that on several occasions to quickly hack together stuff and see what an actual integration with some service looks like. Then i move straight to Java. How does that defines as prototyping, i'd leave for the semantics patrol.

Reiterating "personal choice."

I like to keep things simple so over time I removed stuff from the things I use and kept the things that has the largest reach. So what I use to prototype is very similar to what I use to deploy:

* Typescript + Vue on the front end (with nuxt) - NO SSR but nuxt precompiles the pages for me so I don't get the SEO hit. Front end can be served from any CDN basically for free.

* Node for the rest API with a custom, very simple and declarative framework that wraps HTTP, this only replies in JSON (also typescript)

* ArangoDB for all database needs. Has key value store, document store, graph store, so best of all worlds. I can use it like a RDBMS where it matters because graphs support relationships so no data duplication AND no need to normalize.

I can basically do anything with those, from quick prototypes, to a very low traffic website to serving millions (managed k8s, horizontal scaling comes into play then).

+1 the choice of Vue for the front-end.

I would choose a different backend (Go, Kotlin, F# but that's just me) and PostgreSQL or MySQL.

As mentioned: for you probably Python+Django (rendering pages, not an API), if you want/need a dynamic front-end maybe Vue+Firestore (or the like), 3rd choice Vue+Django.

From personal experience I can say it's very easy to get 'caught up' in the back-end tech and lose focusing on the front-end/product/customer.

The entire backend in Rust, using actix-web framework and async libraries for postgres and redis.

You're not going to rapidly prototype anything with Rust for your first 12 months working with the language, depending on your motivation and your ability to write missing parts for security middleware. However, once you've gone through that, you can be just as productive with an async Rust stack as you can with a Python one. Your prototype will also be ready for the "no time to refactor" mandate that makes it your production system. Actix-web framework and async libraries for postgres, redis, and rabbitmq are all mature and well-documented. I realize you said quick prototype/MVP, but all of this comes at little additional cost once you know how to adopt and integrate quickly.

If I were writing a big web-app I'd probably use either golang, or Perl.

I'm not a fan of PHP, I've never used any of the python frameworks, and while I can use Ruby on Rails it would usually not be my first choice - not unless I was building a simple CRUD application.

Perl gives me the amazing CGI::Application framework, a lot of libraries for integrations, and a standard approach to writing tests.

Golang is the new-hot, it's good for writing servers and services, also has a testing-centric development approach, good support for templates and a simpler deployment approach than most dynamic languages.

Still, my preferences tell you little except what I can/will use. The answer is usually to always pick the framework/think you're most familiar with OR the thing that you want to learn next.

> the amazing CGI::Application framework

Year 2000 called, it wants its webdev paradigm back.

> Year 2000 called, it wants its webdev paradigm back.

"Come and take it!" ~ Serverless frameworks, Lambda, etc.

I think you've already mentioned all the obvious choices. Out of those I would probably discount Node if you want a really quick prototyping experience. Nest/Next just aren't on the same level as the others.

One of the best things you can do is use Postgres as the backend.

Seems to read different opinions on the node stack here.

I am getting to a similar conclusion to you though, where other tools were good for prototyping and the node stack really better for the real projects (post-prototyping).

We just finished rewriting a 3 year old Rails app in Node+Knex, performance with 10k concurrent sessions is roughly 4x and p95 is 10x better.

Keep this in mind whenever someone decides Rails is fine for a quick prototype and then leaves you to deal with production.

I am of the unpopular opinion that Rails "many opinions" are confusing as hell to someone who doesnt breathe Rails due to the sea of implicitness: Symbols just appear you are supposed to know where from, debug requires context dumps, gems are an unholy mess of registering hooks and overloading core apis. Combined with "slow as a dog", I really dont see what there is to love here.

> We just finished rewriting a 3 year old Rails app in Node+Knex, performance ... is ... better.

I suppose the next step would be to rewrite this app in Go or in Elixir? ;-)

Not sure you’d see much improvement. Node is pretty fast

I still reach for Rails a lot for prototyping. If the application can leverage Rails core functionality and the bigger gems in the ecosystem, I find it the quickest to prototype in, and the point of a prototype to me is to optimize for speed and customer feedback, often as the only developer. In many cases, the prototype needs to be re-written anyways when core assumptions don't survive encounters with the customer.

I think the reason this productivity exists is the all batteries included approach. For example, if I build a Rails gem, I can include data persistence through ActiveRecord and that code becomes less code that the developer using my library would have to write. Multiply that out by the various core libraries and the time savings can become significant.

I would also point out that for very early stage startups, the biggest problem is speed of development with only one to two devs. If they can't get the features out to reach product-market fit, it doesn't matter how good the performance of their application is.

> Symbols just appear you are supposed to know where from

While I don't like Symbols yes you are expected to know Ruby to at least a basic level if you wanna write Rails. It's like me saying in Node you are supposed to know Promises/async. Of course you are.

Also what were you using to support the concurrency before the switch? There are quite a few solutions out there you could have tried before doing a rewrite. Seems to me like you guys just wanted to write Node, which is fine, but it probably cost you quite some time.

Out of curiosity, what do you think the node ecosystem is lacking in this regard?

The Node ecosystem is fine. In fact it's arguably th strongest of the lot. But I have yet to see a Node framework that is as complete as Rails, Django or Laravel. And that makes a huge difference to prototype productivity.

Yea I agree with you. There are a couple of full-stack react projects being built now, with Redwood.js being maybe the biggest one and Blitz.js being built on top of Next.

Personally, I've been thinking of a project to create Next API routes directly from Prisma models, so effectively something similar to Django Rest Framework to connect Next and Prisma.

Recently I really enjoyed using Elixir with Phoenix for this, it replaces what Rails use to do quite nicely.

For frontend I try to stick again to just HTML and Vanilla JS, if I know the frontend will be more complex then I go straight to Elm

For the design I built MVP.css for “drop in” styling without having to learn a CSS framework:

https://andybrewer.github.io/mvp/

I'm surprised no one has mentioned Pharo with Seaside. I'm not sure how you would make the iteration cycle shorter than editing code in a live Pharo image and using the image itself as the data store.

My main language is Python. But I took the Pharo MOOC just out of curiosity. When I switched back to Python, I instantly missed all the support the Pharo environment provides me. It's impressive.

Depends on the type of proof-of-concept you're building, e.g., website with lots of user interactions or a data pipeline?

Either way, I use python (FastAPI) and vue.js to keep the front-end and backend separate. That way, if you're working in a small team then responsibilities are easily separated and helps with scaling too, e.g. when you reach 10k users. There's also a great range of libraries available so prototyping is quick on both ends.

As for deployment, I use docker and a digital ocean droplet. That way, you can deploy easily as and when needed.

I should add that depending on the fidelity of the prototype that using mock data in JSON on the front-end is ideal.

Backend: I would stick with Python, but modernized with some bit of dataclass and typings.

A very tempting alternative is Golang, where it's fast build time and light syntax makes it a good candidate for prototyping.

Also, I know many do not like it in this forum, but a document-oriented database such as MongoDb will save you a lot of time when dealing with json style documents.

Frontend: Here, I feel Angular can still deliver, once you have climbed the steep learning curve, the most important being to use a toolkit such as Bootstrap, which is a huge time-saver.

The best tool is one you already know

To be honest the point of this post was to see what people are using and if one was standing among others.

I would be willing spending a bit of time learning a tool today if it can save me tons of time in future project ideas - read: would allow me to actually DO work on these ideas.

I would start with separating the frontend and backend, as some others have suggested. I would probably use react but could try svelte or vue also. In the start you can mock the backend or have a memory-kept version of it.

For backend (the api) I would go for c# or nodejs (maybe with nextjs). I might combine this with a serverless solution like Architect.

https://github.com/architect/architect

I won't be the most popular person on hacker news for this but check out bubble.io for the front end and then use heruku(free tier) + python(flask + fastapi, etc) for the API.

With this stack you can quickly build a API, connect it to bubble and show people your idea in a way that's actually working. Later on you can move all your API data off bubble and replace the front end with whatever you want.

I found it the cheapest and easiest way to build something very quickly.

For me it's Ruby for shell scripting, Elixir+Phoenix for web apps VIM mode (of whatever IDE or editor) for editing.

For a fast prototype, picking a language that has ready to go api examples in your space is the best bet:

Twilios: https://imgur.com/a/iACVPvU

Stripe: https://i.imgur.com/esOq0dB.png

ETC

Ruby on Rails, people!

Svelte + Hasura (+ Keycloak for auth)

Skip the backend unless you absolutely need it. Saves so much complexity, time and money.

I agree with the many who recommend not building a backend. I'm loving Supabase at the moment. In the past I have built things very quickly with Firebase.

For the front end, skip CSS too. It's such a time sink. Use Material UI or Ant Design.

Just be aware that both of those UI libraries only save time if you go with the out of the box experience. If you need to theme them there will be a bit of a learning curve and if you really need to customize then that learning curve goes up dramatically.

- Backend

-- Ruby: Roda + Sequel + SQLite (or any db)

- Frontend

-- Node: SvelteKit + ViteJS + TailwindCSS

- FullStack (monolithic)

-- Ruby: Roda + Sequel + ViteJS + TailwindCSS + SQLite (or any db)

Just wondering isn't it frustrating being a Rubyist not on Rails? was just wondering what's life like on the other side of Rails. I have deep respect to what you're doing don't get me wrong, it just seems hard.

Find a bootstrap visual editor and use that to mock up a Web site. Make sure to use one with lots of blocks you can just drop in the page.

Use framework7 with Vue for a mobile/webapp. For a more complicated site build it with django or php if you might want to hire cheaper devs in future.

Frontend: NextJS DB: GoogleSheets

Google Sheets allows you to see all your data immediately and setup takes 5 mins. Does it scale? No. This will ensure that you throw away your prototype and use your learnings during a rewrite in case the project becomes more successful.

I like feathersjs for the server/api since I find service-oriented thinking to mold well to most projects and it scales well, plus easy integration with almost any database.

Re: frontend, I like vue/nuxt plus Vuetify as a component framework

Vue: because it is easiest to pick up and has great dev tools.

C# with ASP .NET Core (because i am most comfortable in .NET)

cloud: Azure (easy to use, has in built auth), and you can limit your credits, so you won't end up with crazy monthly bill like AWS

I have seen some very good real world/production projects working on this stack!

What’s the base rate for a cheap web app + db on azure?

Safe stack iff I don't ever want to put it into a production environment for work. If it's my side project then I would still use it.

Why because at the moment I like F#.

For web: Next.js + React.js + Tailwind CSS + MongoDB!

I'm using Nest for mine which allows me to stay in the JS ecosystem, so far I love it, it supports pretty much all I need out of the box.

Python (Flask) and AngularJS/Material 1.8

I use python/flask on GAE or express js on firebase functions. React for fe. (In all cases, no managed instances.)

Clojure/Ring + Datomic + React

I've come to find Datomic less than great for prototyping in situations where my data model is evolving. Since your history of data is immutable you get to live with all of your mistakes forever, you can't really just write a migration that shifts from one data model to the next.

You can always ETL the latest value of the DB to a new DB/Schema

Do you have a specific example? Datomic is great for evolving in prod (https://blog.datomic.com/2017/01/the-ten-rules-of-schema-gro...), and Clojure is a great language for generating data (or ETL) when you want to make radical changes in dev.

It was a service ticket system where we moved from a boolean status to a string for more states (noob modeling mistake I know). The problem came up a few months later when a dev pulled every attribute, saw the old field, and wrote new code against the old field, leading to some really confused tickets.

Looking at that blog post though, it seems that using #9: Annotate your Schema could have helped us avoid this situation. Thats an interesting feature of Datomic I was unaware of.

Extreme minority opinion: Lazarus/Free Pascal

Nest with next.js for sure. With apollo as communication layer the frontend storage is resolved as well.

Reply on news.ycombinator.com