4 ms·

Am convinced there exists web tech that enables you to move fast enough without requiring a full rewrite once you confirm product market fit. Preferably with fi

Am convinced there exists web tech that enables you to move fast enough without requiring a full rewrite once you confirm product market fit. Preferably with first class type safety throughout (rules out RoR/Django). In ye olden days, we referred to this as “skill,” but I’m more sure we’re allowed to talk like that now :)

cultofmetatron 3y ago
Phoenix framework is what you're looking for. I can build out mvps as quickly as in django/ror but the runtime perf is on par with go or rust (for io bound stuff) Been in operation for 3 years and scaling has come out though incremental improvements. no large scale rewrites needed. 1. out of the bod req/res time is fast 2. multiclustered websockets come out of the box with channels for subscribing to events 3. easy to spin up a "service" as a genserver 4. best ecosystem of tooling for building asynchronous and parrallel systems 5. liveview is THE standard for reactive frontend frameworks where you are updating in real time from serverside html. (no shade thrown on rails but hotwire is a joke by comparison) liveview processers are persistent for the live of teh user session and can subscribe to server side events so you can have a user make a request, push the task into the background and update the ui when its completed with very little code. ok so type safety isn't at ocaml, rust or haskell level but its good enough that Its rarely the source of bugs assuming you perform even minimal testing.
- eropple 3y ago
  Phoenix is quite nice if you're coming to it from a dynamically-typed environment, but I'd strongly dispute that its type system is "good enough" at large (human, not technological) scales. Phoenix itself makes good decisions in a lot of places but it relies on things like Ecto for database manipulation, which (as just one example) is absolutely not enough for substantiative, human-scalable development--your "minimal testing" is my, as even a comparatively easygoing TypeScript-down-the-stack enjoyer, a whole lot of extra stuff. It also faces impedance mismatch with a lot of cloud tooling--which is not a disqualifier by itself and BEAM might not even be wrong, but most Elixir-in-anger systems I've seen end up abandoning much of the benefit of BEAM clustering and running a bunch of horizontally scaled web applications because they've got containers to manage and it fits the overall get-it-out-the-door plan better. This makes things like "just add another genserver" not really map to reality all that well, though of course genservers are a good layer of abstraction and modularization on their own. LiveView is great, though. I am hopeful for React server components and server actions to continue to mature; they're promising as it is.
  - cultofmetatron 3y ago
    > is absolutely not enough for substantiative, human-scalable development you'll have to elaborate there. we have a pretty large codebase at this point that serves 3 different apps. granted our engineering staff is small but thats exactly what makes elxiir so great. It lets you build scalable infrastructure with a small team of humans > most Elixir-in-anger systems I've seen end up abandoning much of the benefit of BEAM clustering and running a bunch of horizontally scaled web applications because they've got containers to manage and it fits the overall get-it-out-the-door plan better. containers and clustering are not mutually exclusive. we run a elxiir cluster and take advantage of that with shared data and the ability to send mesages between each machine in pure elixir. At the same time, each vm is running inside a docker container managed with kubernetes. they work well together. we had one instance where a vm went down and kubernetes immediately brought it back up followed with it connecting to its peers.
Kalium 3y ago
It's never product-market fit that requires a rewrite. It's bumping into the limits of the tools you chose up front. In my experience, that's mostly a function of how technologically wrong your guesswork was. If you set out to build cloud cost tracking but mostly build AWS accounting, that's pretty close and you'll likely do fine. If you set out to build games and wind up finding fit with an enterprise chat system, you're likely to end of with a full rewrite no matter what web tech you started with. In other words, I don't think there is any web tech that does this because it's all about what's between the ears of humans.
Zetice 3y ago
Why avoid the rewrite? Why require your work to be "skillful" in the first place? Wouldn't it be better to focus all of your time and effort on the hardest problem of all, finding customers, and leave whatever wisps of brainpower you have left to the initial implementation, until you can hire people dedicated to that task? Engineers think a tech startup is mostly tech, but in reality it's almost no tech at first. In fact, the more tech you introduce early, the worse off you are.

cultofmetatron 3y ago

Phoenix framework is what you're looking for. I can build out mvps as quickly as in django/ror but the runtime perf is on par with go or rust (for io bound stuff) Been in operation for 3 years and scaling has come out though incremental improvements. no large scale rewrites needed. 1. out of the bod req/res time is fast 2. multiclustered websockets come out of the box with channels for subscribing to events 3. easy to spin up a "service" as a genserver 4. best ecosystem of tooling for building asynchronous and parrallel systems 5. liveview is THE standard for reactive frontend frameworks where you are updating in real time from serverside html. (no shade thrown on rails but hotwire is a joke by comparison) liveview processers are persistent for the live of teh user session and can subscribe to server side events so you can have a user make a request, push the task into the background and update the ui when its completed with very little code. ok so type safety isn't at ocaml, rust or haskell level but its good enough that Its rarely the source of bugs assuming you perform even minimal testing.

eropple 3y ago
Phoenix is quite nice if you're coming to it from a dynamically-typed environment, but I'd strongly dispute that its type system is "good enough" at large (human, not technological) scales. Phoenix itself makes good decisions in a lot of places but it relies on things like Ecto for database manipulation, which (as just one example) is absolutely not enough for substantiative, human-scalable development--your "minimal testing" is my, as even a comparatively easygoing TypeScript-down-the-stack enjoyer, a whole lot of extra stuff. It also faces impedance mismatch with a lot of cloud tooling--which is not a disqualifier by itself and BEAM might not even be wrong, but most Elixir-in-anger systems I've seen end up abandoning much of the benefit of BEAM clustering and running a bunch of horizontally scaled web applications because they've got containers to manage and it fits the overall get-it-out-the-door plan better. This makes things like "just add another genserver" not really map to reality all that well, though of course genservers are a good layer of abstraction and modularization on their own. LiveView is great, though. I am hopeful for React server components and server actions to continue to mature; they're promising as it is.
- cultofmetatron 3y ago
  > is absolutely not enough for substantiative, human-scalable development you'll have to elaborate there. we have a pretty large codebase at this point that serves 3 different apps. granted our engineering staff is small but thats exactly what makes elxiir so great. It lets you build scalable infrastructure with a small team of humans > most Elixir-in-anger systems I've seen end up abandoning much of the benefit of BEAM clustering and running a bunch of horizontally scaled web applications because they've got containers to manage and it fits the overall get-it-out-the-door plan better. containers and clustering are not mutually exclusive. we run a elxiir cluster and take advantage of that with shared data and the ability to send mesages between each machine in pure elixir. At the same time, each vm is running inside a docker container managed with kubernetes. they work well together. we had one instance where a vm went down and kubernetes immediately brought it back up followed with it connecting to its peers.

Kalium 3y ago

It's never product-market fit that requires a rewrite. It's bumping into the limits of the tools you chose up front. In my experience, that's mostly a function of how technologically wrong your guesswork was. If you set out to build cloud cost tracking but mostly build AWS accounting, that's pretty close and you'll likely do fine. If you set out to build games and wind up finding fit with an enterprise chat system, you're likely to end of with a full rewrite no matter what web tech you started with. In other words, I don't think there is any web tech that does this because it's all about what's between the ears of humans.

Zetice 3y ago

Why avoid the rewrite? Why require your work to be "skillful" in the first place? Wouldn't it be better to focus all of your time and effort on the hardest problem of all, finding customers, and leave whatever wisps of brainpower you have left to the initial implementation, until you can hire people dedicated to that task? Engineers think a tech startup is mostly tech, but in reality it's almost no tech at first. In fact, the more tech you introduce early, the worse off you are.