Live data from Hacker News

Ask HN: What would be your stack if you are building an MVP today?

news.ycombinator.com

611–620 of 736 posts

Re: Ask HN: What would be your stack if you are building an MVP today?

#611
post #368

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/cs…

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

[deleted]

Re: Ask HN: What would be your stack if you are building an MVP today?

#612

Earlier quoted context omitted.

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…

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…

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

Re: Ask HN: What would be your stack if you are building an MVP today?

#613

Earlier quoted context omitted.

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 wan…

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

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

Re: Ask HN: What would be your stack if you are building an MVP today?

#614

Earlier quoted context omitted.

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

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

Re: Ask HN: What would be your stack if you are building an MVP today?

#615
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 :)

Re: Ask HN: What would be your stack if you are building an MVP today?

#617

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 overn…

Why opt for managed db?

Re: Ask HN: What would be your stack if you are building an MVP today?

#619

- 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 templatin…

> 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 elem…

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.

Re: Ask HN: What would be your stack if you are building an MVP today?

#620

Earlier quoted context omitted.

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

> 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 tho…

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?

Post reply on HN