> As a small team, we need to ship fast.
So they chose a solution that required them to:
> Spent almost a month prototyping
> there was no real ecosystem for Go-app UI components and we knew we’d have to write our own
> Go WASM is slow at parsing large amounts of JSON, which led to dramatic architecture
Not sure what their definition of shipping fast is, since this just sounds like resume oriented programming.
During that investigation you discover things (like having to implement your own components) and try to account for how much they'll subtract from the time and energy you save. If the calculus works out, you keep going. If it doesn't, you stop. We kept going, and now we can ship complex features and optimizations to both UIs within a day or two.
Interesting. I have two wildly different takes on this.
1) Dagger is such an interesting company that they let developers do whatever they want, as long as it works and works well. A good mix of pragmatism and fun.
2) Holy crap, it's a real company with real customers. Why would they attempt something like this in one of their key products, where are the adults?!
But if you claim to be a small team that needs to ship fast, I believe you should just pick the industry standard boring technology and grind away.
The question is to fully see (and boringly like the parent post was talking about) what are the rewards and the risks to decide if it is worth it or not. What if it made the company tanked financially (like you would have to go back to the state before but have to rewrite the rewrite because you had to change the database design in your first rewrite or something) and not be able to ship for another 6 months? Being a small team you don't have all the cash you want unless you already made it big. Also you have to explain to your investors why you won't ship. And really how come you are an expert in tech when you had to redo it from scratch so next time maybe they can reinvest.
This type of decision needs clear planning, reward and risk, and a real business goal to happen. But let's be real many times it's not the case and X is the new cool tech. I am all about being audacious but in a calculated way.
Why hate on people actually enjoying the thing at times when everyone with the boring stack is one round of layoff away from the door?
"Not sure what their definition of shipping fast is, since this just sounds like resume oriented programming."
> So, we ended up with two interfaces trying to accomplish the same thing, one of them in one language and ecosystem (TypeScript/React), the other in a totally different language and ecosystem (Go), and we couldn't easily share business logic between them.
> As a small team, we need to ship fast. Having to re-implement every feature twice was just a massive tax on our velocity.
Oh. Wait. They're cutting away an entire code base and a second language & ecosystem to support. Maybe it's not quite as resume-oriented after all.
We can certainly argue if that was the right way to do this, but it's not like it's an entirely unreasonable resume padding exercise.
and we would all fail system design interviews for considering the same thing
Why?