hckrnws

After working with the PETAL (Phoenix, Elixir, TailwindCSS, Alpine.Js, Liveview) stack at $JOB for a while now, I have to say I've never been more productive.

Early on I would still have to lean on Alpine heavily for various JS interactions but with all the features Liveview has been adding and improving on (Hello JS module!) I find myself needing it less and less. Liveview really has been a game changer for me. Tailwind has more or less fixed most of my frustrations with CSS and has worked itself nicely into the company design system resulting in nice re-usable components that can be easily customized for those one-offs. Elixir is a nice language to use and I find myself missing features of it when working with other languages. Phoenix is well structured for projects and the newer generators solve a lot of common issues/features in projects like user auth in a reasonable way.

Depending on the needs of the app I'd look into deploying to Fly.io otherwise I've been using Kubernetes with little issue. I've toyed with Nomad for orchestration but haven't used it enough to give an opinion. I do wander if it's a nice middle ground for those who don't need the full suite of what K8s offers.

I second this. I would say that I am pretty advanced with Python (and Django) and same with JavaScript (Vue and Nuxt) and have written applications that got used by multiple users. I saw a sharp rise in my productivity when I knew enough about the frameworks. But Elixir + PhoenixLiveView + Tailwind has been life changing.

I learned Elixir for the sake of the joy of learning a new programming language and I kept playing with it for few random days over 5-6 months. Finally, I took the leap of faith and for our startup I started the switch to Elixir + LiveView with minimal JavaScript hooks and I feel a weird bliss that we are two engineer FTEs and I can add features on a daily basis. Why that's the case, I still haven't ruminated myself, but my guess is 1. I have gotten older, 2. Elixir is beautiful and productive by design-- pattern matching, everything is a process (so the dimensionality of time is not an issue at all) and the code is kind of a right balance of simplicity and complexity, and in my opinionated view, there is "one" right way of doing things. 3. Standard tooling (mix, ExUnit). They have enabled us to write really maintainable code and for our next hires, we are willing to pay for them to learn Elixir than switching to other languages. Of course this is only for true for our web app which is actually a weird beast that interfaces farms, sensors, algorithms, and humans.

Awesome experience write up.

Question for you and OP, do you find that using languages like Elixir makes it so you have to look for a certain kind of dev given that Elixir is a pretty niche community or are folks with no experience able to adapt with relative ease?

Not one of the OPs but can happily echo their experience/praise for PETAL and think I can answer your dev search question:

Anyone with a can-do attitude can learn Elixir. People with a “no thank you, I already know XYZ” mindset you really don’t want on your team.

Almost 20 years ago @pg wrote the “Python Paradox” post: www.paulgraham.com/pypar.html

The same holds true for Elixir (and Rust) these days. The people you want to hire are those who learn new skills/languages proactively.

However I can confidently say, from experience of having hired several Python devs/data scientists with zero Elixir experience, that smart+motivated people can learn Elixir in a couple of days and be productive within a week. See: https://www.verytechnology.com/iot-insights/elixir-for-pytho...

I'd argue the other way. Yes anyone with a can-do can learn Elixir. But there's a difference between learn and LEARN..

I work with a pile of rails devs writing code in elixir. In that I mean you can feel the rails in their code. It "tastes" like rails. A few python devs also write python with elixir syntax.

Finding people who know the language is hard. Finding people who are willing to risk their time on the language is also hard.

By risk. If I spend 2 years writing Elixir and then go looking for a job I'm looking at getting a job with a language that's not popular. So my pool of place that will even look at me is smaller. Hiring managers/gate keepers might not see..

After 12 years of c++ I got a job where I needed to code in Delphi-Script for a year. When I told recruiters what I'd been doing I got "Oh.... Okay um... We'll call you."

I switched to rails for 6 months (same job) and recruiters were calling me non-stop. Working in low popularity langs limits my options. (even if they are great langs)

I'd say picking a language that's not yet popular limits your pool not just to the can-do's, but also to the can get my next job with this on my CV.

Isn't Elixir a little bit like Ruby though? At least superficially. And it supports metaprogramming like Ruby.

So I'd guess the code would end up looking similar on a lot of teams

It's a little bit like ruby.. But

It's not object oriented, it's a functional language. It is polymorphic and all data is immutable. (Edit: actually realised its very much not like ruby, when I re-read this)

What I've seen in most projects is that the awesomeness that is threading (tasks and processes) is not really used. Supervisors aren't built as first class citizens.

I see teams eat the cost of NIH, but not get the benefits of crash fast, crash often.

So yes it does end up looking/smelling like ruby/rails but it really really shouldn't.

“A language that doesn't affect the way you think about programming, is not worth knowing.”

I like the quote at the end, I would change knowing to learning though

There is development joy found in both, but Elixir and the underlying erlang definitely has it's own idioms.

You can know enough to get going quickly, but there's a healthy layer of power that will only come with time.

Took me a year before I found a dev/manager that even scratched at that power. A dev that pushed me to learn it. Before that I was a rails dev writing elixir. :)

I should mention there is no problem not going there. I respect my teammates. Ruby/Rails is a great way to get things done. I would 100% use it as my MVP lang.

That nailed what I wanted to know. Thanks!

I didn't want to confess, but yes you're right. Elixir (or the willingness to learn Elixir) is a great filter for me to find the right people. Again, this is my purely subjective opinion and might as well be true for other languages as well.

I'll more or less echo what nelsonic said.

No one where I work has come in with Elixir experience. We look for people that are motivated to learn. Elixir has been one of the easier languages in my career to learn, and I think others that I work with would agree with that.

The degree of difficulty with learning Elixir/OTP depends on what one needs to learn. Phoenix web development has its own domain of learning requirements where as other domains have theirs. Learning Elixir is one thing but learning OTP, and then learning how to make sound decisions about design/architecture, is far more demanding of effort and time. "How do others solve this?" leading to github search tends to fall far short of what one would find with other language ecosystems.

Moving from Python/JS -> Elixir at a startup seems very high risk, have the rewards been worth it? I can imagine issues with hiring, unknown unknowns, and less libraries/support in general.

I know-- I was scared like hell. But after the first week and multiple staging releases in less than 10 days, I was on top of it. Yes, hiring is real challenge and am facing it already. However, if I, even as a startup, reach the salary threshold, then hiring is not a problem. I'd say I've yet not found a case where I couldn't find a library for my use case.

The start-up I work for uses Phoenix and Elixir. I've been there around two years now and we haven't experienced any issues with hiring or finding skilled people. If anything, I'd point to Elixir as being one of the major factors of our success.

We are a remote company, so things may not be as easy, depending on your location, if your company demands people be in the office.

I also would choose Elixir/Phoenix. Having spent my career in Python/Django, Elixir/Phoenix/Live View is on another level of productivity.

For anyone needing a reason to jump into Elixir, take 40 minutes and watch this talk [1] by Sasa Juric. He communicates things so well as to all the benefits of Elixir/Erlang/BEAM.

Then take the time to read Elixir in Action book (again, Sasa) and you'll be off to the races.

[1] https://www.youtube.com/watch?v=JvBT4XBdoUE

I also went this route, but am keeping the infrastructure simple in order to minimize lock in. It has been super productive but also I've spent years using elixir professionally and unprofessionally so I'm comfortable with it. The nice thing is that the elixir ecosystem is so robust you don't need to get locked into whatever cloud provider solution is in vogue at the moment. Also, we got a pile of cloud credits from different providers, and intend to use them :)

I too would reach for the PETAL stack you mentioned. I don't code professionally anymore, but when I did I had experience using a lot of different languages (e.g., C#, Java, PHP, Ruby, Elm, Python, Perl, Lisp, Node, Clojure, F#, etc.). Elixir is by far the most productive and joyful language I've ever experienced. It's absolutely beautiful.

Adding my vote here. Throughout my career I've gone the C#.NET -> RoR -> Clojure -> Elixir/Phoenix route. After spending a year with Elixir, iterating rapidly on a production system, I'd default to it for any MVP or serious project going forward.

LiveView is also very close to becoming default over React for interactive Frontends.

We use Nomad at $JOB and it's been great. We're a small startup with one senior site reliability engineer doing pretty much all the infra work and I (~CTO) chip in when I can be useful, though when we adopted Nomad it was just me working on infra.

I looked into Kubernetes (I haven't worked with it at all before) and there just seemed so much complexity to handle things I didn't need that it was too much to learn for the benefit. Once I found Nomad it was a lot simpler, but it has everything we need and that's stayed true as we've grown.

I'd definitely strongly recommend it if you're wanting an orchestration system and don't need the complexity Kubernetes brings.

For deployment I'm using Docker + Github CI + Digital Ocean basic droplets. Docker support is built into Phoenix, all you need is `mix phx.gen.release --docker`.

What I like about it is that upgrading a DO host is basically a matter of spinning off a new droplet and install Docker on it. Also, setting up deployment for a new Phoenix project takes about 30 minutes now.

I feel similarly, except for the AlpineJS part. I think PETL is fantastic and I would 100% choose that for my stack.

Is Liveview CSP compatible? I found out that Alpine isn't and the alternate CSP build of it isn't stable.

I'll second this. Alpine.js is so nice.

Fly.io is great!

Personally big on Rails (use it at work every day). But, my last MVP I did with TS/Next/Mantine/Supabase/Vercel.

Reasons:

- I've been using Rails as an API only, so having to grok views felt like a waste. My React skills made me feel that learning how to make complex views in my backend was a waste of time.

- One type of bug I hate is ensuring my API calls have the right schema. With Supabase and TS in the frontend, this is a non-issue: export types from db schema and all frontend requests are typed.

- Supabase is something for sure: I had been eyeing it for a while now, and it did not disappoint. Getting endpoints - even with realtime updates/subs in the frontend - after just defining a schema is magical.

- Auth is super simple with RLS - all this uses my SQL knowledge and makes me double down on it, which seems like a sane choice given it's been around for decades.

- Mantine gives me a large list of prebuilt components. This isn't exclusive to this stack but would highly recommend using something like this instead of just Bootstrap or Tailwind on its own.

Overall I'm happy with the results, feels way faster than my React/Rails workflow. Way less time in the backend (models, migrations, presenters, etc), more focus on tweaking the product.

Con: does not move me in the direction of using Python more. Feel like this is going to be a must-have for AI-powered components.

Same, Next.js, Vercel, Prisma, Supabase. I push to my GitHub repo and the site is live and deployed in less than a minute.

With the stack you can use the same language, DTOs, libraries, etc.. both server and client side.

Server side rendering ensures a graceful handoff between server rendered state and the resulting app state on the client.

I’m also using MUI which includes all the components you need for a front end app.

I also just really like react/JSX, very strongly typed coupling between the html and JavaScript. Makes it very easy to refactor and pull out new components with confidence.

I really think this is the best stack for an MVP CRUD app right now. Interested to hear of anything better.

This stack is pretty incomplete for most MVPs, as unless you're building something trivial like a landing page, you'll probably at some point also need libraries or a custom implementation for:

- Validations

- Translations

- Error and request logging and auditing

- Security (CQRS, CORS, CSRF)

- Permissions and a way to integrate it with your authentication (does supabase handle this? don't know)

- Email sending

- Background jobs

- Caching

- File uploading

- Rate limiting

- ...

Every time somebody suggests "just" Next.js, just "Remix", just "flask" or just [insert minimalist framework] I think they're either building something pretty trivial, or wasting a lot of time on rebuilding or integrating things you get for free with batteries included frameworks.

(supabase CEO)

We wouldn't be the best fit for all of these, but here are some:

- Validations: handled already by Postgres and if you use JSONB you can use pg_jsonschema[0]

- Translations: probably won't ever be part of our stack, but for multilingual FTS we offer the pgroonga extension[1]

- Permissions: we offer AuthN (email & social logins, MFA, SSO) [2] and AuthZ with Postgres RLS[3]

- Background jobs: pg_cron [4]

- Caching: For images we have a smart cache [5]. We'll extend this to database queries over time

- File uploading: supabase storage [6]

[0] pg_jsonschema: https://supabase.com/blog/pg-jsonschema-a-postgres-extension...

[1] pgroonga: https://pgroonga.github.io/

[2] AuthN: https://supabase.com/docs/guides/auth/overview

[3] AuthZ with Postgres RLS: https://supabase.com/docs/guides/auth/row-level-security

[4] pg_cron: https://supabase.com/docs/guides/database/extensions/pgcron

[5] smart image cache: https://supabase.com/blog/storage-image-resizing-smart-cdn#s...

[6] supabase storage: https://supabase.com/storage

I mean, yeah you need more libraries, but I wouldn't list Formik/mobx/react-i18n/Sendgrid when talking at this level of abstraction.

That stuff isn't "hard" per se, and some of that stuff isn't even needed for a MVP, they're good to haves or only really required when you've got 100s of users (product dependant of course). If the MVP doesn't get there either iterate product or bin it

None of these are difficult per se. Multiple of them, working seamlessly together, having them tested, documented and battle tested is a bit more difficult.

Then you think about all that time doing this could have been spent in actual business logic and it makes no sense to me anymore.

The post is literally about building an MVP. Remix isn't a minimalist framework - it's a full stack web framework.

Maybe next js instead of supabase?

Next.js is more about frontend, but Supabase is more on backend. I cannot see any conflicts of the two, they can work with each other flawlessly.

Meant to say Nest.js sorry

This is a really nice stack and what I’m using together with a colleague right now.

Do you use the serverless functions available with Vercel/Supabase? If so, I’m curious how you choose when to go with each provider.

I use vercel functions for this side-project bc they worked out of the box. Just least friction tbh not sure if optimal.

Ah you comment about MUI reminded me to include Mantine, also big productivity driver.

Wish I could afford vercel

Super generous free similar product is netlify... you get 300 build minutes per month, I've never even gone above their free tier haha

Unless something has changed, they explicitly disallow any website that facilitates for profit commerce. Granted I don't think they closely monitor it unless your bandwidth is over a certain threshold. However, Cloudflare Pages is free and unlimited FWIW but I doesn't seem as nice or fast as Vercel.

Remember we’re talking about MVP. Moving this stack to a VPS would only add a day.

> Con: does not move me in the direction of using Python more. Feel like this is going to be a must-have for AI-powered components.

This is why too many companies build on Python... some thought that maybe someday they will need some AI something, and they hamstring themselves from the start with inferior tooling.

I'm glad I came across your comment, I'm planning a 2-week project for learning purposes and I thought rails backend with react/ svelte would be the fastest way to prototype.

My ruby/ rails experience is very limited compared to my JS experience; I really just started experimenting with rails. I'm blown away by the magic, JS frameworks feel like toys in comparison. I also like that Rails is omakase.

Based on your experience, would you suggest trying rails or going the full JS stack route?

I was faced with this decision a month ago and started building my models and views in Rails 7. Late night tinkering with views, then trying out ViewComponent I went 'dude wtf am I doing, these apps are so easy to build in React'... Next.js with Supabase has been a breeze. Setting up db with auth and getting realtime updates and object storage with minimal setup (TS fn calls) was mind-blowing.

Caveats: setting up Supabase auth takes a bit of reading docs, using the js helpers correctly and configuring RLS, but after that it just works.

imo rails without react and leveraging hotwire is going to be the next big thing in web dev. react is a huge increase in complexity for not much appreciable gain. you are not facebook and don't have facebook's needs. rails is nimble by itself.

I'm a fan of this too, and it honestly confuses me that people would do a Rails API with React for a MVP.

If you're already doing the backend in rails, it's hardly any more work to just do hotwire with server side rendering at the same time, and you can switch to a SPA later (if you really do need to).

Most people in this thread are not suggesting a stack for an mvp. They’re just listing their favorite stacks, that’s it.

There’s a comment of somebody saying that just Postgres and Go. How on earth is that a good stack for building an mvp?? You’ll have to write a shit ton of code or glue together 10 thousand libraries.

it's also not a ton more work to pivot and turn the rails app with hotwire into an ios/android app with a minimal amount of work. and yeah you can also sprinkle react in if you need some component or two or even do the api that way and drop into a full SPA if you really need that. but at that point you are doubling the amount of work on the frontend for little gain in my view.

I liked the idea of react and have used it but i don't feel like it improves the situation enough for 95% of the sites out there to justify it and the enormous extra work there is in getting state/routing/etc to jive with the backend. I'm hoping strada, if it ever comes out, will be a large improvement to turbo native and at least provide a very compelling alternative react native.

I would love to learn more about this. As a complete beginner though I tried to find resources for full-stack Rails and unfortunately there is nothing much there that teaches you the new front-end or shows how to build an MVP.

Compared to that JS ecosystem perhaps has too much :)

Hotwire is pretty new but there are some guides out there. it's a progressive enhancement thing generally so you build it normally and then sprinkle in the extra stuff.

1000 foot overview: https://boringrails.com/articles/thinking-in-hotwire-progres...

a tutorial: https://www.hotrails.dev/turbo-rails

a video tutorial: https://www.driftingruby.com/episodes/hotwire-introduction

probably a good paid option: https://pragmaticstudio.com/hotwire-rails

and then there is the main site: https://turbo.hotwired.dev/

cheers!

Thank you!

I'd stick with rails unless you have a complex front-end where UI responsiveness is of the essential (i.e., highly graphical-interactive). React is many levels up in terms of complexity.

Rails and React are doing completely different things in the stack; I don't understand this argument (having worked with both, but never getting good at Rails)

React is purely about managing the frontend and user interactions. Many apps are very heavy on this. For a lot of things I've built, I think Rails would have been overkill. Even for ones that use a database, I find node.js/express/prisma much easier to work with (until you get into migrations). Activerecord's story around migrations is the best I've used.

But for an MVP you don't really need to worry about that.

Mantine is such a good library, especially when compared to Material, Semantic, etc. I’ve used it with a couple projects and have been very impressed.

What's RLS? Row Level Security?

Correct. We suggest using Postgres Row Level Security if you use the Supabase APIs + Auth: https://supabase.com/docs/guides/auth/row-level-security

You don't have to use RLS if you BYO middleware, but the RLS approach give you the option to do `frontent <-> backend` (vs `frontend <-> middleware <-> backend`)

Definitely old schools. I am building a MVP right now(kinda building my parachute while jumping off the plane)and I went with Django. And here is why. 1. Very vibrant community of devs and time-tested open-source libraries.If you want a multi-tenancy there is a library for that. IF you want stripe integration there is one for that. If you want "fully built out" services, then we have a plethora of free and paid templates. There are folks here(HN User rlawson)who have built many side projects using Django that they have monitized. if that monetization is your goal, then time is money and Django is your friend. 2. Very easy to deploy. This is a Major major requirement for someone like me(dabbling in webdev). Even after the demise of Heroku hobby dynos, there are things like Railway.app which lets you git deploy app, try it out and then scale it if you want. 3. Lastly, Javascript not necessary- I am a "hobby python dev". I don't have the inclination nor the time to learn yet another Javascript framework. I have an idea, know a bit of Python and I want to iterate it on my idea fast and get to the customer ASAP. Meaning, I can deploy a MVP without having to dabble with JS while jumping through all the different web pack configurations. A big win for me. So, "boring stack" definitely.

For context I'm someone who spent nearly 20 years doing almost exclusively python dev, attended the first DjangoCon in 2008, ran the Django community blog during its formation heyday back in the mid 2000's and built tons of Django modules, apps, sites etc, have commits on the Project from way-back, tech edited Django books, etc...

Did rails for a short while in 2010-2012 and absolutely hated it then spent 2012-2020 doing mostly Python/Flask dev for huge fintech companies on AWS.

I now use Javascript/React/Nextjs on Firebase/Google Cloud. So much less hassle, tons more libraries and what seems like an exponentially larger ecosystem. There's still weird shit with transpiling typescript to javascript etc... but overall I enjoy JS dev much more these days.

Be aware that firebase or aws are only good until you have actual traffic. So in many cases you just loose time you spent understanding their managed infra. I would advice to go with Linode. As a bonus you get to lean new techs that are not tied to crazy managed pricing :)

If the traffic to your app is generating a significant Firebase bill then you have probably moved from MVP to successful app territory. Would you rather start managing more infra or focus on keep building features that add value to the app?

I would be interested in hearing of any instance where Firebase costs created financial hardship.

Any tutorials for handling next js and a private server ( like linode)

As a long time python dev, I’m now not certain why I would use python for a web app, over typescript on Next, other than familiarity. Sharing types between the server and client, and only having to manage _one_ software ecosystem is great.

Some potential reasons:

1. The data layer, if you want a high-quality ORM and migrations

SQLAlchemy + Alembic (or Django ORM + its built-in migrations) are battle-tested systems that I trust will scale to large teams and not break my data.

If you're more of the persuasion to write raw SQL, or to just use a SQL query builder, Python is less of a draw these days (although SQLAlchemy's query builder is quite nice and can be used independent of its ORM).

2. Ties to the data science + machine learning universe

If your back-end intersects with these in ways that are not cleanly separable into services, Python might be a good (or the only) option. Even if you can cleanly separate, you're effectively committed to managing Python on the back-end.

3. Stability

For good and ill, the JavaScript ecosystem churns far more rapidly.

4. Familiarity

To your point: there's nothing wrong about optimizing for creature comforts and/or velocity from just having done it before and fired the foot-guns.

---

I agree that using a single language provides an advantage at the API boundary. Curiously, my experience is that most modern javascript frameworks (like NextJS) don't have a lot to say about how to structure this in practice. Maybe that's fine, but I'd love to see some opinions emerge in the ecosystem.

Amongst other things, I typically want to:

- Share types (typescript `interface`s, etc.) between the front-end and back-end (while avoiding accidentally bundling back-end code into the front)

- Have run-time types (via `zod`, `io-ts`, whatever) for (at minimum) API request structures so I can validate my inputs

- Have a story about how API validation failures are shipped back to the client (and how the client exposes them to the users, e.g. error messages when filling out form fields)

- Differentiate between API types and my underlying data model (the `User` in my database is somewhat to very different from the `APIUser` I ship to my client)

In the python universe, Django, Flask, and FastAPI all have well developed opinions about run-time types, validation failures, and API types vs. data models.

On 1 - I've worked at startups using Django ORM and banking companies using MSSQL stored procs. I don't understand why anyone would ever go the stored proc/raw SQL way unless they absolutely needed the performance. And if you do need the performance, you can always dip down to that level from whatever ORM you are using.

Most of the queries I've done using Django can be optimized at the application code level to be fast and efficient without even touching SQL. There were a few instances at the two Django shops I've worked where we optimized one or two queries by writing raw SQL, but the number of times I've seen that in a codebase can be counted on one hand.

The SQL/stored proc method, on the other hand, doesn't come with any way to do migrations or version your database by default (AFAIK). So now you have to write migration code and come up with some kind of versioning system by hand.

Wish I had more experience with SQLAlchemy/Alembic. I've tried using it on little things here and there but since I've always known Django, that's what I usually go with.

What to you use for ORM/database migrations with Next.js apps?

I had a similar journey but with Rails and ended up in a similar place.

React+Nextjs on Firebase makes the deployment and scaling steps so much easier than on Rails. I'm very conscious of the platform risk of depending so much on Firebase but gosh darn it they've spoiled me.

It’s funny that only in our industry “time tested”/“battle tested” is called old school and frowned upon. No wonder we see software bloat everywhere.

Eh, I think experimental physicists and medical imaging also lean towards newer tech.

No area of health work tends towards new tech. It's disallowed by regulation.

Eh.. you'd be surprised. Medical Imaging isn't as radical as you may think it is (I spent 7 years doing projects for the exploitation of medical images).

I’ve had the pleasure of annual echo cardiograms my whole life, and moved around a lot, and at least my experience has been visible hardware/software/imagine improvements almost annually.

In any event I wasn’t saying all medical imaging is state of the art, I was saying it is another field where people prefer newer tech.

Absolutely fair. The vendors have gotten much much better tech "in the room" as it were - CT's are lightning fast anymore, US is clearer and can do more on-the-fly analysis than ever before (e.g. highlighting bloodflow dynamically and capturing tons of data in microseconds), etc. Every modality has grown tremendously so my comment wasn't nearly fair enough in acknowledging that.

Downstream is getting better with items such as AI advancements and more sophisticated mechanisms to transfer data between systems both on-prem and cloud-based, however utilization of all of this tend to be stifled a ton by the standard issue of tech moving faster than policy. My frustration/disgruntlement is due to this issue more than anything.

Thanks for the insight and the reminder that my bubble of experience isn't the world - seriously.

Anecdotal, but a co-worker’s parent works at NHIS and I’ve heard they’ve adopted Kubernetes.

JS frameworks are also battle tested. "old school" is not necessarily a bonus because the common paradigms have shifted.

Using Django with React is not as easy as a full-stack framework like Next.js. Modern tech stacks are now generally moving towards either full-stack JS frameworks like Next.js, Remix, Astro, etc and/or serverless with things like railway.app, fly.io, Cloudflare Workers, Deno Deploy, Supabase, neon.tech, etc.

Many features of "old school" frameworks are becoming redundant or are being replaced by options with better DX.

I do not want to start a flamewar, but most of the things you mentioned Next.js, Remix, Astro, fly.io etc are not even 6 years old. Django is running production ready code since about 2006 and has more shelf life. I was not downvoting JS but in terms of longevity and robustness, Django has that going for it.

[dead]

Did a big migration from Flask to Django for my main side project for all of these reasons earlier this year.

I love Django. It's criminally underrated.

Side project if anyone's interested in peeping it: https://www.fpgajobs.com

I’d imagine many are curious like me … are you making any money on this? I have a similar Niche job site I’m thinking of

Fellow EE here and love what you do! Loved your post on scraping.Btw, I thought you used Flask. Looks like I was wrong.

Thanks for the kind words. It’s probably time for me to revise that a bit, or write another one. I’ve learned a lot more yet since I wrote that.

I used to use Flask, but I changed over to Django at the end of 2022. Super happy I did. It wasn’t painless, but the benefits have been totally worth it.

What were the benefits switching over to Django from Flask?

Batteries included admin console with easily configurable model views.

Built in migrations. Can’t possibly overstate how much this has helped ease deployment. Most of the live debug and prod edits I had to do on the older app were due to db migrations not being shipped with the app.

A baked in ORM with lots of backend optimizations like pagination that keep your queries fast, plus convenience functions for model creation and retrieval (long live get_or_create)

There was a learning curve to all of this, and the complexity of all this in the tutorial scared me away at first, but having seen how the other half lives with Flask, where there are no guardrails for anything, I really appreciate having a framework that solves these kinds of challenges for me.

Interesting, appreciate the reply. Wouldn't hurt to add it to the repertoire.

One more big benefit: you can figure out how to do almost anything with Django with the right combination of Google and Stack Overflow searches. Not so for Flask.

Ok, well, maybe there are some answers, but it’s always like “Install, configure, and integrate this third party plugin”. Ain’t nobody who’s side-hustlin’ got time for that.

IMO for early stage startups, proven tech is almost always a better bet than the hot new thing. Your goal is to capture market share quickly, not wrangle beta tech into place.

Is there a multitenancy package?

Is it this one?

https://djangopackages.org/grids/g/multi-tenancy/

I know there is a paid one.

Yes this is the one. Or one could also use the https://django-tenant-schemas.readthedocs.io/en/latest/. I don’t want to plug any paid options for obvious reasons but they are posted here regularly

Agreed, although I'd really like to throw in type safety, because the lack of it made my life needlessly complicated. Is this feasible with Python?

Type hints in Python are nice, by pale in comparison to truly typed languages. If you want to feel like your language’s type system significantly improves your development experience and the safety of your code, don’t pick Python.

What would be a nice contender for someone who is otherwise happy with Python? I love that I can use it for darn near anything.

It’s not enforced at runtime, but otherwise I feel like typing is in a pretty good place in Python right now. If you’re diligent about using Pyright or MyPy as linters it makes life a lot easier.

Type hints in python also work great with vscode (and probably other IDEs) as it can offer better autocomplete suggestions for things like function parameters.

The one thing that Django is missing is the ability to attach a User object to a session without a full-fledged RDBMS. I wish it was structured like the Session object which you can in your own backends for.

This is unlikely to ever happen though since so much is tied to it like the permissions system and the admin. The ORM itself is central. I wouldn’t use Django unless your project depends on an RDBMS.

Even if not using a database, I will always reach for Django over a Flask or FastAPI. Yes, there is more boilerplate when just offering a few memory views, but there is so much ecosystem built around the tooling that the expense is worth it. Just making a form or sending an email from Flask requires a third party library which will never receive the level of maintenance as first-party Django. As an example, the often recommended (still mentioned on the Flask Mega-Tutorial) Flask-Mail package last had a commit in 2014.

Fair. I'd probably reach for it too if I had any kind of frontend required, even if that were just HTML and forms. For server-only applications I'd probably go with FastAPI these days and I'm actually looking forward to an all-in-one framework that encompasses FastAPI as the core.

one thing I'd like to see in Django is something similar to InertiaJS [1], just being able to use VueJS for the view layer is amazing and passing data from the backend to the frontend without having to build complex api systems is a godsend. Maybe I haven't done enough research but is there something similar in Django world ?

[1] https://inertiajs.com/

Still a bit raw on the edges, but IDOM [0] looks interesting and has a Django integration [1].

[0]: https://idom-docs.herokuapp.com/docs/index.html [1]: https://github.com/idom-team/django-idom

interesting, is this something similar to htmx ?

https://github.com/inertiajs/inertia-django

Reactivated [1] looks similar in spirit, but using React on the frontend. I haven't tested it yet but the idea is very interesting.

[1] https://www.reactivated.io/

do you still use builtin views/templates ?

Yes! Trying to keep it as simple as possible! Might try this whole HTML over the wire after I have made some dough. Not now tho. My customers don’t give a damn about my stack

Django, in my previous role we did MVP websites for academics and the speed of getting a site up and running and deployed was just so fast. I’ve never worked with anything else that is as fast, anything like FastAPI or Flask or Express or similar either requires additional libraries to add really basic and common functionality or you have to roll it yourself.

I personally don’t think that if you’re building an MVP you should be worrying that much about how to store users in the database and add RBAC and building a way to add middleware and a storage layer and all of that crap. It’s not worth it, your application is not a special snowflake.

Edit: Should say that with that I mean serving HTML via Django. Usually I would use Bootstrap for layout. Very occasionally I’d add an API for some interactivity but I think for most MVPs interactivity is likely to be a secondary concern until later.

Came here to say this. I have a side project that I need to spin up quickly and after lots of framework shopping, I settled for Django.

Django and it's batteries included philosophy is perfect for creating full stack applications. The best thing about Django is that almost every problem you face has been answered by the community.

The community tools like DRF/Django-Ninja/Crispy-forms/Django-environ etc are top notch and it's very easy to extend your application.

7/5 would use Django again.

>The best thing about Django is that almost every problem you face has been answered by the community.

This is something I realized pretty quickly when toying with migrating my side project from Flask to Django last year. Everything I wanted to know how to do, I could google with “Django” as the first term, and figure out how to accomplish. Anything that took longer than 2 mins to figure out how to do was generally a matter of not knowing how to phrase the question.

It’s made me a huge Django advocate.

The Django community is amazing - very friendly, welcoming and a very rich 3rd party app ecosystem.

Nowadays, Django has an amazing library which is a lot like FastAPI but in the Django ecosystem.

https://django-ninja.rest-framework.com/

It's absolutely wonderful. I would use that in a MVP, and do the F/E in NextJS + Typescript.

I’m familiar with it, and I don’t love DRF but the downside with Ninja is that you end up writing a lot more boilerplate IMO. Unless you’re strongly optimising for performance (and usually latency and the database are the biggest issues there), you can get away with ModelSerializer and DRF ViewSets a lot of the time for APIs and write very little code.

The biggest benefit to Django, in my opinion, is the orm and admin tooling. Being able to fix things in your app without having to open a repl or open a database tool is absolutely killer.

I honestly cannot believe that Rails doesn't have this built in. This was something that was in Django for as long as I can remember; I was looking at it in I think 2006 and it existed at that point in a very similar state to what I've seen lately.

Not a dig on Rails, like "Oh, Rails is so bad they don't even have..."; rather, Rails is extremely capable, and so are Rails devs, so I legitimately don't understand why this isn't there already, 15+ years after Django.

Rails has Active Admin which is equivalent to what you get with Django. It's just not a core Rails gem but it's one line in your Gemfile to add it.

Whoah I never knew that - or maybe did but never seriously considered it. It's been my biggest surface-level gripe with Rails compared to Django so thank you very much for bringing it up

Edit: and it' still maintained !

There's a handful of very capable and mature admin solutions (activeadmin, rails_admin, administrate, and still people coming up with new ideas, see avo and madmin as newer examples), they just haven't had one become bundled mainline.

Similar situation with authentication, where devise has been a mainstay for over a decade, but it's not always the best fit for everybody so core rails still just has the basic plumbing to build it yourself (with the low-level has_secure_password).

To be fair, Django only caught up with Rails in the past 5 years. When I started with Django it didn't have basic stuff that Rails had, such like auto database migrations and the Rails asset pipeline. The database migration stuff really helps when building/iterating. The Django middleware was very finky at the time.

FWIW, Django has built in migrations since 1.7 which was released in Sep/2014.

The Django Book is phenomenal. It is just so well-written and so clear that it makes my heart ache: https://django-book.readthedocs.io/en/latest/introduction.ht...

Another good one is Tango with Django. https://www.tangowithdjango.com/

I‘m trying to learn Django just for this kind of MVP purposes. I also did a small mini project in RoR by following their documentation. Is there anything that is significantly easier to do in RoR vs. Django? Alternatively, is there anything, say, on a larger scale that I can do with RoR that I cannot do in Django if the project grows? These are the questions I‘ve been wrestling with quite a bit now. After learning Vue and React.js and having used and being cognizant of Next, Nuxt, Supabase, Firebase and all that other stuff, I‘m looking to become a bit of a better developer by understanding the intricacies of traditional monoliths and how problems are solved on the backend. I‘d also like to be able to serve predictions and host ML models in production. Likewise, if my MVPs catch on, I’d like to retain majority of my ”IP” by the means of Django or RoR. Any intuition perhaps on my above questions? Thx!

My 2c.

Django shines at creating a nice project scaffold with all the things you need to do rapid development. It has first class support for DB, unit testing, schema migrations, good enough templating system, performant ORM and can be easily debugged. The documentation is top notch and the best thing is the community. Due to its longevity I found that almost all the issues I had were resolved by a simple Google query or visiting the docs.

It’s very easy to add functionality like social auth with few lines of code.

I’ve also not found anything like Django admin in any other framework. I would highly recommended Django for an MVP.

My view on this is that there is little between them so in that case it’s better to look at availability of skills you’d need to take it forwards in the operating region. For e.g. if it’s easier to hire Ruby developers then choose Rails.

I see a lot of people talking about Elixir, etc. on this thread, but I’m based in the U.K. and I’ve never seen a company locally using Elixir so even if it’s really cool, it’d be a bad idea for me to choose it absent a very very good reason. If I choose Django then even if I can’t find a Django developer, I can likely find people who know Python and the barrier to entry is pretty easy.

Several companies in the UK use Elixir including the BBC, USWitch and the NHS! The London Elixir Meetup https://www.meetup.com/elixir-london/ has 1,467 members and is great place to meet fellow alchemists and learn interesting things!

I’m not in London ;)

Noted. but responding to the “UK” comment; London is often a good guide/proxy for the UK tech scene. But for reference: there are quite a few universities in the UK where students are learning & using Elixir for distributed/embedded computing projects so these people will gradually filter through into the workforce.

Also there are plenty of Ruby/Rails Devs who have embraced Elixir/Phoenix.

But it’s a classic network effect problem; adoption drives jobs which drives learning and further adoption. Without a big corporate sponsor like a FAANG co, Elixir/Phoenix doesn’t have the mindshare of other languages/platforms.

In my city, if I restrict it to the “Greater X” area that includes some outlying towns on LinkedIn, I get 7 people that mention Elixir, and 3400 with Python. If I do the same in London, I get 751 people listing Elixir and 113k listing Python.

The scale is just not there to make it worthwhile in evaluating for any company to adopt other than a FAANG or really major employer IMO

Thank you for such a great and senseful answer!

If you thinking of anything closely related to ML then python/django is the way to go.

This is where I came out a couple of years ago. I love Django and it has worked out perfectly. But I'm far from an expert.

HTML, css, js, (maybe jquery and font-awesome if I want to get fancy) and all static files dumped in an S3 bucket for as long as I can get away with it, then django if I need anything more. Not that I think python/django is the "best", but it is what I know and it's got all the batteries included out of the box. I've never made a sufficiently advanced UI that required react/vue/etc. So I still just stick with html/css/jquery on the front end.

Semi-related side note: I do use TS/react in my 9-5, but the more I use it professionally, the more I'm convinced there is no need for it outside of trying to get a job, IMO.

Very similar to my approch.

One difference: I am in the process of stripping out jQuery from old projects. So I would not use it in new projects anymore. Plain JS is just awesome these days. And it is easier to reason about event listeners you have set yourself than wondering "Where does this mouseover event come from? Maybe its from jQueries hover function? Wouldn't that rather use mouseenter?".

Instead of an S3 bucket you can use GitHub Pages. You push stuff to the upstream git repo and it gets deployed. It’s free (you have to pay for GitHub Pro if you don’t want to make the source code publicly available) and comes with Fastly CDN if I recall correctly. You just have to configure your custom domain.

I use a GitHub action to sync to an s3 bucket, works extremely well.

my update.yml:

  name: Update Website
  on:
    push:
      branches:
      - production
  jobs:
    deploy:
      runs-on: ubuntu-latest
      steps:
      - uses: actions/checkout@master
      - uses: jakejarvis/s3-sync-action@master
        with:
          args: 
        env:
          AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_REGION: 'myregion'
          SOURCE_DIR: 'mydir'

Just an FYI. You can now use OIDC to authenticate to AWS. This removes the need for hardcoded IDs and KEYs.

In the case of static HTML/JS/CSS, the webserver will make the source publicly available to your browser anyway, so that's not really an issue.

Use GH to push to S3 on commit. Done.

You should look into Cloudflare Pages. I'm using it for all my sites, and it's completely free. Automatic deploys when you push code to GitHub, serverless functions called workers baked in, and built-in analytics. Not to mention, you get high-speed CDN caching for free.

I wonder why people like s3 buckets. if your website becomes viral it might become expensive

There is an AWS CDN available that can be placed in front of the s3 bucket. Also allows for custom domain names, TLS, globally distributed for low latency ec. https://aws.amazon.com/cloudfront/

True. For static only deployments, I would use Firebase or CloudFlare or Vercel or Netlify etc. You get automatic CDN and generous free quota.

It’s pretty easy and free to slap a CDN like Cloudflare on top of an S3 bucket

> I've never made a sufficiently advanced UI that required react/vue/etc.

There is no such UI. Users don't want 'advanced' UI.

Hhere is quick survey :

Regarding backend choices:

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i Django | wc -l
  36

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i supabase | wc -l
  17

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i rails | wc -l
  28

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i node | wc -l
  15

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i elixir| wc -l
  14

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i phoenix | wc -l
  7

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i fastapi | wc -l
  7

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i svelte | wc -l
  9
  curl "https://news.ycombinator.com/item?id=34530052" | grep -i React | wc -l
  34
  curl "https://news.ycombinator.com/item?id=34530052" | grep -i htmx | wc -l
  15

Wow, now curl is doing pretty well in the rankings!

C is winning

R really ramped up its rankings and seems to be running ahead of the rest ;)

. is doing best actually

tangent: asked ChatGPT to update your code to use for loops and voila:

Backend Choices:

  for backend in "Django" "supabase" "rails" "node" "elixir" "phoenix" "fastapi"; do
  count=$(curl -s "https://news.ycombinator.com/item?id=34530052" | grep -i "$backend" | wc -l)
  echo "$backend: $count"
  done

  Frontend Choices:

  for frontend in "svelte" "React" "htmx"; do
  count=$(curl -s "https://news.ycombinator.com/item?id=34530052" | grep -i "$frontend" | wc -l)
  echo "$frontend: $count"
  done

Ask chatgpt to collect every possible frontend and backend frameworks form this post.

Should include Laravel too, which would also be my answer.

Laravel is just as big as Django and Rails in adoption, definitely should be included

   curl "https://news.ycombinator.com/item?id=34530052" | grep -i Go | wc -l
   891

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i vue | wc -l
  14

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i laravel | wc -l
  10

But doesn't that ignore the negative comments, e.g. don't use rails! /s

for that case we need to build a language model :D

Grepgpt? ;)

Edit:

apt install grepgpt

Downloading 0% of 5GB #......

you left out at least vuejs for frontend

still collecting frontend parts

Deno didnt make the list...

For good reason.

Curious! Can you please elaborate?

Well that depends a bit on what the MVP needs to be.

Anything web related I'm probably going the Elixir/Phoenix route. I'm no web dev, but this combination makes me actually kind of like doing web-things with how batteries included it is, and the tools it provides to really jump start a project. Then I'd host it "old schoolish" in a VPS or similar since that's what I know best. Might consider being fancy and investigating if Fly is a good fit. If a DB is required I'd use SQLite unless some constraint pushes me into Postgres.

If we're talking command line tool, the correct answer for me would be C# since that's what I know best. The answer I'd want to give though is Go since I want to get deeper into it, but that's not a good business decision.

Desktop application, best I've got in my kit is WinForms with C# and prayers that it never need run on anything but Windows. Maybe Linux with some Wine trickery, but that's not something I've done before either.

Agreed Elixir/Phoenix + Tailwind is at the sweet spot of scalability, performance, and bonkers productivity.

Real time? Need to go distributed? Maximize # of features / developer bandwidth? Cutting edge machine learning training & model serving?

Mobile? JSON APIs and GraphQL tooling is great, but https://github.com/liveviewnative is moving fast so this stack almost has the exodia of full stack, one language, and distributed actor model based scalability.

Honestly I continue to be amazed with each year of developments. The increased robustness of the greater Elixir ecosystem is unreal. The best part to me too is despite how active it all is, progress overall is very measured and sane. It also doesn't develop at such a pace that it feels exhausting to keep track of, despite all the great work.

What I like about elixir is that it feels like developing with javascript, but you're not delivering megabytes of js to the client

> Cutting edge machine learning training & model serving?

I am curious about this. Do you have more infos?

Totally agree! For almost all web-based MVPs the PETAL Stack (Phoenix with LiveView & TailwindCSS) deployed to FREE Fly.io is an epic choice for both response times, realtime features, dev speed (time to market). We're currently building our MVP with it and it's fully Open Source so anyone can learn from our journey: https://github.com/dwyl/mvp

I really wanted to like LiveView but starting from 0 in the Erlang world meant learning a whole bunch of language semantics and idioms.

In fact I found it perhaps harder to get started than learning Rust, especially because the language server seemed unable to offer as rich completions compared to Rust.

In the end I did manage to understand most of the primitives and concepts in the basic sample app, but it did make me re-evaluate if it is the best choice in terms of technology adoption when it departs from most typical Python/JS/C family style conventions.

Totally agree that the learning curve can feel steep learning Functional Programming style, Elixir Syntax and Phoenix framework in one go. But if it’s any consolation, our company has taken people who only JS or Python and got them fully up-to-speed in less than a week using the open/free tutorials we’ve written: https://github.com/dwyl/technology-stack HN feedback very much welcome.

That looks like a fantastic resource, especially appreciate the update you've provided here https://github.com/dwyl/learn-elixir/issues/102

I'll definitely have to keep at it and play around more, thanks!

Thanks for this link, I'll give it a go!

I can sympathize, it was a huge jump for me coming from C# land, and I see this sentiment repeated a bit for newcomers so it might be the nature of the beast.

I definitely wouldn't recommend it for an MVP if someone isn't already into it, but then I don't think MVPs with tight business requirements are generally a good place to explore new technology anyway. I think there's a lot of room for nuance there though.

Never heard of phoenix but sounds interesting. What's the persistence layer of the stack?

Typically Postgres

LiveView is great but IMHO it's easily abused. "No JS, ever" is a mistake. IMHO it works best when there's very clear rules with where one should use LiveView vs JS.

I'm building an MVP solo.

Rust for the core application, Elixir for the backend, frontend, API, data layer. Javascript is pretty much non-existent, all client-side interactivity is done by LiveView.

Packaged into a podman container and deployed to a Hetzner dedicated server. Storage on PostgreSQL, probably the only thing I would rather not have to manage, but honestly single node is perfectly fine for an MVP. Provisioning is done with Terraform and Ansible.

Future expansion (pretty far away, post launch and post paying customers) is add more geo-distributed worker VPSes, talking to the central coordinator via Wireguard link.

Setup is pretty cheap, fast, scales really well, and it's easy to understand. With additional services (mail, monitoring, etc.) should be less than $100/mo all inclusive, and that should be enough for up to ~100 paying customers.

I have no plans of changing any part of this setup for the next decade. I'm too old to want to get golden handcuffed to turn key solutions and cloud products that just introduce complexity and become VERY expensive, and badly documented, past the demo stage.

Started in November, closed alpha release with users next month, launching Q2 2023.

If the backend, frontend, API and data layer are in Elixir, what's actually written in Rust?

At the core there is a custom crawler written in Rust, with the goal of eventually releasing it as an open source standalone application.

But everything else, including scheduling the execution of this crawler, and parsing its output, is done on the Elixir monolith.

Would that be in Rust for performance reasons? Elixir IME isn't as slow as some other popular languages but it's no speed demon either.

Performance has nothing to do with it. You can imagine the application being a very specialised version of `wget`, and I like CLI system applications to be easy to distribute, with no dependencies and not requiring an entire VM to run.

Erlang/Elixir is good for networked servers. For CLI apps I either choose Go or Rust, and I much prefer the latter. Since I want to make this component open source, I wanted to keep it separate from the rest of the closed source, proprietary Elixir backend.

There is no wrong choice to be honest, this is mine for my startup, and I don't think I need more justification than "I am productive with it for the task at hand."

Rust also has the benefit of eliminating a ton of classes of bugs, which is great for the core of a product that connects to the network, fetches untrusted content, parses it, and (presumably) stores it somewhere.

Not that you can't still have bugs, but when you can get C-levels of speed with Python-levels of safety, why not?

"Python" levels of safety? Let's aim a little higher in life.

A crawler should be limited by the network not CPU. Outside of the language making it easier to handle multiple concurrent connections, I doubt speed would be much of a consideration.

I'm not sure, it might be. If you're not careful, CPU can become bottleneck when you have a 10Gbit network card.

How does Elixir interacts with the Rust code ?

The Rust app is kept as a standalone application. Elixir spawns the process, passes it an internal URL where it can post its output, and forgets about it, since each run might take a few minutes to hours to complete.

Via native implemented functions aka NIFs.

But do you code in vim?

Emacs.... Just kidding, of course vim

I love Rust and program in it a lot...but I would never use it for an MVP

Rust is the tool you use when you are done prototyping, not when you are just beginning

Hard disagree. Rust lets me move much more quickly in many scenarios. I wouldn't want to prototype in Python for example. In my experience I'll spend too much time debugging and dealing with typing issues if i did that. Even with type hints. Having solid tooling that I can trust to help me maintain quality while moving fast and a really good ecosystem makes Rust a good choice

Depends what you're prototyping. Rust is hard to beat for prototyping an interpreter, for example.

Ah… part of the process is having fun. If ppl enjoys rust, then rust is fine :-)

For an MVP, I'd choose what I'm most familiar with and can be fastest with. That would mean:

1. Laravel

2. An Ubuntu VPS in either Digital Ocean or Linode

3. A managed database in one of those services, likely Postgres

That would get me to market the quickest. I have no issues with the application being in Laravel/PHP and after getting to market, I'd work on making the infrastructure scalable. I wouldn't expect overnight success, so a single VPS and managed database would let me keep costs low while I pick up a few customers and then work to handle the scalability in the background (likely AWS with a combination of EC2/ECS/Fargate, RDS, SQS, SES, CodeDeploy, ElastiCache, etc.)

> For an MVP, I'd choose what I'm most familiar with and can be fastest with.

That is absolutely the takeaway here. Use the technology you are familiar with and/or can be fastest with. MVPs are risky enough, don't add in "oh, gosh, I have to learn the tech (libraries, deployments, monitoring, database access, etc)" as well.

The only case where I'd pick a new tech for an MVP is when there is an existing open source or free project that I could use that would obviously get the project shipped faster by providing extensive pre-built functionality.

For example, I once used Sharetribe https://github.com/sharetribe/sharetribe even though I was only an intermediate ruby programmer because, after time spent evaluating it and other solutions, it had functionality that could get us shipped faster.

From "git init" to our first beta customer was 1 month of time. Then to our first paying customer was 1 more month. One developer (me). To be fair, my co-founder had done a ton of market development before I started coding, so the initial market/feature discovery was done; that's a huge part of any MVP.

Why opt for managed db?

In my experience, I'm far more likely to run into database bottlenecks early on than web server bottlenecks (largely through hastily and poorly written queries or unchecked Eloquent N+1 problems). I'd opt for the managed DB so that there's limited chance that the database will affect other processes on the webserver (including serving requests, handling background and scheduled jobs, etc.)

It also makes it easier to scale within Linode/Digital Ocean if you find yourself needing to do that before the more complicated AWS infrastructure is ready.

Nothing really beats Rails. Use something like Jumpstart (jumpstartrails.com) and Avo (https://avohq.io) and you scaffold a full consumer-ready app in literally a few hours.

The thing that bugs me the most with Next.JS and the whole JAMStack movement is that, yeah, you get from "git clone" to deployed on Vercel in two minutes, but if you need to create real app features like a sturdy admin, accounts, authorization, proper asset management, CI/CD, it takes a whole lotta time. I'm not even touching the most common app features. I'm speaking from experience, from building a Next.JS app for about a year.

Most Next apps out there are incomplete with the worst freaking user experience. Insert any other JS framework or hosting provider in the place of Next.JS and Vercel.

Of course, this is a generalisation, not all Next apps are that bad.

Using Rails is like a cheat-code in dev term.

Thanks for making Avo! I'd been building something similar in the application I'm currently working on and it was nice to have something that already figured out much of the hard stuff to replace my shitty implementation.

Great to hear! Let me know if you run into issues.

If you are going to pay for a starter pack, you could get the same sort of thing for NextJS, right?

- Server: Node.js + SQLite

I know JS very well, so writing HTTP handlers is quite fast.

Node runs on V8, which is probably the fastest runtime for dynamic code.

SQLite makes development easier as it’s just a file, gives you ACID.

- Frontend: React/Mobx/Tailwind SPA hosted on firebase hosting.

I think the concept of JSX (write your HTML with JS) is good as it gives you a real language instead of a restricted templating DSL.

Tailwind for the fast iteration speed.

Firebase hosting for the simple CLI and fast CDN.

- OS and hosting: Docker running on Google Container Linux

Docker so that the OS level dependencies of my server are defined somewhere.

Container Linux as it auto updates and has all the GCP logging and monitoring built in.

GCP for the incremental disk snapshots for simple backup of the SQLite state.

If I had to scale the service I would add more CPU cores and faster disk. I would also move the parts that need scaling to Go/Rust, and design the code to make use of the cores.

A few principles I use when choosing tech:

- Avoid distributed state (network boundaries) when possible (SQLite instead of SQL server, function calls instead of micro services).

- Use tools for their primary purpose. No shoehorning. Issues arise when you try to use something for what it was not designed exactly for. If you have >3 tools in your stack that you are shoehorning, things are more likely to break in the future.

- Things should still work in 10 years with minimal updates. Lindy effect. Bet on older tools if possible as they are more likely to be around and maintained.

- Good enough vs optimal: stop trying to find the perfect tech. Web tech is sometimes messy and imperfect. Opinion over what is right changes.

> I think the concept of JSX (write your HTML with JS) is good as it gives you a real language instead of a restricted templating DSL.

I never got this reasoning. In Vue the idea is:

* Write html templates in HTML

* Call javascript from the template to do javascript things (i.e. computed properties and methods)

This has always made the most sense to me, conceptually.

Sure Vue gives you a DSL for looping template elements (v-for) or showing template elements (v-if), but almost all the typical javascript action happens inside typical javascript calls.

JSX shines if you use TS. Mostly because tsx has excellent code completion, type checking and refactoring tools.

It eliminates entire classes of human errors.

I’m keen on this approach for my next project.

Can you share any Dockerfiles / scripts you use to get going with this?

Sorry I do not, although I have been meaning to publish the "skeleton" template repo's I have locally.

There are two template repos I use: `web-ui` and `server`

The both have a `sh` dir with common commands in .sh files (watch tailwind, watch esbuild, browsersync to serve and live reload during dev).

You config Google Container Linux with a `cloud-config.yaml`, which can take a bit of time to tailor at first, but after that every project uses the same config with small changes. I use Caddy to terminate HTTPS (it will auto generate and renew certs).

If you have a contact I can message you when I put them on Github.

Interesting. Thanks for the tips. I’m ccorcos@gmail — would appreciate the notification when/if you put on GitHub. Thanks!

What do you use for auth?

Just a normal create-user/login form. Or Firebase Auth if Google and other sign in's need to be supported.

In the former case, are you managing signups, password resets...?

Yes, I write those parts myself.

> What would be your stack if you are building an MVP today?

Many years ago a CIO told me he didn't really care what technologies I picked for an upcoming MVP backend, as long as I was already comfortable with them and would therefore be productive quickly.

He also told me we would almost certainly need to rewrite everything at least once, so not to dwell too long on the initial stuff.

Build the MVP, build it quickly, get it in front of users. It just needs to work, you're not going to get marks, or customers, for backend coding style.

    He also told me we would almost certainly need to 
    rewrite everything at least once, so not to dwell too 
    long on the initial stuff.

    Build the MVP, build it quickly, get it in front of users. 
    It just needs to work, you're not going to get marks, or 
    customers, for backend coding style. 

Stakeholders and managers want you to keep adding incremental features. Never had a situation where they were like "okay, cool MVP, see you in a few months after you tear it down and rebuild it 'for real'."

That "build a fast crappy MVP" mentality takes serious buy in from stakeholders from day one. That mentality might be common in SV and other startup communities but boy is it tough to find elsewhere.

Agreed, but it is also easy to see the tension in your second paragraph. You can plan to rewrite everything at least once, but you will never get that actually in the plan.

My only somewhat clear path out of it is to make sure you built it so it will be easy to rewrite. Either do the least that you can, or keep an eye for improvements, but don't necessarily act on them.

That CIO is brilliant. That's the kind of wisdom you get with experience. Always good when stakeholders ask for additional features because the MVP isn't completely throw-away and then my team doesn't know the language. Then they learn the language, but we need to hire new devs and grow, and no one in the market knows the language. I always tell the new hires that we have a lot of learning opportunities - Go, Ruby, Python, Elixir - you name it. All the fresh college grads can't wait to jump in and contribute within 2 hours of getting hired. My grand-grand father always said "If you can't pick up a new language in a day, you aren't a good programmer and don't belong on Hacker News." He also said using C#/Java/Python is "sus booomer ** fr".

This is excellent advice. The "worse is better" manifesto says similarly:

> The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads.

https://www.dreamsongs.com/RiseOfWorseIsBetter.html

I would pick whichever stack that I would be most productive in.

A Laravel app hosted with Laravel Vapor (AWS Lambda) with a MariaDB database. Would allow me to get up and running quickly, at low cost and without having to worry about scaling for a long time.

Using Tailwind and VueJS or AlpineJS for the frontend.

This. Your fastest stack is not my fastest stack. If you want to learn the ‘fastest’ frameworks, that is a totally different decision than getting an MVP out the door. That is an educational one… which is totally valid just not in an MVP sense.

The goal of the MVP is ascertaining product market fit, everything else is waste. Use what you know and optimize later. If your MVP can handle 1m calls a second, you have failed (unless it was natively supported by the framework)

I think it's a very reductive view. One cannot try every stack to find its fastest stack. This is why people ask about other people's experiences. Someone might have a better solution, and a convincing argument, so you could try it and become more productive.

I have a relatively terrible answer that I would recommend to no one but it works for me. That's the fastest stack for me.

The question wasn't "what is the fastest stack" or "of all stacks which is the fastest for you" but rather akin to "what is the fastest stack for you". Which is often the one that you are productive in.

It's almost always not worth learning a new stack to prototype something unless the goal is to learn the new stack.

That’s usually my take, but I still worry about a few things:

* which stack will still be around in 1/2/5years?

* which stack Will other teammates or future devs be productive in.

I’m still searching for a very light, productive open source stack that is well accepted and if not future proof at least we’ll backed.

For an MVP, none of those things matter. Just rewrite it in a different stack later if you realize that the one you picked doesn't fit your requirements long-term. Worrying about that stuff before you have users/customers is just a waste of time and energy.

But does that really happen? It seems that we have a lot of bloated, buggy, inefficient code out there because it was initially built using something that was 'quick and dirty' for the MVP and was never rewritten properly once it caught on.

I have clients that still use Excel spreadsheets for their database instead of using a real one just because their data was initially stored there and they never changed. New features were added incrementally over time and it became costly to break everything for a complete rewrite. So they limp along forever because management won't let them do it right until it absolutely breaks.

Yeah, it's definitely a cultural shift from the way most software is built today, but it's a better way to do it in most cases. I was also assuming a startup environment in my comment; established companies can generally afford to do more work up front to make the foundation more robust, and they are (slightly) more likely to have a better idea of what their customers want ahead of time.

But to answer your question more directly, it does happen, it's just uncommon. Where I've seen it done successfully, the rewrites have been piecemeal, not all at once, so that definitely helps with the buy-in factor.

you should check out https://wasp-lang.dev then. It's probably one of the fastest stacks out there for React + ExpressJS at the moment

It really depends upon the product, right?

Let's assume we're talking about a web-based business app.

If the MVP already requires some complex business logic, then I'd probably choose an old-school stack. I personally prefer Rails. But I'd probably pick .NET. Above all, my metro area is full of .NET people. It'd be much easier to find/hire collaborators in .NET. I'm comfortable and productive enough with .NET on the technical level.

However! If I could get away with just putting up a couple Lambda functions, then that's absolutely the path I'd choose. It's an MVP. Let's get this boat rowing ASAP!

In short, product and market influence the best technical approach.

Elixir, Phoenix, LiveView + Postgres

Main reasons are:

- Can build entire app (with SPA-type experience on the FE) in a single codebase

- No need to build any HTTP APIs

- Periodic tasks and managing in-memory state is super easy in Elixir. Eventually you might want to stick state somewhere which survives restarts (eg redis) but for the sake of moving quickly Elixir makes this really easy

- Newer versions of Phoenix/LiveView support html components so building out UIs now feels as nice as some of the tools in the FE ecosystem

I like Phoenix/LiveView so it's a nice option.

But I'd probably choose Blazor over it as every one of those bullet points also apply to it, it's C# (with which I'm very familiar), and if it takes off there are masses of devs available in most markets as opposed to handfuls currently for Elixir/Phoenix.

Coupled with something like DO droplets and SQLite/Postgres.

I have no experience with either (though I have perused some Elixir docs a while ago). I'd much rather jump into a Phoenix/Elixir project though, just based on what I've heard and know about it.

I wouldn't apply to a C# job, I have no interest in it.

I think the only disadvantage is really that Elixir devs would be newer to Elixir. But I think the applicant pool would skew towards having broader experience.

Depending on your use case you could consider using SQLite. For example storing auth info in a central database and then having one database per customer.

I built Call Stacking ( https://callstacking.com/ ), a modern Ruby on Rails debugger, with Jumpstart Pro and 1.5 hours a night over the course of 4 months.

We have four kids, host an exchange student, a new puppy. Our schedules are full.

Nothing compares to the productivity of Ruby on Rails. Especially when coupled with a high-end template like Jumpstart Pro ( https://jumpstartrails.com/ ).

I used something similar ( https://bullettrain.co/ ) in the past. Have you taken a look at that? Bullet train used to charge but now are apparently open source.

I haven't personally used it, but it looks like a really solid choice as well.

I know of Andrew Culver through Twitter and he seems like a genuinely nice person.

Next time check out Avo. It integrates perfectly with Jumpstart (or any Rails app) and helps you create a back-office app in no-time.

https://avohq.io

I've checked out Avo several times before. I don't need it quite yet.

It looks beautiful Adrian.

When I click examples why don't I see code?

I’ve been working on a side project that aims to provide a really simple UX to spin up full-stack web apps with CI and scalable infra by default. The idea is that you would simply enter a domain name you want to purchase and then the tool would do the following:

1. Purchase the domain name using AWS Route53 (perhaps you’d need to setup an IAM role for the website to access your pre existing AWS acct)

2. Setup frontend, API, and CDK infra repos. All in TypeScript.

3. Frontend react, backend Api gateway backed by lambda functions. Have a graphql endpoint that talks to an Amazon auroradb. CI for backend and frontend is defined by a CDK package that is also deployed to the AWS account that also sets up the networking and database for you.

4. Have a basic layer of application code for setting up user authentication and storing user data in the aurora db.

Basically my idea is it kinda sucks that everyone has to do all of this setup yourself if you want to start a new project. Or you have to rely on no-code tools like Squarespace etc which may not be what most engineers are looking for. Having something that can go from simply entering the domain name you want to scaffolding out a fully functional full stack web app with CI and serverless infra defined by code that can scale from day 1 seems both incredibly useful and doable.

Curious to hear other people’s thoughts on this!

Neat, I am working on something similar with almost all the same tech you mentioned (CDK, R53, TS, APIGW+Lambda), and a Dockerized dev env with everything set up. It's meant to be a boilerplate I copy for new side projects. DM me on twitter (same username) if you'd like to compare notes or collaborate.

Hey sourdesi, this is _exactly_ my stack too, and I am also dabbling with a starter. Would also love to discuss and collaborate. Please send me an email (see profile).

Rails on postgres with React in the frontend is my default swiss army knife. I know Rails well and it still gets stuff done fast, comparatively speaking. If the problem space I work in requires something different or solves the problem better than Rails, I'd switch.

Edit: post-mvp, I'd stick with Rails still unless there are specific difficulties with it. But I've yet to have major issues building a large Rails team/project, including present day.

If it is a SaaS 100% Ruby on Rails

Why:

- has almost everything that I need usually in mature gems - battle tested in production

- speed of development

I did so last year, and I cannot be happier. My only regret is that I wasn't aware of htmx/hotwire at the time. I went with Vue, and I regret it immensely.

Rails is the fastest development platform I've tried so far, it is predictable, well crafted, structured yet flexible. You can't go wrong with it.

Every now and then I try something new on a side project or I have to work on some other codebase for my customers, and nothing so far has tempted me to move out of rails for my serious projects

I'm using Laravel with Hotwire and it's fantastic. Now I want to cry every time I see the mess of overengineering I have to deal with in other projects when they're built with Redux, React, etc, etc.

Why Hotwire instead of Livewire if i may ask?

Mostly due to Turbo transitions between pages and being able to persist elements across pages. I know Livewire V3 will solve this but at the time we took the decision it wasn't available.

Also something brought up was a conversation regarding Alpine vs Stimulus. At first sight Alpine looked a lot easier, but Stimulus seemed it would scale better and be easier to maintain at the end, plus we expected it to have less problems with Turbo than Alpine given those were made to work together.

An important difference we found, is that Stimulus can "react" to value changes (https://stimulus.hotwired.dev/reference/values) while with Alpine it was not clear how a component, or some external code would trigger an update by changing a "prop" or an "attribute" of the element. We know we could use stores and events, etc but that's what I meant with stimulus being easier to scale long term.

Interesting. I had the feeling that framework like that has to be so tied to the backend framework that Hotwire has to have lots of troubles outside Rails. I would have never even thought of trying Hotwire with Laravel. Will try. Thanks

Yes, that was my initial impression years ago too.

But it's very progressive. For example, you can just use Turbo to get the "SPA like" navigation between pages (no full page reloads) and that's for free, just including it will bring in that behaviour, plus caching when navigating back, link preloading (so when you click the content it's already there), etc. All of this very easy to control/configure via html data attributes.

Integrating the "Turbo frames" feature is also pretty easy, just wrap content in <turbo-frame> custom tags and the library will do the replacement without page reloads when you submit a form. Similar situation with "Turbo stream", etc.

This is an excerpt from the main documentation site at https://turbo.hotwired.dev/handbook/introduction :

"...You don’t need any backend framework to use Turbo. All the features are built to be used directly, without further abstractions. But if you have the opportunity to use a backend framework that’s integrated with Turbo, you’ll find life a lot simpler. We’ve created a reference implementation for such an integration for Ruby on Rails...."

Same story with Stimulus. You can add it to any framework, it's just a frontend library.

Having said that, there are some "helpers" that you can have in the backend that will make things more idiomatic and avoid some boilerplate, etc. And Laravel being such an amazing framework with such a great community, has a great integration library here: https://github.com/tonysm/turbo-laravel

I couldn't be happier with this stack. With Laravel + Hotwire + Tailwind + Laracasts I feel I'm unstoppable.

I'm vaguely aware of htmx, but have never used it. Had not heard of hotwire until just now, but that looks really interesting. Thanks for the pointer!

Would you care to say any more about your experience with Vue? I've heard a lot of good things about Vue and had it on my mental "things to learn one day" list for a while. Would be really interested in hearing any counter-points from somebody who hasn't enjoyed working with it.

I'm not sure what their particular beef with Vue is but I've been using it for several years now with Rails and its mostly been great.

They had a similar issue as Python, albeit not nearly as bad, with their upgrade from version 2 to 3. It required some rewriting. They also introduced a new core concept with the "composition" API, which completely changes the way Vue apps are written. Luckily once you made a few required changes you could continue writing apps like you used to, ignoring the new composition API. I'm assuming at some point we'll be forced to change, which will suck.

One thing we do, which I don't think is as common when using Rails with a heavy frontend like Vue or React, is that Rails is not in API mode. That is Rails still handles routing, pages are still rendered in ERB, and then each page is its own little Vue app. So we can use Rails, Ruby, etc to initially hydrate the pages and inject stuff by calling to_json on it. This also means we can let Rails and Devise handle login and session, which I absolutely hate doing with a pure JS frontend.

Routing and session management are something I think Rails is extremely good with. This also means that if a section or sections of the site are pretty simple (password reset for instance) we can just render the page in ERB, no JS required.

Regardless, I still like Vue and it has a pretty decent ecosystem. If I had to go back and start again I'd probably just go with React. It clearly has the most support (and most jobs) on the front end.

First I heard of HOTWIRE. I have been using PJAX for a decade now, which is a similar concept.

I use .net mvc with a razor templating engine. But this can be used with any backend.

It makes it super easy for me to maintain all my UX in server-rendered HTML templates. I get a clean SPA with super high development efficiency with MINIMAL javascript.

The best part was I could hire any developer and they know how to work in basic HTML/JS/CSS.

Edit: Reading more, I might need to spend time looking into HTMX/Hotwire as a replacement for PJAX at some point.

I love Hotwire and it's reinvigorated my love of Rails.

Check out also Unpoly. It’s probably the most “batteries included” of this kind of tools, although not as popular.

Can you expand further?

What has you bother to introduce unpoly when Hotwire is included by default? Aka, what are the main things missing/better that drive you to use unpoly.

I was replying to @moxplod because it seems they didn't know about these alternatives to pjax. They're mentioning HTMX, etc so I've added Unpoly to the list of similar things.

I'm not saying you should replace Hotwire with anything else - I wouldn't do it given it's the default or defacto solution.

But all of these tools (pjax, htmx, unpoly and hotwire) work perfectly well outside of Rails too. So if you're not using Rails and you're, for example, using Django which doesn't have a default solution then you can pick one of them, and I think Unpoly is a very nice one.

Worth looking into Hotwire. It works well with .NET MVC.

IMHO, part of this is that people have accepted the poor experience of non-realtime applications. But there's a huge UX improvement if the application responds faster than users can input actions. Doesn't matter for all applications but if your users are going to spend significant time inputting data it makes a huge difference.

Also IMHO, a flexible type system like Typescript makes development faster than without it. You can refactor faster, it catches silly mistakes, and you don't have to write as many tests.

Rails does a lot of great things for you, but IMHO ultimately it's stuff you don't really need. If there's any chance that the application will grow beyond a few developers I think it hurts more than it helps.

>If there's any chance that the application will grow beyond a few developers I think it hurts more than it helps.

Simply not true.

I've consulted on multiple teams across products built with Rails. Products that supported hundreds of millions of requests and generated a similar levels of revenue.

Rails scales - programmer productivity, traffic. It scales.

One thing I've taken to pointing out, and it seems like you have way more experience with which to back it up - is that it's not just about scaling to millions, it's also about scaling from zero.

Thoughts? :)

>Simply not true.

It's not true that I think it hurts more than it helps?

> part of this is that people have accepted the poor experience of non-realtime applications

my experience has taught me the exact opposite: people have accepted the poor experience of real time applications (client side crashes that bring down the entire page, half-baked routing that is essentially just rebuilding the browser navigator, inconsistent client vs server rendering processes). developers tend to completely stick their head in the sand when these issues are occurring. there's complete classes of problems that simply go away when you're not building an SPA.

> Also IMHO, a flexible type system like Typescript makes development faster than without it. You can refactor faster

in the long run, yes, but in the short term you're probably not going to get your mvp out faster because you chose TS

> people have accepted the poor experience of real time applications (client side crashes that bring down the entire page, half-baked routing that is essentially just rebuilding the browser navigator, inconsistent client vs server rendering processes).

People complain about that stuff all the time.

>stick their head in the sand when these issues are occurring. there's complete classes of problems that simply go away when you're not building an SPA.

Well, yes. If you don't actually build a real time application you won't get the benefits of a real time application.

>in the long run, yes, but in the short term you're probably not going to get your mvp out faster because you chose TS

Once there's even a moderate level of complexity (i.e. 2-5 devs for 1+ months) the type system helps you catch issues. Even if it only saves you one 4 hour debugging session you come out ahead.

That assumes you sit down and write out your MVP without any significant refactoring. If you do have to make changes then TS will save you significant time there.

It also assumes that you're not writing tests that duplicate what a type system does. If you do write those tests then again I think you're slower.

Rails does have the advantage of there generally being one "Rails way" of doing things. That can short circuit a lot of design discussions and other sorts of bikeshedding. But you can also just not do that and, IMHO, come out better.

> Well, yes. If you don't actually build a real time application you won't get the benefits of a real time application

A rails application can be just as "real time" as any SPA, I don't think that definition really means anything. You get a distinct set of problems that come with SPA's that don't exist in a traditional server side rendered app that have nothing to do with how "real time" the app feels.

with hotwire you get the benefit of having that SPA with quick responsiveness but with the much, much reduced complexity in stack with all the jankiness that that brings with it.

I used svelte and it's been super simple and efficient.

Which gems do you most commonly use?

.NET 7 & SQLite.

Because I wouldn't need anything else.

Also, it could potentially be my final stack depending on the size of my business & market. The current Kestrel web server implementation is extraordinarily fast (i.e. millions of requests per second fast). Vertical scaling isn't exactly a problem now that we have 2S servers with 256 cores (and beyond).

Have you found any good managed places to deploy modern .NET apps other than Azure? My experience is you can either use Azure, in which it's fairly abstracted for you but overpriced, or you can use something like DO where it's more reasonably priced but you have to handle everything yourself.

Just for clarity for others passing through this thread ...

Current .NET produces stand-alone cross-platform executables just like many other stacks.

Unless you're forced to do legacy stuff, there is no Framework any more, and no Windows or IIS needed. They build and deploy exactly like other ecosystem executables because that's exactly what they are. You can even generate a Linux server build from Windows and MacOS. And it also works fine with standard container stuff.

By default a .NET web app or API is a stand-alone server, with optional https built in, and you can either sit it behind a proxy like nginx or you can direct traffic straight at it. In summary, forget all the old stuff about frameworks, Windows, and IIS. If you're doing your own project and not working legacy stuff you don't need any of it.

Fly.io works great. .NET will generate the Dockerfile for you already so it's pretty easy to set it up. Fly.io will even give you a hosted PostgreSQL.

DigitalOcean's App Platform should also handle .NET apps as easily as anything else.

.NET makes it easy to get your app all set for Docker and there's a lot of platforms that will take Docker containers or even build them from your repository.

I guess I'm wondering what managed services for other languages feel more managed/easy than Fly.io or DO's App Platform taking your repository, building it, and launching it.

I think we need to be super precise when we use the word "managed". Today, we use EC2/Azure VMs to run a lot of .NET 6+ apps. I consider these to be managed resources. My involvement with those servers is an email from the hypervisor ~once a year politely requesting a reboot.

I don't think .NET has any specific implications regarding where the product is hosted. If you are referring to the Microsoft insight/Azure integration crap, we use 0% of that.

That's basically what I mean. I just want to deploy the app and not have to worry about anything OS-related, including IIS config, SSL, etc.

That's exactly what I do - I build a monolith using the self-contained deployment feature and zip it up to the server to run.

The management of certificates, configuration, etc. is built directly into any product I work on. Outsourcing this stuff to IIS, et. al. is exactly how you wind up hating all of this tech in the first place.

Prerequisites are zero if you do this right. I can take a blank EC2 server, copy the binaries over and run them immediately. I don't even have to install any runtimes or SDKs.

How do you setup your webserver. This is the most challenging part for me.

Here's my process. Build locally, publish, upload to server, dotnet run... Now what?

Modern .NET contains the web server. It's not an external thing anymore. You include a .NET library to host your stuff. Check out the minimal api reference:

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/s...

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...

Literally everything runs inside your process now, including the database if you go for SQLite.

C# is heavily influenced by golang now. Run with 0 dependencies. Web server bundled.

> C# is heavily influenced by golang now

Source ?

Looks like you can run containerized .NET apps via GCP Cloud Run

https://cloud.google.com/run/docs/fit-for-run

This is what I do.

* CloudRun - .NET in Docker * CloudSQL - Managed Postgres

AWS has been aggressive in .NET support in the last couple of years: https://aws.amazon.com/developer/language/net/

I'm still building personal stuff in the style of "1. Old schoolish".

I'll use a VPS or host it on the Raspberry Pi in my bedroom[1]. I use these primarily because I'm worried about price complexity at cloud providers.

I use a mix of languages for personal stuff and I'm finding Go quite addictive at the moment. I rarely use a framework and base most of my MVP's on the simple Neat CSS framework[2] I created for that purpose. I like to keep stuff light.

I've started to create some live coding style video's[3] of myself doing these projects with a goal of setting a schedule for myself and an ultimate goal of creating a micro business.

1. https://joeldare.com/private-analtyics-and-my-raspberry-pi-4...

2. https://neat.joeldare.com

3. https://www.youtube.com/codazoda

Rails if I want a database, Sinatra if I don't.

Ruby just... wants you to be happy while you're using it. And in the long run of life, that matters.

Python wants to be correct, Java wants you to not make mistakes, JS is still figuring itself out, Scala wants to do hard things...

Ruby wants you to be happy.

IMO - There's a lot of very worthwhile follow-on effects of that - everything from libraries (generally) being just that much easier to get going with, to lower-stress teams having better communication, to debates instead of fights (I'm looking at you, PEP572). Ruby is nice so we are nice :)

I was a Rails, Sinatra, Ruby dev for years and I’ve been work with Go for years too. I’m struggling to understand your perspective because I’m no less happy coding in Go.

I've only done a bit of Go. I liked some of the ideas that were present, but ultimately (and I believe explicitly) Go has computer-sciencey-correctness goals (hence all the kerfluffle over generics) that, now and again, trip things up.

Sometimes that's really nice - we had a handful of tiny utilities written in Go, like a format converter for use in a datastream - other times it gets in the way. I don't think I'd want to code up something large in Go, although it's not something I've had the opportunity to try.

AFAICT, Go believes in preventing you from making certain mistakes. And usually, within it's context and paradigm, it's correct to do so. The problems arise when your problem domain doesn't line up well with that context and/or paradigm, which sometimes just comes down to the time you can spend on the issue.

Another example: IMHO, all the weird issues Go was having working out how to do package management stems from some (admittedly very cool) ideas about Correct And Proper Package Management. I can't remember the last time I had an issue with gem management / bundler (except for the perennially awkward PG gem issue).

It's a 85% vs 95% thing, and IMO that straight-up comes from having other priorities. There's a lot of overlap between "developer happiness" and "computational correctness", but it's not exact, and that comes up in few, but enough, places.

Maybe another good example is Ruby array arithmetic. It makes no bloody sense from a math/CS perspective, but goddamn it is handy in applications. So if your language is aiming for computational correctness, you're not going to get that tiny bit of joy.

> Go has computer-sciencey-correctness goals (hence all the kerfluffle over generics)

I really don't understand this. The debate over generics had nothing to do with "computer sciencey correctness" goals, they had to do with ergonomics. Of course, from Ruby, the idea of typing your code is completely foreign, but imagine if a function only allowed one type of parameter, and if you wanted another you had to define it again with a different name.

Basically like allowing flexible parameters makes function definitions more flexible, a lot like all the metaprogramming business in Ruby

> the idea of typing your code is completely foreign

I don't understand this?

> I really don't understand [Go has computer-sciencey-correctness goals]

My impression (way back when, TBH when Go was first announced and discussed) was that the language creators had some Very Strong Ideas about how to do various things 'much more correctly', and/or to avoid specific pain-points they'd had in other languages, and that those things informed a lot of the decisions about Golang; in particular the module system, generics, and error handling.

I'm calling that "computer-sciencey-correctness goals", perhaps incorrectly, as I also got the impression their goals and methods were heavily informed by CS research into computer languages.

No I don't necessarily disagree about Go, I just don't understand what generics have to do with that.

Are you suggesting generics were divisive because computer science-y people didn't want them or wanted them the best way?

Every language has goals. Many of them explicitly state those goals.

1. https://the-zen-of-go.netlify.app/ 2. https://peps.python.org/pep-0020/ 3. https://thethreevirtues.com/ (perl, arguably) 4. https://rubyonrails.org/doctrine

You will end up sacrificing other things in favor of your principles. Other languages sacrifice developer happiness for theirs. Ruby sacrifices other things in favor of developer happiness.

That's it. Everything else is [my] speculation about why people chose their particular principles.

Citation note: I've always heard that "Developer Happiness" is a thing from Matz (Ruby's language creator), but the only place I'm finding it explicitly stated is in the Rails doctrine.

I'm currently approaching MVP / ready to pitch stage on something and these are my choices-

Rails 7.1 w/ Tailwind (esbuild, not import maps) Postgres DaisyUI for Tailwind UI components View Components for Ruby Nothing particularly "hot" but there are some newer tools

Post MVP, the only thing I'm looking to change is potentially replace a very heavy data analytic background job with a Crystal version of it. Will be super easy to port, and since I'm using Sidekiq, I'll drop in Sidekiq.cr and thus won't need to make any other system changes.

I'm thrilled about it, it's taken a month to go from zero to everything working and I'm just tidying up the marketing site

Sounds great. Curious, what did you use for auth?

I'm using Devise. It's rock solid and goes along with a general sense of "use trusted solutions" for me. I will be adding Omniauth and the Devise plugin for it, but that will be the extent of what I need in the future.

Django/Postgres/htmx(for interactivity) . I was able to release aipaintr.com in 3 weeks working 2-3 hours daily.

All the new fangled frontend technologies make me dizzy :). On top of that this is my fist project in django.

There is a nice django starter oss project called djangox which takes care most of the integration out of the box.

For a new project the complexity should be on the marketing stack. Choosing a good tech stack is a distraction. Choose something that will allow you to create MVP fast and then start marketing.

djangox definitely looks a bit less opinionated and lighter weight than what I normally use for a starter project, which is cookiecutter-django: https://github.com/cookiecutter/cookiecutter-django

It seems to include most everything that djangox does, and a little bit more, and with cookiecutter's setup process, you can strip out much of what you don't want/need.

elixir/phoenix is the best platform for knocking out an MVP today. Its batteries included and has a frontend system called liveview that lets you write most of your frontend using elixir too. You get built in pubsub and websockets which are important for any new kind of software product. Users demand more interactivity and phoenix lets you do it and scale from day 1. Ecto is easily the best sql database library I've ever worked with. Its comparable to linq only it is uses elixir macros so its just a library.

1. you get a lot of out of the box rails like glue jsut like rails or django but the runtime perf is way faster. you can get away without even using caching in prod for awhile

2. supabase is written in elixir

3. lambda could functiosn have their place but loc you in to a cloud provider. I can move my elixir mvps accross providers with no issue and I won't get any surprise bills.

I love elixir/phoenix and wish I could use them in prod for my job, but...

> pubsub and websockets which are important for any new kind of software product

... not really. By far most people (probably by a huge margin) are doing fine building 1000s of new products per week without either those things.

Further I think you are right.

Holy smokes! I had no idea this project existed, and it just solves so many issues out of the box.

I'm a backend/infra developer, and I had been dreading having to learn a new front end framework because the work flows just look hideous. This looks like I can sidestep most of that problem entirely.

phoenix has been the inspiration for a lot of stuff comming out of the other frameworks.

phoneix channels -> django channels and actvecable but phoenix's version is much more powerful

liveview -> livewire, hotwire. both are copies of liveview but neither of them are as powerful since only liveview can spinup a persistent thread PER user allowing active stateful sessions that can push and recieve events from the client.

Not claiming LiveView is not most powerful (probably is because erlang is most suited to this). But saying that Livewire or Hotwire are copies is not fair at all. I am not sure why they are named in so similar way but they are all green field projects.

Livewire has started at pretty much same time as LiveView and AFAIK both projects influenced each other over the years. Both authors are in contact and the frameworks are quite a bit different because Livewire (in PHP) does everything over http so it has to employ different tactics than LiveView that can run over websockets.

Hotwire on the other hand is from Basecamp who have been using this approach forever. They just packaged their experience into a framework they released. Theoretically hotwire is the oldest of the three.

I am saying this because i don't think you need to use LiveView. All of them are super productive and are used for many real projects. They are just a bit different and better at different things.

Phoenix is super pleasant to work with, very few surprises.

1. FastAPI (Python) or Axum (Rust) for back-end, deployed on Fly.io.

2. Supabase for Postgres and Authentication.

3. Astro as a framework for front-end, deployed on Vercel, running in Hybrid mode.

With all of these in-place, I can extend my existing components to accommodate any needs. It scales very well in the beginning as I move very fast, and anecdotally scales very well regardless of size.

The only missing parts here is support for timed jobs, but that can probably be done with Fly.io machines in the future.

I am building one now as a single founder, with plans to never grow beyond a few people, and I'm using Clojure + Postgres (having done Python for almost 20 years!). I do technical due diligence for private equity companies for a living, and I evaluated two Clojure companies. It was amazing how much they could avoid in terms of problems as a small team by leveraging the JVMs concurrency and threading capabilities. No worrying about microservices, managing crazy k8 systems, or complex CQRS problems, no outgrowing pokey ORMs (a problem I have talked to way too many mid stage companies about who started on Rails or Django - huge elephant in the room there). I intend to use a mix of HTMX, some Reframe (a clojurescript reactive framework over react) and webassembly on the front end.

Clojure's not the easiest thing to get into, the stability and documentation and libraries are great.

Clojure is something i really want to learn and work with. The people using it on projects seem at another level of productivity.

I'd go full stack Rails with Turbo and Postgres DB. As things grow, you can easily migrate your Rails app towards a JSON API layer and create new clients to interact with it either with your favorite JS framework or mobile app. I just love how quickly you can churn out new features in Rails -- or how easy it is to implement things like authentication or an admin panel by simply adding a gem.

Go & Postgres on the backend, running on a baremetal server.

Because this is actually capable of handling a decent workload for really cheap compared to cloud.

There's a few tricky bits to do with logs and reporting, but the benefits outweigh the pain.

Vue on the frontend.

Last time I used BootstrapVue and it worked well. I'd want to re-evaluate that decision next time, have a look at some of the newcomers. I'm aware Bootstrap is now considered to be passe.

I really like the Vue philosophy and it pairs with Go nicely. Last time I ended up using ESBuild to actually build the Vue bundles from inside the Go server, which was interesting but I'm not sure I'd do that again.

I'm of a similar philosophy, but also because I'm not beholden to rushing a minimally viable product to the feet of some angel investors (Super allergic to that after a few experiences). I mean it's kind a a premature optimization if you just need to get a working example out there for people who like to see fast results, but if you've got the funding to start your own company just writing it properly for performance from the get go is the obvious thing to do.

I also choose a stack like that because it's what I've been mostly working in for a long while now and it's really productive (For me).

yeah, I get the same - I'm probably not going to get something up as fast as I would if I used Rails (though it's probably close - I've built so many sites on this stack that I know all the pitfalls and have a lot of the boilerplate down to copypasta now).

But this backbone can take a lot of experimenting with features easily, and is fast enough to forgive a lot of sins - I generally just don't have to worry/think about performance at all.

This is the correct answer. It's quite shocking how many Django and Laravel answers there are in this thread. Performance and type safety appear to be completely irrelevant to HN.

You should take a look at Vite (https://vitejs.dev/) for a Vue development environment, if you haven't already.

> This is the correct answer. It's quite shocking how many Django and Laravel answers there are in this thread. Performance and type safety appear to be completely irrelevant to HN.

I was wondering about that actually.

Writing code in Python, Rails, etc is painful. A stupidly high percentage of the "unit tests" aren't testing logic at all, they're simply ensuring that incorrect types are handled properly.

And then I see comments like "well, my MVP can run very cheaply, a $100/m DO droplet" and wonder what on earth they are talking about - I had a $5/m DO droplet handling around 50k-60k concurrent TCP (not HTTP) connections, all serving data without any of the connecting devices timing out.

The devspeed differential between things like C#/Java/Go and Python/PHP/Ruby is large only at the very beginning of your project. When you're adding new features in every day, six months into the project, you're almost definitely going to be faster in some statically typed compiled language.

Seriously, using Django is likely to shave a week or so off the time; if that week matters so much then your expected lifetime for the product is what? Two weeks? Three?

I get it, in that if your MVP is timeboxed to (say) two weeks to alpha, then, yeah, those things that shave a week off make sense. But if your MVP is timeboxed to two weeks:

a) Tt's unlikely to be of much value to the consumer, b) Your competitors will appear two weeks after you first launch anyway.

I want to do a new product, and when judging each product idea I have, the largest issue is always finding the largest amount of value I can create/deliver in a particular timeframe (say, 3 months f/time).

If the value the product is providing can be done in a week with Rails, then there's not much motivation for me to develop that product - everyone with a week of leave or a month of weekends is going to have a clone out before I can even learn marketing.

If it's going to take 3 months regardless of the language, I have at least 3 months to build up a userbase, and do product refinement and fit.

> The devspeed differential between things like C#/Java/Go and Python/PHP/Ruby is large only at the very beginning of your project.

That's a massive hard-no for me. I generally only get faster the longer I get to work with a Ruby codebase, as I get to make it more and more into a DSL for the business situation. I never saw that happen with compiled languages; my speed tended to remain constant after the initial boot.

I know what you're talking about tho - it's the sharp knives + large team problem. The language doesn't maintain a standard of code for you, you (and your team) have to do that yourselves, and if you don't, things can very much get bad. If you're programming in a loosely typed language such that you're effectively having an explosion of types, you're suffering one of the more common downsides to typed languages and you're not using the common upsides to loose typing.

That said - when I'm working, the main difference I've seen with Ruby (and, to a lesser extent Python and JS) vs compiled is the iteration loop, particularly due to having a REPL console. Static languages have definitely made some gains there (looking at you, Scala REPL). Being able to drop into both any debug point in the program, as well as a console loaded with your code, makes certain explorative processes substantially faster.

I do wish for a Go REPL. I use tests for this - write exploratory code in tests, and then move it to the actual package when I'm happy with it, which isn't nearly as satisfying or fast. But again, the gains of coding in Go outweigh the costs (for me, I'm aware other people don't find the same).

I'm doing mostly the same; one difference is that I know structure my test code and implementation code so that I start the test in the debugger and use watch expressions as a primitive REPL.

    call dbl.tbl_create(....)

No, it’s not, because we’re talking about an mvp and not about building an ultra high performance micro service.

And btw, there is no “correct answer” despite how much you like it.

There are many “correct answers” and a lot more wrong ones. Like using assembly code for building a CLI app or Go for an MVP.

thanks for the tip, I'll check it out :)

Build with what you know, that way you'll be focusing on just building what your customers are asking for, and not also having to learn the technology as you build.

Exactly. If one were to look at my top-level reply here and ask "why?" for any item I listed, in basically every case the answer would be "It works, and I know it." I could get more done faster using that stack than a stack I'd have to learn from scratch.

That said, there's a time and place for experimenting and learning new stuff. And I am interested in trying Elixir at some point. But to "get stuff done" in the near term? Yeah, it's going to be mostly Java/Groovy, Grails, and some Javascript. Hell, I might even break out jQuery just out of sheer familiarity, if I got stuck doing something using vanilla JS.

I'm going to buck the (numerous) trends here and keep it simple at the same time.

C# REST APIs on Linux with PostgreSQL and the front-end framework of your choice. I generally stick with Angular.

Same (but I use F#)!

I find .NET to be great for backends though maybe not as great for frontends (there's just better stuff out there). So I use the best tool for the job and that typically means using something else for frontend.

Right now I use SvelteKit for frontend.

I use the exact stack. I even develop on Linux using Rider. :)

There is only one good answer to that, you should use what you already know, if you build an MVP it's to deliver a product, it's not meant to spend 2-3x more time to learn new tech.

I'll add an anecdote to contradict that argument:

I work in embedded, and the place I work restructured to have a dedicated software group. They hired young software engineers and focused on getting people who are good programmers without really caring what they were good at. Most people ended up being web developers and liked webstack.

We were tasked with making a handheld air quality measurement device with a touch screen that could pair with a computer app that we would also write. Most people on the team knew webstack so we decided on a HTML/CSS/JavaScript +SQLite that would run in Electron Chromium on Linux on the physical device.

So what went wrong? Well, electron is bloated for embedded devices and the mid-tier processor we were using chugged so much that it would get hot. Hot enough to affect the temperature sensors at the top of the board and throw off the gas density measurements. Our MVP was nearly done when we discovered this problem.

We had two choices: throw out the hardware or throw out the software. We ended up throwing out the software and starting over (in Winforms + C# if anyone's curious). I and two others quit as a result. It is _really_ depressing redoing something you've already done in a different language.

If we picked the lighter weight framework from the start instead of picking the language most people knew, we wouldn't have lost a year of work.

This is the most common advice around these parts, but it seems woefully misguided to me.

The “only good answer” if there is just the one is that you should use whatever fits the requirements. If those requirements involve you getting to market as fast as possible in a highly generic domain (ie building a standard website) where the tools you know work just as well as others and you’re not worried about various other factors then sure, go with what you know and can churn out the fastest.

But though many projects may fit this mold they are by no means universal requirements, and your requirements may very well dictate the best path is for you learn new tech (for instance if you usually do .NET stuff but are building a a ML service on a device or something). Sometimes there are better ways to accomplish things than what you already know and you’ll indeed be better served by learning them. If you’re just a hammer looking at everything as a nail because you can bang on it the fastest you’ll stub your (and probably others’) thumbs one way or the other.

Not to mention learning new tech is often its own reward regardless of the much less certain fate of a given MVP. At the very least you'll have another tool in the toolkit to assess future project requirements, rather than blindly attacking everything w/ a hammer.

Sure, but I suspect the motivation behind this post is specifically to learn about what people love to work with, not to be convinced about what to use for their own MVP?

At least that's the value I'm getting out of everyone's answers that actually talk about their favourite stack (vs just saying "use what you want" etc)

This is always the wrong answer to this question.

Yet it never goes out of style, apparently.

Agree

I've been writing Python for, gosh, almost 20 years now. I've used many frameworks but for an MVP I'd probably use good old web.py or Flask or similar.

Over those years I've come to greatly appreciate the wisdom of Gall's Law. I always start with an absurdly simple system, make damned sure it works, and only then complicate it.

- for edge functions cloudflare workers are currently the best mix of being modern and professional/feature rich

- nothing beats the simplicity and power of svelte for UI

- netflix falcor for state and request management, because it has the 90% of features of graphQL i need but is much simpler to reason about and i can auto generate nearly all my requests from svelte without writing queries (because falcors model matches 1:1 to POJOs and has optional schemas so prototype at lighting speed and then add schemas later as needed for reliability)

- pouchdb/couchdb because nothing beats this combination for sync and offline and low latency features

1. Laravel.

Because:

- Battle proven

- Secure

- Well maintained

- Well documented

- Fully featured (a lot more than others such as Django or Rails. Jobs, auth, asset manager, etc out of the box)

- Doesn't hate JavaScript, embraces it (hello Rails!).

- The templating system, Blade, is pretty great...you can even do components.

- Opinionated and not that many different ways to do the same thing, makes things more consistent

- Performance is good enough for 99.9% of use cases. For the other 0.01% add Octane.

- Great, friendly and professional community. Top high quality packages with lots of users and well maintained.

- Excellent frontend integration packages in case blade is not your thing: Inertia, Livewire, Hotwire, etc.

- Lots of people know it and like it, so easy to hire for too.

- Code organization makes a lot of sense to me (hello Django!)

These days with Hotwire and HTMX, you can go very far with Django/Rails (and I suppose Elixir too). Not having to write an API for your webapp to consume is huge.

Until you actually have reason to scale (eg you are building WhatsApp), building to optimize the productivity of your iteration cycle usually gives the best payoff for pre-PMF projects.

> Not having to write an API for your webapp to consume is huge.

This is something that is so understated. I use Blazor to achieve similar semantics in many .NET codebases.

The speedup you get by pulling the client state into the server is incredible. The time savings is easily measured in thousands of hours at this point. It's almost like working with old school PHP again, but you get all the 2-way stuff as well.

This is Hacker News, so why am I the first to suggest Common Lisp (SBCL) and Hunchentoot with PostgreSQL on the server? I'd default to Vue for the frontend.

I have to say, it’s pretty symptomatic of webdev to see hundreds of suggestions of solutions before having the slightest whiff of what the problem is.

Having said that, the answer is Python+SQLite.

I still use my Rails + Postgres + Heroku with various gems like omni-auth, pagination etc. I have created a shell app that is a blank website with login mechanism and basic data. Anytime I have an idea, I can spin up a site within couple of days.

I was tempted about upgrading by default stack, but after lot of wise advise here, I think it's better to stay in a stack where velocity will be high rather than wasting time in learning new things (unless that is the goal)

For a for-profit mvp my goto answer is always "the one you know", fast release matters, fast iteration, fast sales. Optimize once you got sensible sales and sensible metrics.

For personal projects, reactjs or vuejs or solidjs, tailwindcss, nodejs. Depends though, sometimes there are projects that demand the strengths of golang or rust.

The ones I know are Django and Express, but I would possibly pick up .Net if I had to build a product today.

I’m wrapping up a Python project right now and my next personal project or two are going to be .Net apps of certain ambition (users, scheduled tasks, a few tables, maybe a sprinkle of real-time) so that I have some good foundations come gametime.

For the front-end I’d pick some React flavor.

Data in PostgreSQL.

Cloud provider probably AWS because it’s the devil I know but I don’t care too much.

I'm 90% on Ruby on Rails dockerized. Meaning I would almost certainly choose that absent a very good reason to use some other backend stack. Rails because it's highly battle tested and flexible and good enough for almost anything. Dockerized because IME setting up and maintaining a Ruby environment with up to date version on bare metal is highly painful. Docker lets me be much more consistent with both Ruby versions and the rest of the server config.

I'm less solid on the deployment. Could go with one of the commercial docker-y hosting systems, or a commercial K8s setup, or a hand-rolled Docker host via Ansible. I've done all 3, and I'm not sold on any of them being the best for everything.

Front-end side is more flexible depending on the type of site/business. Normal ERB-style SSR is probably fine for a lot of things with a few sprinkles of basic JS. Would re-explore if I thought it needed a proper front-end app. React is neat, but darned if every single time I try to do a version bump on a small React app, I end up needing to rewrite half of it.

I've been pretty deep in backend engineering a while, but despite that I strongly try to use Hasura [0] whenever I can. IME backend engineering isn't a differentiator, and I've written enough REST/GraphQL endpoints/tests/blahblahblah. I think Django and Rails are amazing, but if I ever have to use them again I'll probably sigh deep and resign myself to sadness.

On top it's probably Tailwind, and if it's just me I'd use Svelte, but if it's more than just me I'd use React.

[0]: https://hasura.io

As somebody trying to learn the web stack, reading this thread makes me a little sick to my stomach.

Edit: Thanks for the advice!

Don't think about it too much. Most of the web still runs on plain old PHP and HTML. New technologies pop up every now and then but most people who do this professionally just want something that does the job and don't talk about "their stack" outside of work hours.

I've only recently come back to the world of web after doing mostly devops/backend stuff.

While getting on the JS framework treadmill might get other people hired, staying server side + Bootstrap kept me sane and productive. The only place where I spent an innovation token[0] was on htmx and so far it's been absolutely worth it.

[0]: https://boringtechnology.club

what backend do you use?

That gave me the biggest thing to think about. I had the most web experience with Django but it's been years since I used it in anger. In the meantime I'd been using FastAPI and knew enough of its warts, so I went with FastAPI + Postgres.

But if I was just starting out trying to learn a web stack like GP, I'd say absolutely don't pick FastAPI, use Django + Postgres + Bootstrap + htmx and you'll be happy.

Don't worry too much about all of the options.

Pick one stack and learn it. The concepts are all transferrable.

They're all basically the same, some are just more or less bad and some have more or fewer very-helpful libraries available. It's all doing the same shit, mostly in very similar ways.

[dead]

Svelte + Typescript & Tailwind, .NET 7, SQLite.

Why? Mainly because I'm familiar with them, and would be most productive with these.

I'd almost like to reach for Blazor, but if it's at all public-facing, I don't think I can justify using Blazor at this time.

>I'd almost like to reach for Blazor, but if it's at all public-facing, I don't think I can justify using Blazor at this time.

What are your concerns with Blazor for public facing apps?

Try navigating to the site for the Blazor material design library, MudBlazor, on a mobile browser:

https://mudblazor.com

As much as I want Blazor to work out well, those load times are too abysmal for me to seriously consider Blazor outside of internal apps.

I wonder how well mud Blazor works in a MAUI Blazor app when it's all packaged locally and compiled to native.

Probably great if I had to guess; I've also used Tailwind in a MAUI Blazor app to great effect. The only thing is: there is no DOM for MAUI Blazor components (only HTML & CSS are valid), but since Mud components work for Blazor server okay I'd imagine that wouldn't cause any issues.

Honestly I think this is where Blazor really shines: not in a web app, but as an alternative to the old XAML-based UIs - or even better, an alternative to Electron for desktop app development.

Oh wow - I thought it was broken.

Nope, just loading.

Are you building the MVP to make a product or to learn a new technology? If the former, then the stack you are most comfortable with. Let the challenges come from the product-side. If the latter, then take your pick based on the reasoning for learning something new. Be it job-opportunities, curiosity, whatever.

I'm building the MVP to make a product and get some market feedback / validation.

Then build what you know… always the fastest choice.

I agree with this. .NET isn't sexy, but I can do it in my sleep. Throw in a reasonable front end framework, and I can spend my time getting feedback and iterating. Once I need to grow and scale, I'll put more thought into the right tech for that job.

- Backend: Java - Front end: React - Persistence: MySQL and S3 - Dockerize containers for backend and front end - AWS CodeCommit for code repo - AWS CodeBuild and CodeDeploy for CI/CD - AWS ECS Fargate

Java aka Spring Boot 3.x

Linux VPS + C# + ASP NET Core

If front needed then pure js or vue

Database probably sqlite or postgres if that fits the needs

Similar to what I use.

I use .net mvc with a razor-templating engine. With pjax.

It makes it super easy for me to maintain all my UX in server-rendered HTML templates. I get a clean SPA with super high development efficiency with MINIMAL javascript.

About a year ago I took off maybe 5 months to create a ephemeral voice messaging mobile app (Android + iOS)

Stack:

- React Native + Expo - Typescript - Supabase - Vercel - Some Vercel/nextJS-ish lamda functions so I could avoid AWS (Supabase didn't have that kind of offering yet)

For me, it was _very_ pleasant to work in. I was able to ship features via OTA updates from idea to live in literally minutes.. sometimes even under a minute.

Loved working with Supabase.

How did you define your models and manage database migrations with Supabase?

After things were live, my migrations would be backward compatible. It's also possible to organize your tables where most of your data is in private schemas, and public views serve as your apis and versioning. Anything in a public view must be treated as a long-lived API until clients can be phased out.

My userbase was in the dozens at most, so pushing out a version OTA usually was effective to get things moving along.

Worst case, I had some code to check if the client version was too old and would shut it down until they updated.

As per models, what kind of details are you asking?

The supabase CLI supports database migrations:

https://supabase.com/docs/guides/cli/local-development#datab...

Personally, I've found node-pg-migrate works well for a Node stack and Postgres migrations in Supabase. Then, I primarily interact with the database using the Supabase GraphQL API + RLS.

I'd go with blazor and asp.net core. Stupid fast and easy to build with c#. No javascript needed

My first choice if the product is a good fit would be old school Django deployed to a single VPS (no docker). I am creating a public starter kit that does exactly that, including the deployment part: https://stribny.github.io/sidewinder/

However, there are lots of use cases that would call for additional SPA (Vue/Nuxt), or other tech. So in that case I'd add it or replace the tech stack entirely. I'd probably avoid specialized cloud services, might consider something like https://supabase.com tho if the app doesn't need a complex backend.

For the database, anything that's managed - I'm partial to SQL server just based on my work history, but Postgres is nice too. Even the expensive ones are like $100/mo for the lowest production tiers, if you're bootstrapping with a W2 job that's reasonable for 6 months while you try to find some level of traction.

For the backend, probably default to JS or maybe TS lambdas/function apps. Quick to write, quick to deploy, slap an API gateway over the top and you're ready to go.

For the front end, for a true POC I have a lifetime/full Creative Tim membership. So I'd just grab a dashboard and landing page template and start plugging in calls to the API gateway.

This sounds ideal to me. Are there any tutorials or resources that can help me use this stack? Thanks.

Whatever you know best and can set up quickly and easily. It's very easy as an engineer to focus too much on the tech and not enough on the product. Don't agonize over postgres or Dyanamo DB, Django or Spring, just use what you know to get it set up and focus on product, market, customers, sales, etc. Those will be the hard part.

My priority is to get things done. Ubuntu (DigitalOcean VPS), Django, Postgres, HTMX. I'm going full old school boring tech. No excitement. No drama. I might even go typeless if the code is of reasonably manageable size.

Same but with Rails and traditional server rendering if it's feasible. I know React is becoming boring tech but imo it's just so much faster to bang out most of the boring pages server-side and then if you really need it, break out "cooler" client functionality into its own React sub-app.

React has new friends all the time and they're not boring enough.

Java and Postgres. For large numbers of devs, this is a very intuitive stack they have lots of experience in and can get work done super quick. Also won’t have to rewrite later because good performance. I’d stay away from depending on any vendors for anything except a VM to bring your servlet container up on.

I'd go old schoolish-ish with Rails with Turbo or Phoenix LiveView (both with PSQL) + maybe some CF Workers.

We see no reason to use extensive front-end as it has only downsides now - it loads longer, it exponentially balloons stack, it requires to hire front-end guys, it is not needed anymore for DOM manipulation.

MVP should be built on things you will use later. Which is C#/Java/Python, React, and Postgres SQL unless your product has unique needs outside of the traditional space (it's a game, ML project, IoT project, mobile-only app, etc).

Firebase is too expensive. Only use case if you have only front end devs.

Dynomo/Mongo/Cosmos all do the same niche thing - you don't need a no-SQL db for most apps.

4. Apparently a lot of YCombinator companies still use Rails. I don't really understand why.

edit: I didn't know about Supabase - thanks.

Django/Rails make you a 10x developer. Thats why many who went for "Shiny New Things" are now coming back to Battle Tested frameworks , because nothing compares to those framework in terms of productivity in those shiny nodejs land of inventing wheel .

AWS Lambda + C# or Golang with S3/Redis/DynamoDB backend. Maybe Aurora Postgres if you need complicated queries.

It's boring but it works. It also scales as far as your wallet can handle.

I used NextJS and Firebase and while I disliked some of it: I would use it again because if the benefits of speed in building.

With this setup you can permanently host for next to nothing until you get users, do zero devops or ops, and have something that will scale up (wont be the fastest thing but it will be OK and will scale)

You could switch out NextJS for a static site generator too, but NextJS is pretty convenient and is a superset of a static site generator with everything wired up nicely using React.

I would not switch out NextJS for a SSG. NextJS can do SSG. But most SSG frameworks can't do SSR nor CSR.

Thank you, 'the next to nothing' bit is very helpful. I'd like to have a decent runway and a decent protection for my wallet just in case the MVP takes off in terms of user growth but not in terms of revenue growth.

Trying to make Solid/ChiselStrike stack work. It has its rough edges but I am trying to iron them out so its reusable for all my projects going forward.

https://github.com/learn-anything/learn-anything

Reasoning behind the stack is that I feel productive in Solid and it's plenty fast on first load and as SPA when fully loaded. I love the component model and JSX.

ChiselStrike is new to me but I was looking for something that lets me declaratively manage my schema. I checked https://entgo.io (it produced too many Go files to my liking), also Prisma (https://www.prisma.io), found it bit complex to get started with.

I also checked https://www.edgedb.com and it's nice but with ChiselStrike I can deploy it with LibSQL (fork of SQLite) and replicate it so responses should be plenty fast and I can build on top more easily.

For native apps will use SwiftUI composable architecture when it comes to it. React Native code sharing seems nice but Solid doesn't have a React Native alternative yet sadly.

I agree with that too comments that you should avoid having a backend at all for your MVP if you can avoid it (just make a static hosted website with HTML, CSS, and minimal JS).

But since you asked about backends specifically, this is what I would use. I would use clerk.dev for authentication, Hasura for the CRUD API, neon.tech for the database, S3 for static files (images), and AWS Lambda for any extra functionality you can’t accomplish with Hasura natively (but call them through Hasura).

Personally, I like using GraphQL because I can just focus on my data model and not think about what endpoints I need to make. But there’s definitely a learning curve, so sticking with a REST API is probably better for most people.

As an alternative, I would also consider Supabase like you mentioned. It sounds cool, but I’m already comfortable with Hasura so that’s what I go to first.

Update: For a website, I would actually use Remix with Clerk for auth and Prisma/SQLite for data stuff. That’s one of their premade starter stacks. I made one prototype with Remix and had a lot of fun using it. It’s easy to learn and will give you a high performance full stack app. My original answer is what I would use if you’re making a mobile app.

I've been trying to put together a solo project, that might be worth launching a bit later. My stack in general is:

Elixir for the backend. Reasons for it:

- Elixir is designed for reliability, so since I want to keep the app alive as much as I can by myself, it seems like a great fit.

- It also has excellent integrations with Postgres (my choice of DB) with Ecto.

- I generally skipped Phoenix, as I'm just using Elixir to create my API.

- Absinthe provides amazing support to create GraphQL API from scratch.

Frontend will be React probably with Relay.

- I've been using React at my job for years with GraphQL and I'm pretty fond of it.

- I've been planning on investingating Mobx, as I've never used it but heard good things about performance there. I'm not sure if it's going to be worth using it with GraphQL

- Relay has quite a lot of boilerplate, but I found it good enough for what I'm doing, and I liked the performance. Also it's fairly easy to integrate with Absinthe.

- Generally since this project is not made to be a start up or a business first, I want to experiment on the front-end on how I could reach the best performance with these tools at hand.

- I plan on using TS with the GraphQL queries mostly generated from the schema.

For deployment I plan on using a VPS probably, though I'm way far from having to choose that.

> - I generally skipped Phoenix, as I'm just using Elixir to create my API.

Why specifically? Phoenix is mostly just some convenience on top of plug, but does a lot of things you'll have to reinvent.

My issue with Phoenix (or Elixir..) is that there are like 3 people in the world using it. The community and the third party packages available is minimal compared to other ecosystems.

And in my opinion, it is already past its best days. I know of several companies in my area that a few years ago chose it for building their services and ended up, or are migrating to other stacks because of their problems hiring.

> there are like 3 people in the world using it.

This is flat out untrue.

I'm surprised nobody has mentioned https://redwoodjs.com

Here's why I'd pick it:

1. One language for the whole stack. It's an MVP so the front and back are both changing fast, with changes made by the same person, and you don't want to context switch all the time.

1a. Javascript as that language because it's the most flexible. And with TypeScript you can gradually opt into type constraints where they help you.

2. An opinionated full stack like Ruby on Rails that integrates all the pieces I need to ship. When you assemble yourself, even small version bumps or outdated tutorials can send you down a rabbit hole, stealing time from testing PMF. You want someone to validate a combination in which all the pieces work together smoothly.

2a. Redwood.js closest to be being the Ruby on Rails of JavaScript. I've toyed with it before and got up and running quickly. Its opinions took a lot of unimportant decisions out of my hands and let me focus on what I was trying to produce. I didn't get so far as to confirm this but it also seems to make it easy to gradually drop the scaffolding if the opinions and simplifications ever get in your way.

None of these frameworks (next.js, remix, redwood, etc, etc, etc) is a even half close to what you need for any non-trivial MVP backend. Such as:

- Validations

- Translations/localization

- Error and request logging and auditing

- Security (CQRS, CORS, CSRF)

- Permissions and a way to integrate it with your authentication (does supabase handle this? don't know)

- Email sending

- Background jobs

- Caching

- File uploading

- Rate limiting

Several of these very important things are missing for all of these frameworks. While most of them come by default or with community maintained "de facto" solutions.

I'm yet to see a feature wise equivalent framework in the JS world to laravel/django/rails. They're batteries included or full stack just on the surface, as soon as you start using them you start missing a ton of stuff.

I've never been much a fan of Node for backends though. There's no framework that's as feature packed as, for example, Laravel on PHP. And you have to worry about leaking state/memory across requests.

THIS.

I think I'd have to say NextJS with SQLite. Every DB table would just be 'id' and 'data', where 'data' is JSON-encoded and the schema is only enforced in code. This lets you write a 30-line ORM. Foreign-key relationships are just modelled as lists. If speed is the major concern, I find this the fastest way to build. You can bring structure to the DB as things are nailed down.

Why would you need to do this? It's not like creating tables with columns is a time consuming endeavour

Frontend - Elm + Tailwind (possibly Miso, it has been a while since I tried and dismissed it)

Backend - Haskell, Postgres

Infra - My most recent experience is with AWS and ECS but I'd likely try out Nomad and HAProxy.

Pretty much any other moving parts would depend on the MVP itself.

I'd use Postgres for the data layer, I'd build the service layer around OpenFAAS (using faasd) and Node/Typescript functions, and for the client I'd probably go with React/Next (though Svelte is starting to look pretty attractive). For basic CRUD functions I would probably use Postgrest.

I'd stand it up on a VPS initially, using ansible scripts to make switching deployment targets to AWS easy.

Probably React for the frontend, Postgres for the database, PostgREST to serve up a REST API, Nginx for routing. Any services or tasks not done in the DB directly written in one of Python 3, Kotlin, or Go. Pretty much any generic search task including freetext is easy in Postgres, but if I need more I’d throw in Elasticsearch.

Building an MVP should be done with the tools you’re most comfortable with!

Front end: Is SEO relevant? YES: AWS Lambda generating server rendered HTML behind API Gateway. NO: Vanilla React.JS app hosted on S3

Back End: AWS Lambda behind API Gateway

Database: AWS DynamoDB

This stack will reduce down to zero usage costs when there is no traffic and will scale up to much more than I will possibly need for anything resembling an MVP with no interference required by me.

Could you elaborate (or link to a framework) for doing the server generated HTML on Lambda?

I mean I'm literally building an AWS lambda function that outputs HTML when it's called via API Gateway. So someone hits https://mydomain.com/mycoolpage, then the MyCoolPage AWS Lambda function is executed, does database queries or reaches out to other lambda functions I've built as microservices and then outputs <html>whatever</html>.

If you're interested, I use https://middy.js.org/ as a middleware engine for my AWS lambda functions which I find helpful.

I use the open sourced serverless framework for doing deploys https://www.serverless.com/ though I'm probably going to move to using AWS SAM in the future.

Definitely still Rails for me, both for personal projects and for work. There are so many hidden requirements in SaaS products that have been baked into Rails and popular rubygems, getting to build on top of all that work is wonderful. It also makes coming back to a project to update it in a few months/years standard and simple.

If you haven't played around with Rails for a bit, things have gotten simpler in the past few years. Doing a quick demo/todo app on Rails 7 is delightful. With hotwire/stimulus, you get frontend performance that feels like React, but you're writing simple HTML/ERB templates and partials and some light JS controllers. It's quite nice.

Scaling those apps to lots of complexity is still an interesting challenge, and we're leaning towards React frontends on top of Rails APIs when the frontend is complex, but if you're building a standard CRUD app, Hotwire/Stimulus just lets you motor through the build and spend your time/money on user-facing value.

I replied on a different comment. I was faced with the decision to learn Rails or JS frameworks but I couldn't really find a lot of Rails tutorials or resources to build an app with Hotwire and the new front-end features. It's kind of a shame but there is not a lot of updated stuff out there.

T3 (https://create.t3.gg/) + Postgres (RDS). Hosted on AWS, Node Lambdas for async / background work.

I mean for me it comes down to what I am most familiar with. I am old so that means things like Digital Ocean and Express.js with plain old JavaScript. I guess I should not admit that publicly. Or privately.

But also if I was slightly less old I think I would be heavily into Python at this point especially as far as the ability to easily leverage data and AI tools and libraries.

But again, my suggestion is go with what you are familiar with. And if you are less old and are excited about a new language or framework, that seems perfectly valid to me. The hard part about programming is staying motivated. So if new stuff helps with that then great. I

One more take is that you should start by defining the problem in detail before you make up your mind on the architecture and technologies that you will employ. If there is a particular technology that is well suited or has a ready-made solution, you should consider that.

Given that you are going to throw away every single bit of this code -- yes, you will, and yes, your investors should know about it in advance, and yes, you should set hard numbers for when it's going to happen -- you should build your MVP using whatever toolset will allow you to innovate the fastest while keeping the site up, safe, and secure.

Agreeing with what has already been said about static HTML/CSS/JS on GitHub Pages with AWS buckets, but if Django or Rails works best for you, go with it.

Unless this stack is works-best-for-you, beware launching on React, Typescript, Next.js, or Vercel. That's what you're going to use for the Real Version, when you have money to hire some Real Engineers who are okay with the level of complexity. Don't incur that tech debt before you absolutely must.

Firebase (or maybe Supabase) - because I love a "backend-less" stack. It just take less effort (no need to write lambdas). Full solution out of the box (DB, auth, storage). If I ever reach the limit of this stack, I probably have insane PMF, so I'll deal with it then (YAGNI).

I'd probably go with NextJS and Pocketbase[0]. I like to start with everything on a single instance/machine, cheaper and less overhead, allows me to focus more on building things rather than ops.

[0] https://pocketbase.io/

I know this is not really in the spirit of the question, as asked. But an important consideration after having spent countless hours over many years building “MVPs” that ultimately go nowhere.

Hire a PHP/LAMP dev for $10/hour or less (or whatever is cheap and good enough) + something like digital ocean. Communicate effectively the features and milestones and project manage but mainly Spend my time on growth

I’m at a point where I can’t fathom writing a ton of code myself when I am trying to start a business. Programming is a hobby that I enjoy, but my time as an entrepreneur is more valuable elsewhere. Most likely I’ll find the business’s largest hurdle earlier and, it’s probably not a technical one. Then I can decide if it’s something I want to pursue or pivot to something else.

I've done this a bunch

It rarely works for me

Prob a bunch of reasons but

  - low dev expertise 
  - dev burnout bc it's prob a one man shop 
  - overengineered too aggressive on my part -- ie too complicated for an MVP

Old schoolish and Phoenix. I haven't seen any of the new (very cool!) projects in the JAMStack-y space really address things like migrations or even the data layer at all outside of "go use something else."

Ecto is the best ORM-ok-fine-it's-not-an-ORM I've ever used and Phoenix is a lovely framework that borrowed a ton from the success of Rails. Deployment used to be a bit of an achilles heal (in that it was uncharacteristically difficult compared to everything else about using it), but that's gotten _so_ much better in recent years. Even more simple if you just use something like Fly.io, which has incredible first-class support for Elixir/Phoenix.

I was wondering is there anyone uses Clojure or other Lisp languages for these kinds of things…

I do! Clojure and Pedestal https://github.com/pedestal/pedestal work great for quick MVPs. Clojurescript with a nice HMR environment like Figwheel https://figwheel.org/ is also great if you need a front end.

The question depends on context that hasn't been provided. Are you building it alone? Are you creating services where performance matters? What type of volume are you anticipating within the first 6 months that the MVP is running in production?

It helps to use the best language that your entire team knows. It severely limits your startup if the team is learning a new language together. Align tech decisions with the capabilities of the team, unless the common denominator is Perl. If the team each has at least 5 years of development/engineer experience and you're going to need to invest in a common language, give Elixir and Phoenix Liveview a try.

I would still choose Rails or Laravel.

When we were building the MVP for Transistor.fm, we chose Rails because it's what my co-founder knew the best.

These old-school web frameworks are mature, and still have a big ecosystem (community, resources, etc). Beyond Rails, we used AWS with Postgres, Redis, nginx/puma, and sidekiq for background jobs.

With any business (especially early stage), you only make progress when stuff gets built, deployed, and into the hands of customers. Remove anything that slows you down (like learning a new stack).

When we were in the MVP stage we recorded this podcast and went into more depth: https://saas.transistor.fm/episodes/nerd-stuff-our-web-app-t...

For an MVP I'm building, I'm using retool as the frontend, Flask hosted on appengine as the backend, cloud functions for async task execution, and a managed CloudSql postgres instance for the data layer.

I suck at UI/UX design and don't want to write a bunch of JS for async webapp stuff, so retool is a force multiplier there and would highly recommend. I Don't want to manage any infra, so appengine handles that for me. After getting everything setup with terraform in a day or so, I spend all of my time developing core functionality and 0 time managing servers or getting a UI to do what I want it to do.

Total cost to host is < $100

I'm currently building an mvp using Supabase & Next.js (FE & api routes). I can definitely recommend.

My main reason is speed; you can move very fast, and lots of the "boilerplate" stuff is handled out of the box.

I do keep post MVP in mind, it should be pretty easy to move parts to different systems if necessary. The most radical exit would be moving the Postgres DB elsewhere, or even self hosting Supabase.

It's good that it's possible, but I plan to use this stack as long as possible as it's great, and I have zero interest in managing and maintaining infrastructure.

As with everything; it depends. On your product and on your skills/expertise.

What a timely question! A couple of friends and I have been wrestling with the question, and coming from the enterprise world, have been retooling for producing code over producing production code for the MVP. We currently are looking working with

* Flutter, with FlutterFlow for UI * Pocketbase for quick, extendable back end code and basic BaaS * Heavier emphasis on market validation and strategy than technology

We set a goal that the MVP is barely a mock-up. The other understanding we have is that the backend would have to be 100% rebuilt if / when there is traction, but we were able to get to work in one web meeting.

Following up, a note on infrastructure. We are cheap, so our LAN is Tailscale. One of us provided a Mac mini where we installed Dokku to host containers and development servers. For internal use we've been very happy.

For exposure to others we'd likely deploy an MVP to the cloud in Dokku as well.

For production we plan to use Kubernetes, but that is an artifact of our skill set.

I'd go for a Flask back-end connected with Firebase for user authentication, storage and hosting.

Developing in python for me is just much faster to get to a working prototype. Flask is super simple to use, and I find it great to implement HTTP REST APIs for the back-end of my MVP.

With Firebase you can deploy containers in the cloud and you don't pay until you reach a certain threshold of monthly requests.

In terms of my development environment I'd definitely use docker to containerize my environment and make it easier to collaborate with others. If I was making a bigger scale MVP with multiple collaborators and sensitive source code, I'd opt for a cloud based CDE (containerized development environment) with monitoring and security features, such as the one proposed by strong network.

I could have a .NET 7 stack up in a few days deployed (well 1 day for basics), monolith, or multiple microservices, with Sql Server database, along with MongoDb, and JWT Authentication. React or blazor frontend.

With clean conventions to start with.

From the get go, performance would be great, and it would be fairly easy to scale with azure container apps.

Than another week or so to polish things up. Most time from than would be U.I based.....

Just point of reference, a couple of weeks ago created .NET 7 Auth service creating JWT auth from AD B2C, along with custom X509 Cert in 2 days complete with docker image build using Azure KeyVault, another day to get build/deploy pipelines setup, plugging in Azure APIM.

It's really incredibly simple and fast to do now.

You can build basically any MVP in almost any programming language and platform.

That said, anybody who gives an answer without knowing what they're building first and knowing the tradeoffs involved IMO isn't doing things right.

i like building with a backend as a service platform. with that i avoid all the backend work and can focus on the frontend until i have a better idea of what we need. at that point i can optimize or replace the backend if necessary.

I would use IHP, it's basically Haskell On Rails using nix and Postgres, and it all works out of the box. You can autogenerate code for controllers, schema, views, etc. and have a running app in 15 minutes. You can then hack on the code and with ghcid you can always make sure your code is correct as you make changes. I used it for a project recently and I found it much better than rails, python, elixir, and node for this purpose. I am not even considering Java or C because those are not for MVPs.

If it's a proper MVP that needs code and can't be validated via concierge or other no-code approach:

   - React Vite Typescript (React Query and Hooks*)
   - Python Flask Backend
   - SQLite or just fsyncing a JSON file to disk on each write (it's an MVP!)

Don't need anything more fancy than this.

* Tried Redux / Redux Toolkit enough to realize for a MVP it's sufficient to just hack stat with hooks and contexts, reducers are too much b

Depends a bit on the system, but for a fairly simple webapp: hasura, sveltekit, firebase auth and some lambdas

Some of my assumptions - meet customers where they are (need apps & web), be able to iterate quickly, minimize tech skills required, prefer easy-to-hire skills, worse is better (imperfect decisions are necessary to go fast & get customer feedback), prefer batteries-included frameworks.

Given my background that means .NET Maui Blazor (aka Maui Hybrid). You need two skills: C# and HTML (Razor). One language on the front end and back end. Compiles to native code on iOS, Android, Mac, and PC; WebAssembly in the browser. On the native apps the HTML UI is interpreted, but the rest of the code is in-process and native.

Since I want to use .NET, that means the best cloud support is Azure. Azure Functions for the API - serverless for frugal startup costs. For data store, Cosmos DB in NoSQL mode as a JSON documentDB - again, serverless for frugal startup costs.

I'm also very intrigued with using Go and Flutter instead of MAUI, but given my background that means a learning curve instead of being productive with a language I know well. I think C# and HTML are easier (more abundant) skills to hire, but I suspect Go and Flutter would attract more open-source-aware developers.

I'm not sure about a front-end HTML framework to go with Blazor. It ships with Bootstrap, which is probably file. I'm curious about Bulma which looks simpler and Material 3.0 for Web which is in alpha and marching toward 1.0 release soon.

I would use a full stack framework so I do not have the overhead of creating API endpoints.

I would use Laravel with Livewire.

You might also want to check out https://wasp-lang.dev/ - it lets you use React & Node.js (although it seems you prefer php), but you don't have to write API endpoints + everything works out-of-the-box

(disclaimer: I'm one of the main contributors to the project)

Thank you for your reply matijash!

I am not tied to a language. wasp looks very cool and will definitely try it out on the next educational day at the office!

nice, thanks for giving it a look! Btw, what is an educational day? You get to spend the day learning something new?

Yes. I did introduce it in my team to check out new technologies and frameworks which may or may not be useful for work.

4. Wasp (https://wasp-lang.dev) because it's the fastest way to build a full-stack React + NodeJS web app. You can build a prod ready proof of concept in a couple hours. E.g. Google OAuth2 is configurable in ~ 10 lines of code --> here's proof: https://youtube.com/shorts/-daNTYiUC64?feature=share

(disclaimer: I'm the guy in the Video :):):):):)

This is one of the core use cases where Encore [1] really shines. It helps you get up and running really quickly by natively supporting common cloud infrastructure components (databases, Pub/Sub, caching, cron jobs, secrets management, etc), and a simple low-boilerplate way of defining APIs.

It automatically provides API docs, architecture diagrams, and infrastructure provisioning, based on static analysis of your code base.

Disclaimer: I'm one of the founders.

[1] https://encore.dev

I really like NestJS for backend. It has great tooling and generators. It's super fast to create a REST or GraphQL API. Adding WebSockets is a breeze if you need them. It uses TypeORM which is rock solid. Also, it includes unit and e2e tests and linting out of the box. Also, if you're doing your frontend in TypeScript it's trivial to share interfaces for "type safety" across the wire.

https://nestjs.com/

Php/MySQL/html/css still the easiest simplest way to get anything out the front door

I’m doing one right now.

Using Rust, Diesel(Orm), Postgres, compiled jinja2 templates (Askama), and a smattering of JavaScript with AlpineJS, and Tailwind. I have 100 loc JavaScript that makes it easy to replace only parts of the page via Ajax calls.

Really simple stack, really lightweight, a joy to debug, and runs instantly. The delay on my dev laptop is below 10ms, it’s undetectable.

So much better than React and Python that I use at work in nearly any dimension. I hope the mvp works out and I can quit that job one day.

If you're building a B2B app:

- Supabase on the backend (REST APIs are a solved problem, no need to spend a single hour on it)

- Auth0 for authentication (too risky to manage authentication manually)

- react + react-admin SPA on the frontend (does 80% of the job for B2B apps)

- lambda functions (for business logic that can't be exposed on the frontend)

API-centric SPAs are such a time saver... when you don't have to build the API, and Supabase covers it.

For a B2C app, you must render server-side. I'd go with:

- Postgres - Next.js or Remix - Prisma

Curious why you suggest Auth0 and Supabase. What is wrong with Supabase auth?

Why must you render a B2C app server side?

Because of SEO: SPAs aren’t good at using robot time efficiently

That is making assumptions about what type of service it is though. B2C doesn’t inherently imply that everything is public and needs to be indexable.

For an MVP the most important thing is to get the product ready, have early feedback and then iterate based on the response.

After my extensive framework shopping of PHP/Laravel, Phoenix, Supabase, Directus, Kotlin+SpringBoot, I settled for Django+HTMX+AlpineJS for my side project. I could create a working MVP in a week and within 1 month I had most features up and running.

I plan to host it on Oracle cloud (free tier) and have not seen any issues with it so far in the test runs.

What made you decide against phoenix?

Phoenix/Elixir/Postgres Vue/Liveview

Phoenix support for websockets is really good right out of the box and for small/medium complexity UI's Liveview is light years faster in dev time than a spa. Liveview can take you far, but heavy UI work I still default to Vue.

Elixir can take some time to wrap your head around since it's a major shift from more mainstream programming languages, but I think there's a ton of fun in that.

LAMP because I'd like to focus on building features, not wrestling with the build tooling to get the dependencies of my dependencies dependencies compiling.

A project I started about a year ago is PHP/Symfony/MySQL/React. It'll run on any modern lamp server so I've put it on a shared host I already had running for another customer.

I'm going to deploy it on aws fargate sometime in the next 6 months or so, that should get me to scale.

The database I'm going to migrate to a single tiny ec2 instance until I need more resources, then it'll probably go to RDS or PlanetScale.

You mean specifically for products that involve the internet/web and is "full stack"? I'm not very familiar with the trends there but I do know I'd likely use a whole different toolset if I was only building a service without web frontend than if it had a web frontend. And whether or not it involves a database of some kind (and what kind) also heavily influences the choice of tools and platforms.

I'm surprised "Next with Postgres" is under "Old School" here.

Building an MVP to me means you are building a Proof of Concept (POC) for investors to see the value in your product. Using something that has a proven and lengthy track record and plethora of industry resources in the market feels like the right approach.

Depends on resources too... If you have separate resources for FE and BE. Probably still go Rails for BE. The upsides to Rails is productivity and job market. I'd track metrics that would help you keep an eye on application performance where it matters and iterate on those areas post-MVP.

For the FE I'd go NextJS... You can use it as just React or actually use all of the pieces to it where necessary. You can host it on a server or toss it on Vercel or Netlify to have less worries until you outgrow those (if ever).

For the database I'd probably use something that works well with Prisma JS for productivity, PostgreSQL or MySQL.

I'd stick to TypeScript for that productivity too. The iteration speed is a brain dead reason to use it.

If you can make the BE and FE with the same team and use all TypeScript... I'd use NextJS + Prisma JS + tRPC. tRPC would give a huge productivity boost because of its TS integration into your project. You just need someone senior enough to establish guard rails like the boilerplate, linter, and other guard rails to keep more junior developers on track and productive.

I feel that the combination of these frameworks will give you the right mix of quality and iteration speed without sacrificing one or the other. Also, great hire-ability. Though, all of this depends on if you actually need a DB and a backend, or even a frontend for what could suffice as an MVP.

Just some thoughts...

Unclear description of requirements. Even as a green field project you base these on the environment it needs to operate in, the team that will work on it, and/or based on requirements of the actual functionality. And if for your own project, base it on something you know. Learning a new stack and developing an mvp does not go well. You would be struggling more to make it work than making progress.

https://pocketbase.io/ Simple, performant, batteries included

Pocketbase is surprisingly easy to use to build prototypes and smaller apps! Love it so much

Fresh, with Strapi to help bootstrap a backend, but eventually migrating all to Deno when the budgets permit.

https://github.com/Hyprtxt/fresh-strapi.deno.dev

This site uses the framework, but not Strapi: https://videopoker.academy

Plain js on the frontend. Complex logic handled in rust-wasm. Backed handled in Rust using the Actix Web http server, using websockets, proxied through a very basic nginx instance with TLS.

My own servers for the entire cloud, maybe with CloudFlare as a CDN.

Avoid anything else as much as possible. If you need AI/ML, you're going to have to pull in some difficult extra stuff, so make sure the value is there.

Owing both to the unreasonableness of the modern javascript stack (node/eslint/jest/react/typescript/webpack) and also to the considerable improvement of vanilla js over the past 10 years, I really don't feel like all the extra frameworks are worth the overhead and dependency risk on the frontend. Vanilla js is really good these days! And when you need a boost, rust wasm is also really good.

I've found that it's a lot faster - and also a lot safer! - to build in vanilla js than I ever would have expected. Typescript still adds value, but imo not nearly enough value to earn a place in the stack.

What's the advantage of doing complex logic in rust-wasm? I assume you mean in the frontend?

It depends .. (frameworks/libs/langs) for enterprise stuff at work, we have our tech stack worked out, for freelance, it'll be what the customer wants or what I'd feel would be most maintainable. For infra, for both I'd use docker to run my apps and supporting services ... I've been really into the hashicorp stack, nomad + consul .. docker gives you a solid dev env and portability when going production

Laravel. I don’t have time to fuck around with whatever the latest hotness is.

Assuming web app.

1. Python.

2. Flask. Pure server-rendered HTML, no fancy frontend. Avoid JS as long as I can, just use jinja templates. If my app is not going to work with good old HTML and CSS chances are it's not going to work at all.

3. Classless CSS framework. I like this: https://watercss.kognise.dev/.

4. Sqlite3 or Postgres. Prefer postgres because with docker it's 5 minutes to set up. I use SQLAlchemy from the start because it makes life easier. If you ever deploy and worry about real data you add alembic for migrations.

5. One docker compose for everything.

6. Cheap VPS for like $3 per month.

That's it. I would like to upgrade my MVP stack, but it's battle-tested and it works well. After the 9 to 5 I only have like 3 brain cells alive so I need to get stuff done as fast as possible, which means using what I know.

One thing I often reinvent and reimplement is OAuth. Definitely "Sign in with google" is the best way to add auth to your app, but it's such a pain to set up.

If I were building an MVP today, my stack would likely include a web framework such as Django or Ruby on Rails for the backend, a React framework such as refine for the frontend, and a database such as PostgreSQL for data storage.

refine is React based for building CRUD app rapidly. Repo: https://github.com/refinedev/refine With refine You can build admin panel, dashboard, internal tolls, and any CRUD app rapidly

It eliminates the repetitive tasks demanded by CRUD operations and provides solutions for critical parts like authentication, access control, routing, networking, state management, and i18n.

It also has connectors for 15+ backend services including REST API, GraphQL, NestJs CRUD, Airtable, Strapi, Strapi v4, Strapi GraphQL, Supabase, Hasura, Nhost, Appwrite, Firebase.. So you can save a lot of time from development time.

It's obscure and different but I'd be using https://safe-stack.github.io/ I've never felt as confident about my code as I am with F#. It takes a little getting used to and some custom widgets are awkward to get working but I love the stack.

Another F# fan here =)

I really like it for building backends but I haven't found the frontend story as compelling. Currently I use F# for my API and then use a standalone frontend (currently SvelteKit) to try and get the best tool for backend / frontend.

Q: How's your experience been with F# frontends? I'm assuming you're using Fable?

It's been amazing. Yeah I'm using fable. I think there is an early Svelte version.

The strength is shared code between the back end and front end. The same types and validation logic.

I like Elmish but I'm still prone to create a bit of a mess. It takes some thinking in how to build modules up. The bundle size is a little large as well.

My bug count is way down. I love strong typing in the front end.

I used to be into CakePHP and then Laravel, I liked the monolith style architecture where the template, API, and user interface all live together.

I've done backend separated from frontend and while its nice it can be a pain to manage on your own, which is usually what your doing at MVP time.

Now I'm more focused on using stuff like Strapi or rolling my own Hapijs server when needed and having a JAMstack frontend to interact with it.

Next.js has been a breath of fresh air to bridge the conceptual gap between what I was doing in Laravel (PHP) and now im doing in Next.

JAMStack and serverless functions are awesome because you don't need to maintain servers anymore. Most sites can be primarily static especially when you are prototyping... the data that comes from an API can be mocked for demos.

SQLite for DB development without the internet. Being able to run tests or do other stuff thats DB destructive without connecting to anything. No local server, no nothing. Just you and your flat file. Bliss.

Directus connected to a Postgres database

Comes with a built-in low-config UI/API for CRUD on the database, and easily extendable with Vue.js and Express endpoints.

Additionally, should the need arise for something more custom later on, all your data is in Postgres rather than a backend as a service

https://directus.io/

I've used it on a project a year ago and I've found it very effective for prototyping. But I eventually had to move out of it, and I don't see good you can make it work in the long run, as access management and data migrations are a PITA.

*Quick answer:* MERN.

*Explanation:* >> I need to really push myself to finish my last YouTube MERN-stack tutorial. >> I will then be able to competently contribute to the planning and implementation of a real (full-stack-web, and mobile-native) app. —->>> Purpose of app: Higher-education advisory services for N.-American colleges, as well as international students and their sponsors.

python -m http.server 9000

And Bootstrap, if I'm feeling generous.

When you're trying to validate a product, the last thing you should be spending your time on is fiddling with anything more complicated than this.

So many good answers, and interesting to read the overall technology landscape. The technology debates can be endless, though. I think it's good to consider a few non-technical aspects as well for selecting your stack -

1. Is this stack popular among recent similar successful products?

2. What technology will make it easier to find relevant talent?

3. Does your stack allow for rapidly changing code along with a rapidly changing team? This is important, especially in the early stages of development.

4. Are you trying to do things the Google way? Facebook might never exist had they started with C++ instead of PHP.

5. Do you want to be on the cutting edge for the sake of being on the cutting edge?

I elaborated on this a bit in my blog here if interested - https://sleeksky.com/blog/technology-stack

I may be an outlier here. But I strongly prefer not to optimize for speed when building an MVP. Because it just _never_ (at least in my experience) gets a chance to be fully rewritten into something better. The idea of an MVP is to prove the market need and if it’s proven, the wheels are already turning and it’s impossible to resist the pull.

So you end up with a bunch of tech debt or just inefficient stack that poisons your codebase from day 1. I think the initial gain is just not worth it in the grand scheme of things.

So we always are trying to use the best possible production stack. Not overengineer - just use the best solution for the long run. Long term gains beat marginal short term benefits.

Currently our stack for a pretty small eng team is Go, React, GQL and Flutter for mobile. Works pretty well for us.

But as I said, I could be an outlier here :)

For a web-app of some sort?

Host: VPS on OVH

Database: Postgresql

Web layer (server-side): Grails

Web layer (client-side): Javascript - probably vanilla, maybe React. Bootstrap.

Auth / SSO: Apereo CAS

Deployment automation: Ansible

CI/CD - Jenkins

Issue tracking: Bugzilla

IDE: Eclipse

DNS: Route 53

If I felt the need for dedicated micro-services for the backend, I'd use Java and Spring Boot.

If needed, possibly Apache HTTPD as a reverse proxy.

For a lot of stuff that might fall under "other", like sending email, or text messaging, yadda yadda, I'd use Amazon services: SES, SNS, etc.

For an MVP I'm not sure if I'd even bother building Docker images or not. But if/when I had to scale up, then I'd definitely package as images and deploy using Docker or K8S. At some point if the thing got traction and needed to scale Big Time™ then I'd probably go to Amazon EKS or Azure AKS.

If I needed a mobile app... well, I'm not really a mobile developer, but I've been picking at learning Flutter. So probably would continue with that.

T3 stack - Typescript, TRPC and Tailwind (uses NextJS, Prisma, etc). This is the closest in the JS/TS world to something like Django and end-to-end typesafety can enable you to go blazingly fast. Copilot became pretty good at autogenerating my queries/mutations for me too which was nice.

Building with this stack right now, really enjoying it and more importantly able to move quickly as a solo builder. Supabase/Railway/Neon/Planetscale all good choices for hosted DB.

I would focus on functional languages. They don't change much nor often and guarantee (in 99% cases) everything is going to work reliably as soon as it builds successfully. The less people you have the more you need functional languages. Elm, Elixir, F#, Scala, Clojure, Kotlin etc.

I forgot to mention Reason.

As for Haskell - I omitted it intentionally. It seems beautiful yet not practical enough. Perhaps it is perfectly practical but I didn't have a chance to learn it to the level on which in starts feeling this way.

I've had an unparalleled experience in getting an MVP live with shuttle[0] - nothing is as fast for deploying a web app with a database to the cloud. For the database I’ve used shuttle’s dedicated SQL DB instance[1] and for the front-end I’ve used shuttle’s static file server[2].

If you are not scared of diving a bit into Rust, I'd a 100% recommend it.

[0] https://github.com/shuttle-hq/shuttle [1] https://docs.shuttle.rs/resources/shuttle-shared-db [2] https://docs.shuttle.rs/resources/shuttle-static-folder

For something in the same vein but for Go, there is Encore: https://encore.dev / https://github.com/encoredev/encore

I've gotten fast enough with Go + Twirp/proto for the API. sqlc+pgx for the database interface. (i.e. generate as much code as possible). I have a couple of functions/middlewares I can pull in for user auth. I don't think this is that much slower than Django if at all.

Backend: Go, Frontend: Elm.

Both languages are simple to read, easy to maintain, and very fast/efficient.

https://docs.simpleiot.org/docs/ref/vision.html#technology-c... http://bec-systems.com/site/2048/go-for-iiot-systems http://bec-systems.com/site/1625/why-are-go-applications-so-...

While I prefer python for everything else, I'd go with Laravel Jetstream[1] for an MVP, just like I did with the last one I had to build. It's laravel, you can use Vue (React or Svelte) for your views instead of the blade templating language that comes with the framework. Jetstream also comes with Auth, user login and subscription and other useful stuff.

And for the flavor, I'd just go with DaisyUI[2] again, since it's based on tailwindcss and it's what I've been using lately.

In my experience, I can build MVPs real fast with the stack described above.

[1] https://jetstream.laravel.com [2] https://daisyui.com/

Good timing: a lot of top-level comments here mention Rails on Docker, then this post rockets to the top of the front page: https://news.ycombinator.com/item?id=34533930

Depends what I'm building. When getting it done as quickly as possible, I'd rely on Python - Django, and Postgres. If time is still of the essence, but not as breakneck, I'll use Python - Fastapi and Posygres.

If I have more time, I use go - chi and redis as a primary database.

Because of the expertise I have, number of packages i've created for it, and sheer ease of use, I pretty much always do the same thing:

Node.js, express.js, Typescript for the "central command" server that acts as any client's first port-of-call.

Central command fans out to whatever tech is required for the job. Very typical for me is fanning out to various python Flask servers to do ML/image proc/etc. work or connect to GBQ.

PostgreSQL for persistence because it's pretty much the undisputed pereto-optimal solution: solves 80% of problems with 20% of the effort. Does almost everything you need until you get to the big scales, which by then you can afford to just pay the wizards to do the Cassandra, Dynamo, Redis, haskell, etc. magic

Combination of LAMP and Go, which is what I have been doing for years. You can knock out a functional MVP in PHP faster than anything else and iterate very quickly. Then spots where performance is an issue work in some Go microservices.

This has done my team very well for years.

This is a killer combination. Nothing has beaten the speed of iteration with Apache+PHP.

You can also run a Go FastCGI server to deal with whatever you don’t want to put in PHP (jobs, complex business logic, performance sensitive logic, etc. )

As others have said it's about what a developer personally is familiar with and can execute well and fast with.

For me that's Laravel mixed with raw PHP (a fantastic and high performance language that has proven itself for a long time with some of the most popular sites on the internet), running on a cloud platform that requires literally the lowest amount of devops possible, so maybe Heroku but more likely Google Cloud's AppEngine or CloudRun. Frontend I personally would use raw JS with JQuery for convenience and compatibility. Probably Twitter Bootstrap for styling etc.

Result of all that is a quick well functioning and reliable site or service.

Joystick [1] using MongoDB as the primary database. Run a few instances on VPS and then a load balancer in front. This is how I run my site [2] following a massive amount of headaches and random downtime fighting w/ a k8s cluster. Zero downtime since I moved it over in October. Only thing I don't like is I'm using a third-party DB host for Mongo (ScaleGrid) which has unfortunately gotten quite slow over the past year. Planning on moving this to a self-managed VPS as well.

[1] https://github.com/cheatcode/joystick

[2] https://cheatcode.co

My sweet spot is

1.Flask with Postgres for API. 2. C++ with Pybind11 for core performance engine. 3.Whole stack running on a single cloud instance with docker compose. 4.Next.js, Typescript, Tailwind for frontend. 5.Github Actions for CI/CD and deployment to cloud.

Google Cloud Run (with Dockerfiles) + CloudSQL (Postgres) + Cloud Tasks.

On the back-end, NestJS with Typescript plus some query builder such as Knex (TypeORM is pretty buggy). Or maybe even try Prisma.

For front-end it depends. I would try using just Vanilla JS with Tailwind if possible or fallback to React + Tailwind if there are too many screens, or they need a lot of updates based on state.

Those are mostly technologies I'm comfortable with because I use them every day. However, if I have the option to waste time researching and/or learning, I would research the state of server-side Kotlin and learn Elixir/Phoenix before making a decision. NestJS can ge too verbose sometimes.

Whichever "boring" technology you're most familiar/fastest/productive with. It rarely matters. Don't waste time learning a new language/platform when you should be testing the idea itself as quickly as possible.

Depends on the project.

But in general:

* Old School VPS or Cloudflare Workers (if the problem lends itself well to Workers)

* Usually leaning towards sqlite instead of a hosted postgres (as that's often overkill)

* Language: whatever fits the problem best. These days likely TypeScript as it's so versatile.

Heroku/Node.js/Express/Bootstrap/Three.js

Old school, but it works.

I keep that side of the stack simple because the front-end is ESP32/MicroPython/3D-printed-parts/aluminum-extrusions/lots-of-motors.

- SvelteKit (TypeScript/Sass) for front-end - Deno, GraphQL, and EdgeDB for back-end

I'm using Supabase, and a flask server for backend. And using Flutter for front end.

Depends on what the product is. If it's ultimately some kind of CRUD app, hard to beat Rails.

I'd probably run it on a managed K8s platform though instead of a VPS. At the very least use a managed (postgres) database instead of running my own.

Just about to release an MVP.

I went with:

Terraformed AWS/EKS

Docker

Postgres

Node/Express

React

I'm pretty language agnostic, but for webstack I like to use Node, because it means I don't have to context switch too hard. I'm using the same language on the frontend and backend with the same APIs. I only have to keep one standard library in my head and a lot of packages are compatible with either front or backend.

Whenever I'm working on the web, that's going to be my go to.

I would consider Typescript, but I don't think the cost/benefit of Typescript really balances out until you have a team. The need to create types and type harnesses for libraries slows you down at first, and speed is the name of the game with an MVP.

I love Django but think this is a pretty sensible stack for a single developer who is strong at JS.

You are still going to have to make a lot of correct library decisions to implement key features like auth and a DAL. Nest JS is an interesting batteries included approach (haven't tried). TypeORM had a lot of issues few years ago but might be getter better.

Disagree re: TypeScript though. Most libraries worth using have types or are TS native these days. I find myself much more productive writing TS on solo projects with less foot gunning.

A lot of these suggestions sound needlessly complex but I'm probably just getting old.

I'd say either CGI scripts, PHP, or Ruby and sqlite as a DB, all hosted on a single VPS. That'll get you plenty far and be easy to grow out of.

Currently building with Next/TRPC/Prisma/PG and would choose it again. I might be a little slower than starting with a full-featured MVC kit like Laravel or Rails, but having an e2e type system is so worth it to me. I do miss having a more mature ORM.

I'm constantly tempted by Phoenix but desuaded by the lack of a type system. Does elixir somehow make up for the lack of types as a functional language? Also, I can reuse a good deal from my current stack in a react-native app for mobile, which I'd miss out on in another framework.

Wish I could say Flutter, but have not been impressed by the web experience.

There's a component called dialyzer that can help detect type issues, but i wouldn't say its nearly as useful as having real types in a language. That said, I've never found it to be much of an issue in Elixir, and the advantages you get with BEAM are worth it. There's a newer language called Gleam that does have a strong type system you may want to investigate, as it runs on BEAM (like Elixir and Erlang) and can use libraries and applications from both in its apps.

I recently built a Web based MVP and used Node-Red as backend. Frontend was python+flask, postgres and everything dockerized.

I've mainly used sinatra and rails for Web apps and always found it difficult to define a clear api on which the frontend was based on (I.e in order later to build ios or android apps off).

Using Node-Red forced me to build an api for the frontend, the frontend has no direct contact with postgres.

Plus I found it to be more flexible than directly coding when I wasn't even sure what the database schema would look like.

Database modelling was done with pgModeler, I.e. No migrations and more pgsql functions and triggers.

There is so little out there about using Node-Red in this way that I would certainly love to see a writeup of the experience if ever you fancy it!

My experience also! It seems NR is only used for IoT and hobby projects but it definitely has more potential.

What I use it for is api endpoint, email templates and sending emails, websockets and as admin tool (the dashboard).

It requires a lot of discipline to keep the flows separate. Reuse of code is a challenge (very tempting just to copy and paste code) and generally to maintaining an overview (simply because of the number of flows).

On the other hand, business people can immediately see the flows and thereby understand the logic. Debugging is a matter of connecting a debug node at any point in flow. Background jobs (ie sending email) is a matter of splitting the output of a node (ie http response is sent and at the same time email is triggered or websocket update is sent).

Scalability and production performance remains an open question for me. In worse case scenario it would be a case of taking the flow.json (my entire backend is a 300k json) and building some kind of interpretor from scratch ;)

I like this approach!

NodeRed is a perfect MVP for serverless without all the cruft and costs of AWS/GCP/Azure/whatever.

I tried everything from supabase to rails. These days if I need a quick mvp it's built with Imba on the front-end and Pocketbase on the backend. The installation and deployment story of Pocketbase is the easiest.

Elm on the frontend, Elixir on the backend.

Elm because then you can mostly ignore JS et. al. You can hire a normal person (anyone who can solve Sudoku puzzles) and train them up to make working web UI in a week or two. Elm makes that possible. It's like what if you could start a professional bakery with just an Easy-Bake Oven.

Elixir because it's more approachable than Erlang. Erlang (the BEAM & OTP) because it's much closer to the domain (if you're making a complex interactive multi-user kind of a thing, eh? If not then it doesn't really matter what backend stack you use.)

1. k8s 2-node cluster on cheapest instances

2. Hosted Postgresql

3. Hosted Graphql API layer microservice (like hasura)

4. Hosted hhtps server

5. Some kind of cloud storage solution

5. Load-balancer ingress

6. Some kind of CDN

Spinnable in less than day with SSL on, works perfectly for any app to scale and covers most production problems

Late to the thread and haven't read anyone else's responses yet, but I get the feeling this is going to be a common refrain; I'd just go with what I'm most familiar with.

Some off the shelf PHP8/Nginx Docker container, Laravel for the API (always pull in php/larastan for enforcing best practices), Maria for the DB, Laravel's Blade/Vue for the front, probably slap it on AWS as that's what I'm most familiar with. I like structured data, I like that modern PHP has (90%) of the safety of Java while being less verbose.

Golang (most likely a rest API using the Echo framework).

Postgres and maybe Redis if I need a message queue or cache.

React for the front.

Nginx and certbot for the reverse proxy.

Everything hosted on a cheap OVH VPs.

Mostly because it's what I am familiar with. Plus it's cheap specially since I already have the VPs anyway.

Go service with Postgres (without external cache), deployed (SCP) in GCP VM

Reducing touchpoint definitely helps at MVP stage. You've to trade performance with features (depending on the tool dev tools vs CRUD business)

Backend

.NET Core on Linux - Works really well, C# is a great language and quite performant too.

EKS/ECS on AWS with spot instances - works out pretty cheap

Cloud DBs like Aurora or DynamoDB

React for frontend, because of how many libraries are easy to get for it.

Currently building an MVP:

- NodeJS, Typescript, Docker

- Fastify for the API

- Sequelize for ORM (Prisma seems like a good choice too but comes with too many features imo)

- Postgres (locally rn)

- AtlasDB for migration (I like the declaration style)

- Hosting didn't choose yet but would go with vercel or free tier GCP

Im proefficient with JS so that explains the why, however in 10 years the ecosystem still didn't catch with Rails in term of having one solution to all problems.

You still have to carefully choose your dependencies, all tutorials are quickly outdated and it's missing some crucial pieces that you have to glue manualy or code entirely.

Prisma has screwed me too many times to count. Sequelize has always been solid.

For simple cases maybe Bridgetownrb which is a static site generator. The twist is that it can have a dynamic part with roda.

For an application I'll use rails with postgresql (reliable and flexible can also store documents). Redis and sidekiq for background processing. Turbo, hotwire, stimulus and tailwindcss on the front-end. Vanilla rails is the best for me. Easier upgrades in the long run.

FLask would be myy pick!

I have worked with it in the past, and having familiarity for the MVP trumps all, for me. As I can rely on it to provide me with a solid backend without having to worry about unexpected..

I’ve gone all in on Cloudflare for my “stack”. R2, durable objects, D1, queues, logs, Pages and Workers. It all works beautifully, out the box, dev env baked in (wrangler), Internet scale.

I've been building MVPs for the past yearish with this stack. Some of these choices are newish / smallish but it's the simplest, most enjoyable stack I've tried so far.

- Frontend: SvelteKit (Dockerized)

- Backend: F# / .NET running Giraffe (Dockerized)

- Data: Postgres (Managed - currently GCloudSQL)

- Hosting: Serverless Containers (currently GCloudRun)

I built a boilerplate for this to make it easier to improve / spin up: https://cloudseed.xyz

I'd run an API using Deno (https://deno.land), and consume that API with an SSR/SSG site built using Astro (https://astro.build). SCSS for styling, and probably just Vanilla JS (written in Typescript and compiled via Deno) — I increasingly find that unless my site is massively interactive, plain old Vanilla JS is totally sufficient.

Building an MVP right now. Digital Ocean but may switch to Linode. LAMP. Wordpress for web and the API. Delphi for iOS, Android, Windows, macOS, and Linux clients. Stable Diffusion.

For almost everything it’s Elixir at the moment.

Phoenix is wonderful for web apps, LiveView makes UIs about 2x easier and faster.

For more interesting electronics MVPs I still use Elixir + Nerves for prototyping.

A good stack IMO has the fewest moving parts possible.

JAMstack for the frontend served via cdn

Terse STATELESS apis on the backend likely in Go on a managed k8s cluster

DB choice depends on requirements for the app IMO if its data that needs to consistently persist put it in a relational DB like maria or postgres. If the data is short lived let it hit mongo or otherwise.

To be completely honest though with current tooling you could do an e2ee local sqlite database and store it in an S3 bucket using a guid per user.

I went through this exercise recently, looking for a stack for a greenfield project which I had full control over. Tl;dr: I chose Rails, albeit with ViewComponents.

When I compared the existing frontend backend stacks like Svelt, Next, or a Go, Rust, whatever backend + React frontend, the amount that’s in Rails out of the box is just not even close to the rest. From ActiveRecord to secret management, a dynamic ecosystem of gems for almost anything and much more, choosing another stack just didn’t make sense.

Believe me when I say I really wanted to choose React for frontend because of its community and ecosystem but for an app with a backend that there is so much Rail does for you that you’d be spending weeks rebuilding with anything else.

A caveat is that this is Rails + Hotwire and Turbo + ViewComponents that makes it a no brainier. The old school Rails MVC would have been a harder sell

These days I prefer Next.js + MongoDB for full stack apps. Pushing changes to a repo and have it deploy automatically feels like a super power.

I have a moderately complex project, which is built using Next.js but it uses Yarn workspaces (for code sharing) and Docker (for deployment) but I waste a lot of time putting out fires w.r.t this setup than actually building features. I am thinking about doing away with Docker and Yarn 2 to keep the setup simple.

Django. Modern Python has been phenomenal with its choice of feature additions (f-strings, type annotations v2, structural matching, better timezone support, etc.) and its a language with great mindshare right now.

HTMX has been very promising, I have bumped into one or two bugs with it but there are always simple workarounds due to the sheer surface area of HTTP+HTML.

Postgres for great JSON support, keeping some stuff out of rigid schemas is critical for developing MVPs.

Backend: Rust + Axum/Tonic

Frontend: If webapp needed, Typescript + React. If just html templating, probably Yew

Database: PostgreSQL. Move to Yugabyte or Scylla if scale becomes needed.

Streaming/event driven architecture: Fluvio

Cloud: AWS

Servers: ECS/Fargate to start. Move to Kubernetes as needed

IaaC: CDK

Repository: Github Monorepo

CI/CD: Unsure.

Style: Monolith API server. Separations will be made through Rust modules and interfaces. For anything that requires dedicated CPU/threads, those will be moved to separate services to be called by the monolith via gRPC.

Next.js for both backend (server React and REST API) and frontend. Prisma ORM to Planetscale DB (mysql auto scaling). NextAuth. TailwindCSS. Typescript.

Very simple, very easy to deploy and scale, and in-tune with all the best practices of fast frontend (auto caching, SSG, ISR, prefetching, client side nav, etc)

Didn’t like Django. Deployment more annoying, templates are weak and DSL-specific, React integration is poor and then DRF is a strange verbose monstrosity.

I built an MVP that's been running in production for two customers entirely in Laravel and Semantic UI (CSS). When the need to a better UI was a concern, I added bits of client side Vue.

Now I'm rewriting my front end entirely in Svelte(Kit) and Tailwind, and keeping the Laravel backend for now. I will experiment with more lightweight PHP backends and Rust in this rewrite just to see how good (or bad) things can get.

Django, using django templates and hand-written JS and CSS. No CSS or JS build steps -- that just makes things harder at the MVP stage, I have recently decided.

I actually just built one. I tried a few other things first -- started off in BlazeJS / NextJS, didn't like it, tried some other react & backend combinations and there were always obstacles. The kicker was that I wanted geodjango for geospatial support.

The best stack is the one you know.

I guess I’m old school, but I built SimplifyRecipe.com in a few hours using Laravel. That’s not to say that Laravel is better than anything else, but I’m extremely fluent with that ecosystem.

I will say, I believe that Laravel or Ruby on Rails would be my favorite starting point for a solo development effort. I spent 1000+ hours working on JavaScript framework development and found it to be really cumbersome.

I’m very fluent in JavaScript (I’ve been a js dev for 10 years) and don’t have that much experience with Laravel yet. I totally agree with what you say.

Even. It being fluent with pho and the ecosystem I find it incredibly more easy to learn and more productive. A lot less foot guns.

Backend? Probably Python w/Pyright (Type-checked Python), FastAPI, Postgres.

Reasoning is pretty straight forward: I know it quite well and it's easy to grok and hire for them. Good tooling and ecosystem around it. Are there better languages out there? Sure, but Python has the advantage of being wired into so many different business and scientific domains its impossible to paint yourself into a corner.

Backend: NestJS + Prisma (DO NOT USE TYPEORM!!!) Front-end: Next.js with TypeScript (for SEO) Infra: AWS EB (t.micro) + Cloudflare

- Next.js frontend/backend, edgedb on top of postgresql, Linode server behind cloudflare. No Kubernetes.

Or, if you want to be more classical:

- kotlin backend using dropwizard, jdbi ORM connecting to postgresql. No kubernetes.

Or, if you want "plug and play" as backend:

- next.js, supported by postgREST. No kubernetes.

Or, if you want something exotic:

- elixir/erlang/phoenix as frontend and backend, no kubernetes.

I think the future is probably

- some frontend, edgedb, no kubernetes

Vanilla Rails.

My app started 7 years ago with Rails + AngularJS on the front end. Wish I had just used Rails for 90% of what I had used AngularJS for.

NextJS/Typescript. For the database, maybe Redis, or Mongodb. RDMS except sqlite seem to be overkill for an MVP.

For frontend, a picocss-like minimal framework.

Django for the next stage. It's good for blogs, feedback management, back-office. Django beats rails. Rails is generating (scaffold) code while Django abstracting the CRUD operations. Clever abstraction beats generated code.

FastAPI & Postgres for the backend. REST + websockets for the API. Over the years I've tried all kinds of BaaS and more magic "X as a service" solutions, but I often hit some edgecase or limitation that is a dead-end or run into some bug I can't fix myself. So I prefer the flexibility and robustness of Postrgres with the ecosystem of Python.

If I was starting from scratch and didn't have any other constraints, I'm sure that I would go with Elixir/Phoenix.

Fully custom runs anywhere stack, hand written OS, orchestrator, VMM and TLS*

*bearSSL powered because I can't into curves myself :/ as the only external dep

if state is needed I lean on DuckDb but eventually a more optimized in-memory columnar data structure will be devised.

Mostly because I found all the other options in this space to be lacking for performance-oriented low latency services.

I could explain what I'd choose, but that's irrelevant as it's based on my existing skills

The one thing I can't recommend enough is the value of organizing persistence around a nosql distributed db and blobs of zipped files (also distributed)

In my experience, db is expensive. But this setup is dirt cheap.

Sqlite is good but it makes you worry about scaling (so it's great for an MVP)

I'd say hybrid-ish.

1. Hosting, full on AWS. Because I'm super comfortable with it and I get end to end; from domain registry to data store and everything in between.

2. (mostly old school) Web app stack: React, Java/NodeJS, Postgres. S3 for doc store fronted with Cloudfront. Reason: Battle tested, huge and thriving ecosystem, most of the problems are solved.

3. Lambda for async tasks.

My last SAAS was just raw php on the backend with postgres. Raw JS on the front end with a little JQuery. Ran for 9+ years, zero down time, zero issues. Supported the Marketing and legal department of a Fortune 500 company. Old school is they way. It does depend on what you are building though.

Recently really started to like Python so would probably try DJango.

T3 Stack (Next.js, Typescript, Tailwind, tRPC, Prisma) with Postgresql (Supabase is a good free choice), deployed on Vercel w/ Github Actions. These give you the ability to iterate rapidly and is the best choice in the market imho. https://create.t3.gg/

A web3 stack, everything client-side and peer-to-peer. HTML/CSS/JS for front-end. JS/blockchain for backend. JS client-side storage/compute, JS libp2p library for peer-to-peer discovery, networking, syncing, updates, user-generated content, etc. Blockchain for things that need to be tamper-proof or involve payment.

I certainly won't do it in the stack that I don't know even if the rest of the world is saying that stack is the greatest thing since sliced bread.

But more importantly, it depends on what I'm doing.

Just to give you an example: if am I making a simple site with some dynamic content? Why would I use React for that or a giant framework for that?

AWS + Node.js + Lambda + Aurora + API Gateway + ElasticCache + CloudFront + SQS + MediaLive + MediaConvert.

We scaled up to hundreds of thousands of viewers + telemetry worldwide with no issues. Should be breaking into millions real soon now with our next few onboarding's.

We also have an express backend for the UI that's running on some puny EC2 instance.

I'd do python + django + bit.io (serverless postgres; I'm the CEO but I built it because I wanted to use it), deployed in a container to k8s somewhere. These are all personal biases to what I've used and know well; for someone new to backend I'd probably recommend next.js + nodepg + bit.io on vercel or similar.

The number of Elixir/Erlang backend suggestions seems over-represented. Not even Phoenix, just a blanket language suggestion. This leads me to believe that many posts are throwing out their newest stack-fad they imagine would be good for an application. I wouldn't take too much stock in the frequency of keywords here.

After working on a Phoenix project and using LiveView and Tailwind it just makes my brain hurt to think of using anything else. I expect Phoenix is over-represented here because Hacker News tends to attract the smart set.

SvelteKit hosted on Vercel serverless functions.

- Userfront for auth

- Not sure yet about DB/persistence... Supabase? FaunaDB? MongoDB Atlas? Simperium?

I like using ExpressJS with Typescript and a Postgres database. There are lots of great hosting options, but I'm using Heroku right now.

I do really like the Firebase/Superbase options, but they impose restrictions and I don't like having restrictions like that unless I know for a fact that I'm building something very simple.

The Supabase folks are very active on here - if you shared your restrictions, maybe they'll open the up.

(supabase ceo)

We definitely like to receive feedback for improvement. let us know what you're frustrated by @leros.

Sometimes there is context for the restrictions which we haven't shared in the docs, so it would be great to hear it so that we can either fix or clarify.

I'm not unhappy about anything in particular. Superbase is fantastic and many of the upcoming things are things that I'm excited about.

It's just that something I plan to work on for a long time, with lots of people, and that will have lots of business and scaling complexity, I prefer to run my own simple stack so I have full control and don't find myself waiting on someone else's roadmap for a feature I desperately need.

got it, completely fair. thanks for taking the time to respond

Basic REST inspired service made with node and expressjs implementing business logic based interfaces and all data stored in Postgres. Most objects get UUIDv4 identifiers. Logging is with pino. Everything gets kept simple as possible so that junior developers can easily handle operations, basic extensions, or debugging.

React + Apollo GraphQL (on Node) + Mongodb (with Mongoose, possibly hosted on Atlas)

The reason is simple: I'm most comfortable and proficient with this stack and it's scalable enough to run a mid-sized app. Moreover it's very easy to share the code base between web app and mobile app based on expo (React native) if needed.

The stack on which I feel more comfortable right now:

TypeScript on both sides with fp-ts[1], effect-ts[2], Postgres or any random document database with low friction, a random view library that has the best support for jsx and both client/server side rendering (not react).

Any other stack would require me to learn new stuff and eventually slow me down.

Frontend: Elm + Tailwind, Backend: Haskell (or some instant API Generator like Postgrest / Airsequel), Database: SQLite, Automation: n8n / Pipedream / Zapier / …

The strong typing of purely functional languages makes refactoring a breeze and let’s you quickly iterate and move from prototype to production.

Supabase for storage, lambda for backend processing (Twilio, mainly). Front end is all hand written js, pages are statically generated in Hugo. cloudFlare Pages to host.

All free, scalability won’t be a problem since it’s a niche app and db r/w work is minimal. I estimate I can support 10k userbase all for free.

Pocketbase on a very small VPS for the backend and SolidJS + TailwindCSS for the frontend, served using caddy.

I built a SaaS MVP in 2 months (nights and weekends) using Roda + HTMX + Alpine.js + Missing CSS + Postgres. I was quite happy with how moldable Roda is.

I tried rails in conjunction with roda in the first 2 weeks, but I felt far more productive with roda for my use case and stuck with it.

Whatever is easiest to host and has the best module library for the problem domain. Assuming a web app is probably lean towards node on the backend to keep things simple. But really I'd look at platforms like fly.io, vercel, supabase, netlify and build around their defaults.

Choose something from bucket 1 and pair it with an own-cloud PaaS such as what we're building at withcoherence.com! There's nothing that will help you move faster than using well-understood tools with huge ecosystems, and freeing yourself from glue code and internal tooling.

1. Laravel for backend -- continues to be one of the strongest communities & ecosystem and feels beautiful to work with

2. VueJS for frontend

3. Hosted on Laravel Forge (using AWS)

4. Amazon RDS - MySQL (or similar) -- relational databases still solve most of the things I need, unless there were specific reasons to switch to a nosql

5. Tailwind CSS

Rails , it has everything you need to build a reliable MVP fast, with good test coverage and solid architecture design.

1. Rhel 9 (alma/rocky linux) on a vps (don't really matters where, aws, azure, do, hetzner, wherever).

2. Postgres 15

3. Python 3.10/Django 4.x served with gunicorn

4. Jquery and or alpine js

5. Bootstrap 5

6. Caddy to serve everything

7. S3 if a lot of file uploads are needed

--

I'd definitely keep using the same stack post mvp by vertically scaling the db, horizontally scaling the app servers.

Django backend. HTMx on the front end. Possibly an SQLite dB in a mounted volume, or a postgresql server if I need those features and expect more traffic. Might build the django app into a container and host on ECS or another container platform (like on DO or Vultr).

Rails or NextJS on Vercel/Fly/Netlify/wtv, with PlanetScale for the DB. That's it.

- Spring boot (Java 19)

- HTMX + Thymeleaf (replacing need for any SPA framework)

- Bootstrap

- Vanilla JS when needed

- Postgres

- Deploy on Ubuntu server with a deploy.sh that just does cd => git pull => gradlew build => systemctl restart X.service :)

Why? I have been convinced that most web application can and should be created without JS frameworks :P

T3 stack (Next.js, tRPC, Prisma with MySQL, NextAuth, either Tailwind or a component library depending on the project), deployed to Vercel. Maybe swap Prisma for Kysely if cold starts become an issue.

Disclaimer: I maintain an init tool for this stack so I'm somewhat biased

Python: SQLite ORM with PeeWee + realtime UI with DashPlotly https://betterprogramming.pub/dash-is-deeper-than-dashboards...

I'm currently moving from Rails to RedwoodJS (https://redwoodjs.com/) and loving it. The framework is very well integrated and built around its components.

5. JakartaEE for the backend, Jakarta Faces + Primefaces for the front end, redis for the db, Javalin if API endpoints must be provided. Hetzner server. Only pain point would be the NGINX config, always non trivial.

Why? Very simple, fully featured, ready to scale.

Back-end: - Python 3.10 or 3.11 - Cloud functions 2nd gen as first choice (most pipelines & simple APIs) - Cloud run for (more advanced) APIs with FastAPI

Databases - Firestore for front-end related data - BigQuery for Analytics

Front-end - ReactJS with Hooks - MUI Material

Because in my experience MVP at first is a marketing test, not functionality - I need something to easily put text and images down :)

...So - anything. Simple WordPress page with some content builder would work.

No need to invent functionality before testing out the need.

I wish i could use Go, but we are not there yet framework-wise, so I'm either using Phoenix or Rails, depending for the team.

If the code is planned to be a separate React + API app, for example because React Native will be used, the I'd use Go

If you are already using postgres, then postgrest for backend, and solidJS for front end.

Frontend: React + React Query.

Backend:

* Java Spring if it looks like monolith.

* Golang if it looks like microservice architecture.

Postgres for data.

S3 for blobs.

RabbitMQ for queues.

Kubernetes for infrastructure. Managed or self-hosted, doesn't matter. One 16GB VPS is good enough for start and can be scaled later.

That's my approach to any architecture today.

you and i have a pretty similar preference!

I am sticking to Typescript nowadays, its so easy to share types between FE and BE, creates monorepo with many different packages.

I am in fact building MVP right now with Nextjs and Nestjs, i've never felt more productive than this

I'm building my first solo MVP using Falcon. The product will be REST API only with the exception of signup/payment pages, although a friend is helping with that in Laravel, as webdev is his thing.

For hosting I'll use Hetzner.

Django-Ninja but in Lambda with an RDS Postgres backend and a Vue/TS frontend. Why? Because it's what I know. It's on my agenda to learn more about Elixir. I think it really depends on what the MVP is for!

I am working on a boilerplate as below. I normally use nextjs. But instead of dealing with SSR issues I will try to solve it with a tool like prerender.

backend: express + prisma + sqlite

frontend: vite + react + react-query + chakra-ui + zustand

infra: cloud run, prerender

WordPress + mysql

My current go-to are: 1. Go (echo/gin) or Rust(actix/axum) (old-fashioned server-side rendered HTML) 2. alpine.js 3. htmx.org 4. tailwind

I've found that combination to give me amazing DX and appropriate speed of development.

Django for the backend, Bootstrap for the frontend.

I actually prefer Flask and SQLAlchemy, but I haven't found anything to beat Django for sheer "ten minute POC lets-do-the-show-right-here" pulling something out my arse.

AWS Serverless -- all day long...

Lambda, DynamoDB, API G/W, SNS/SQS, EventBridge, S3, Cloudfront.

Reasons: no servers, no VPCs, no k8s yaml, great tooling, easy to deploy (serverless framework, terraform, etc), easy to secure.

oh, and extremely cheap.

Supabase is very resource intensive. Django+drf+ spectacular+filters+jwt gives you all the perks of supabase with - much easier syntax - much lighter weight - alot higher productivity - UI auto generation

I am curious to know more, can you point me in the direction of any blog posts outlining this stack? I have been using supabase for a few months and for local dev it is pretty heavy

> for local dev it is pretty heavy

We were discussing this in our CLI catchup this morning. It seems the Dashboard/Studio is the main culprit here. We'll fix it

Kotlin. Seems like the true successor to Java rather than Go. Comparable speed but much more enjoyable than Go due better type system, quality of life features, and the massive ecosystem of Java.

Current word count:

* javascript / js: 95

* rails: 89

* django: 86

* postgres / postgresql: 77

* react: 75

* python: 52

* supabase: 52

* elixir: 44

* ts / typescript: 41

* nextjs: 31

* sqlite: 29

* laravel: 28

* vue: 27

* phoenix: 27

* net: 26

* htmx: 23

* node: 23

* html: 20

* github: 20

* tailwind: 18

* rust: 18

* ruby: 18

* aws: 17

* vercel: 16

* prisma: 16

* docker: 16

* graphql: 15

* firebase: 15

* php: 14

* flask: 13

* svelte: 13

* hotwire: 13

* liveview: 12

* curl: 12

* grep: 12

* bootstrap: 11

* fastapi: 11

* spa: 11

* java: 11

* linux: 10

* express: 10

* sveltekit: 10

* go: 10

won't be fair if you don't seperate frontend and backend , because theres no much choice in frontend land other than JavaScript.

I would use Supabase for the database and user auth system, I'd use Elixir/Phoenix for the business logic, and I'd use Phoenix LiveView for the front end, with Tailwind for the CSS.

<half-joking> https://github.com/TheAppleTucker/backend-GPT </half-joking>

https://www.youtube.com/watch?v=QTJRwKOFddc

Smalltalk, Squeak, Pharo, Seaside, PierCMS, Lively Kernel

Used by several succesful startups.

Ruby on Rails 100%. I can have a web app with user/pass authentication in less than 1h. Combine that with TailwindCSS and you have a modern looking app in no time.

Probably Svelte + Node.js.

I don't have any experience with Svelte yet, but I hear good things about it compared to other front-end frameworks. I'd definitely want to separate front and backend.

Infra: AWS EKS or GKE

Backend: Go and its ecosystem

Frontend: jQuery & Bootstrap

Database: Depends on the idea

I can make fairly complicated UI interaction with these, I am crazy fast with these, and I have confidence that I can scale it as well.

i’ve been using django/postgres for over a decade. if it were 5 years ago, i’d use django/postgres for every project.

but recently i would use cloudflare pages, r2, d1, zero trust… in many cases, we don’t want to put eggs in the same basket. but in some cases (eg, building mvp, toy projects…), it’s convenient to be on an all-in-one platform .

for example, i recently launched a cms entirely on cloudflare: https://www.microfeed.org/

Scala + Scala.js

The advantages of writing everything in the one language is massive.

Agree, I have been using Scala.js for many years and there is no going back to js/ts.

Spring Boot + Hilla (https://hilla.dev) + PostgreSQL, deployed on a Digital Ocean VM, possibly behind CloudFlare.

Definitely 1., velocity is kind of predictable, it's cheap and easier when working with more people. I like also more up-to-date stacks but collaboration is more tricky I think

Maybe the standard Node and React on the front end? Tried too many niche languages and technologies and now I always come back to JS to stick to the same platform for everything

Laravel + htmx + sqlite + Bootstrap

I'm currently making something with these for the first time. I picked sqlite because it's convenient and seems to be supported on free hosting.

What free hosting supports SQLite?

https://byet.host/ last time I checked, but I haven't actually test it yet. And a quick google comes up with this too https://heliohost.org/

tRPC is incredible. I can imagine most businesses doing just fine with a single VPS on Vercel with a static React frontend and a tRPC backend. The iteration time is insane.

The preferred stack will be Django with DRF and maybe some htmx, SQLite and deployed on DO app platform.

Alternatively, NextJS with Firebase (or any other cloud DB) and deployed at Vercel.

Sveltekit and Supabase. I can have a portable, auto scaling serverless app running with auth and user accounts / CI CD in like 3 cli commands for $0.

To get started? SvelteKit with SQLite (+Prisma).

To scale: 1. N number of VPSes distributed around the world with LiteFS (most likely Hetzner)

2. SvelteKit and SQLite (with Prisma)

3. Anycast Service to direct traffic

Google Cloud Run or some similar scalable container-based abstraction. Off the shelf auth and DBaaS.

I have a lot of opinions on frontend stack too but they vary based on product.

Both old school and new school. Best of both worlds.

Java 17 Quarkus backends with GraphQL, PostgreSQL as DB

Hasura to stitch the APIs if needed

logto.io for AuthX

Svelte with Sveltekit, Tailwind, DaisyUI as a frontend

Typescript, Tailwind, NextJS, Supabase, Vercel and you just can’t go wrong.

If I needed a long running server for whatever reason I’d supplement Supabase with a NestJS app.

Front end: TypeScript, Vite, React, FontAwesome, Radix UI, lodash, React Router, zod, SCSS.

Back end: Python, mypy, Django, Django REST Framework, Celery, Redis, PostgreSQL

Django. It can run anywhere, including in lambdas, and I prefer having a solid piece of back-end that won’t crumble when I start changing data models.

I like Svelte Kit for my UI and backend together since most things I'm building don't need a public API. It makes it easy to work full stack.

Data: Postgres & Hasura (for me Hasura is the goldilocks level of abstraction - lets me skip writing CRUD handlers, but doesn't get in the way either when I need to do something complex).

Frontend: TypeScript, React, apollo client, graphql-code-generator, tailwind

Backend Logic: Lambda functions written in TS, packaged with serverless.com, but deployed with Terraform

CI: GH Actions

Deployment: AWS via Terraform. One account per environment under an umbrella org.

Because I've used this stack so many times I can get a "shovel ready" foundation going in minutes with a skeleton that I've been iterating on.

And god protects us if some day you leave the project and somebody else has to come and understand these setups.

I bet you know this very well and you’re very productive with this, but just imagine the next person having to pick it up.

That’s where full stack batteries included frameworks shine… you know what to expect and how things fit together, you just need to figure out the business logic.

Besides Hasura, every element of the stack is either the dominant tool in the market or one of the most dominant tools in the market (terraform). Hasura is pretty thin and not too hard to pick up.

Please enlighten me as to which “batteries included frameworks” have the market dominance of AWS, React, TypeScript, and Terraform?