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.
Ask HN: What would be your stack if you are building an MVP today?
711–720 of 736 posts
Re: Ask HN: What would be your stack if you are building an MVP today?
#712Re: Ask HN: What would be your stack if you are building an MVP today?
#713Re: Ask HN: What would be your stack if you are building an MVP today?
#714Earlier quoted context omitted.
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?
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.
Re: Ask HN: What would be your stack if you are building an MVP today?
#715Earlier quoted context omitted.
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 p…
Re: Ask HN: What would be your stack if you are building an MVP today?
#716Earlier quoted context omitted.
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 - Bac…
Maybe next js instead of supabase?
Re: Ask HN: What would be your stack if you are building an MVP today?
#717Earlier quoted context omitted.
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://prag…
Re: Ask HN: What would be your stack if you are building an MVP today?
#718Earlier quoted context omitted.
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 p…
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
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 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.
Re: Ask HN: What would be your stack if you are building an MVP today?
#719Laravel + 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?
Re: Ask HN: What would be your stack if you are building an MVP today?
#720Earlier quoted context omitted.
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 crea…