4 ms·

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 t

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.

MobileVet 4y ago
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)
- rat9988 4y ago
  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.
  - xyzzy_plugh 4y ago
    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.
hot_town 4y ago
you should check out https://wasp-lang.dev https://wasp-lang.dev then. It's probably one of the fastest stacks out there for React + ExpressJS at the moment
shireboy 4y ago
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.
- RussianCow 4y ago
  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.
  - didgetmaster 4y ago
    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.
    - RussianCow 4y ago
      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.

MobileVet 4y ago

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)

rat9988 4y ago
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.
- xyzzy_plugh 4y ago
  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.

hot_town 4y ago

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

shireboy 4y ago

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.

RussianCow 4y ago
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.
- didgetmaster 4y ago
  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.
  - RussianCow 4y ago
    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.