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

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?

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

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

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

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

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.

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.

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.

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

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

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.

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.

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.

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.

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

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

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.

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

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.

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?

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.

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

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.

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.

Compared to that JS ecosystem perhaps has too much :)

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!

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.

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

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.

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.

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.

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.

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.

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.

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 love Django. It's criminally underrated.

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

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.

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.

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.

Is it this one?

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

I know there is a paid one.

[1] https://inertiajs.com/

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

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

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.

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.

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.

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.

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.

Edit: and it' still maintained !

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

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.

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.

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.

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

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.

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?".

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'

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

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

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

   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

Edit:

apt install grepgpt

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

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.

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.

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

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.

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

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.

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.

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

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

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

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

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

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.

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.

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.

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

It eliminates entire classes of human errors.

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

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.

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.

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.

> 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

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.

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)

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.

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

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.

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.

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.

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

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

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 know of Andrew Culver through Twitter and he seems like a genuinely nice person.

https://avohq.io

It looks beautiful Adrian.

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!

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.

Why:

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

- speed of development

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

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.

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.

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.

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.