[HN Gopher] Ask HN: Which stack for prototyping?
___________________________________________________________________
Ask HN: Which stack for prototyping?
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
Author : tbronchain
Score : 18 points
Date : 2021-04-18 11:19 UTC (11 hours ago)
| Zealotux wrote:
| 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.
| athenot wrote:
| 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.
| kvnhn wrote:
| 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.
| traverseda wrote:
| 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.
| ransom1538 wrote:
| 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
| juancn wrote:
| 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.
| madhadron wrote:
| 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.
| e67f70028a46fba wrote:
| 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.
| tbronchain wrote:
| Thanks! I need to look into that. Looks like a very hacker
| approach of prototyping, i like the concept.
| e67f70028a46fba wrote:
| The examples are pretty good:
|
| https://htmx.org/examples/
| PLenz wrote:
| The best tool is one you already know
| tbronchain wrote:
| 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.
| sto_hristo wrote:
| 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."
| Dowwie wrote:
| 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.
| rufius wrote:
| 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
| rchaves wrote:
| 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
| michael_vo wrote:
| 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.
| dkarras wrote:
| 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).
| karmakaze wrote:
| +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.
| jitl wrote:
| 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.
| rk06 wrote:
| 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
| tbronchain wrote:
| I have seen some very good real world/production projects
| working on this stack!
| bpicolo wrote:
| What's the base rate for a cheap web app + db on azure?
| bwh2 wrote:
| 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.
| tbronchain wrote:
| This is a very good advice.
|
| For this part I've been recommended "tailwind ui" and it looks
| very promising!
| angrais wrote:
| 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.
| angrais wrote:
| I should add that depending on the fidelity of the prototype
| that using mock data in JSON on the front-end is ideal.
| awb wrote:
| For the design I built MVP.css for "drop in" styling without
| having to learn a CSS framework:
|
| https://andybrewer.github.io/mvp/
| tpetry wrote:
| 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.
| stevekemp wrote:
| 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.
| bmn__ wrote:
| > the amazing CGI::Application framework
|
| Year 2000 called, it wants its webdev paradigm back.
| nicoburns wrote:
| 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.
| tbronchain wrote:
| 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).
| kryptk wrote:
| 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.
| azangru wrote:
| > 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? ;-)
| yoyonamite wrote:
| 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.
| Pandabob wrote:
| Out of curiosity, what do you think the node ecosystem is
| lacking in this regard?
| nicoburns wrote:
| 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.
| Pandabob wrote:
| 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.
| waspight wrote:
| Nest with next.js for sure. With apollo as communication layer
| the frontend storage is resolved as well.
| lostsoul8282 wrote:
| 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.
| morpheu5 wrote:
| 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.
| tbronchain wrote:
| 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!
| pupdogg wrote:
| - Backend
|
| -- Ruby: Roda + Sequel + SQLite (or any db)
|
| - Frontend
|
| -- Node: SvelteKit + ViteJS + TailwindCSS
|
| - FullStack (monolithic)
|
| -- Ruby: Roda + Sequel + ViteJS + TailwindCSS + SQLite (or any
| db)
___________________________________________________________________
(page generated 2021-04-18 23:02 UTC)