4 ms·

Early in the post: > 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 n

by kabes 2y ago

Early in the post: > 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.

hnlurker22 2y ago
It simply means that, for their purposes, React wasn't good enough. Personally, I applaud any effort that doesn't use React.
- hnlurker22 2y ago
  >We had some very good reasons to do it: a team of strong Go engineers; a complex UI that TypeScript/React didn't scale well for
  - yieldcrv 2y ago
    Because its a bullshit assessment, they ran into the same limitations in their obscure choice, they didn’t move fast and break things, and both choices have optimizations to deal with these problems and we would all fail system design interviews for considering the same thing
- deleted 2y ago
  [deleted]
- zero_shift 2y ago
  > Personally, I applaud any effort that doesn't use React. Why?
  - hnlurker22 2y ago
    There needs to be competition
jeswin 2y ago
> I spent a lot of time figuring out how to render 200k+ lines of log output without crashing. This led to optimizations deep in our virtual terminal rendering library... 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?!
- Muromec 2y ago
  The adults would make a quarterly plan, schedule 16 hours of meeting each week, 4x the head count and put everyone into a silo. And then nothing gets done except next quarter.
  - bdelmas 2y ago
    Is it? What if instead it was another “We did a full rewrite and it was a mistake. Here is why” type of postmortem?
    - Muromec 2y ago
      I could have been, but it wasn't so far. And even if it was, there is a lot of things to learn in such mistakes. Audacity of doing the ambitious thing and the newly gained experience of why not doing it is how we get experienced people in the industry. Otherwise it's just dogma and nobody breaks past the established practices, which are always suboptimal.
      - kabes 2y ago
        Sure, if you're like uber at the peak of over-hiring and have hundreds of engineers more than you actually need. Then go ahead and try to reinvent things and hopefully you'll be able to improve the status quo. 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.
Muromec 2y ago
It sounds like people having fun, which means they would care more and ship faster if it works out. If it doesn't work out, they will do something boring. 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?
- pwdisswordfishz 2y ago
  Why call every little disagreement and pointing out of inconsistency "hate"?
  - politelemon 2y ago
    The comment in GP is not a 'disagreement', it is just bad faith. "Not sure what their definition of shipping fast is, since this just sounds like resume oriented programming."
    - pwdisswordfishz 2y ago
      It's not allowed to disbelieve someone's claims, especially given evidence to the contrary?
  - Muromec 2y ago
    Disagreement on values, especially coupled with outright dismissal falls into the hate category for me.
andrewstuart 2y ago
What could this company possibly doing that can't be handled by react or Vue or Vanilla or whatever the myriad other ones are?
pjmlp 2y ago
Definitely, if there as a gold lesson I had with WebForms and JSF, was that frameworks that abstract the way that browser APIs work, without debugging tool for those additional cake layers are not what I want to spend my time on, unless I am told that is the way by higher ups.
vito 2y ago
What you aren't including is the chronic cost of maintaining the status quo, which is the entire reason for making the change. Sometimes making no decision costs you more than making a risky one - and if the decision is risky, you'll want to investigate it first. 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.
groby_b 2y ago
I mean, with selective quoting you can make any point you want. Let's do the full quote: > 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.

by kabes 2y ago

hnlurker22 2y ago

It simply means that, for their purposes, React wasn't good enough. Personally, I applaud any effort that doesn't use React.

hnlurker22 2y ago
>We had some very good reasons to do it: a team of strong Go engineers; a complex UI that TypeScript/React didn't scale well for
- yieldcrv 2y ago
  Because its a bullshit assessment, they ran into the same limitations in their obscure choice, they didn’t move fast and break things, and both choices have optimizations to deal with these problems and we would all fail system design interviews for considering the same thing
deleted 2y ago
[deleted]
zero_shift 2y ago
> Personally, I applaud any effort that doesn't use React. Why?
- hnlurker22 2y ago
  There needs to be competition

jeswin 2y ago

> I spent a lot of time figuring out how to render 200k+ lines of log output without crashing. This led to optimizations deep in our virtual terminal rendering library... 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?!

Muromec 2y ago
The adults would make a quarterly plan, schedule 16 hours of meeting each week, 4x the head count and put everyone into a silo. And then nothing gets done except next quarter.
- bdelmas 2y ago
  Is it? What if instead it was another “We did a full rewrite and it was a mistake. Here is why” type of postmortem?
  - Muromec 2y ago
    I could have been, but it wasn't so far. And even if it was, there is a lot of things to learn in such mistakes. Audacity of doing the ambitious thing and the newly gained experience of why not doing it is how we get experienced people in the industry. Otherwise it's just dogma and nobody breaks past the established practices, which are always suboptimal.
    - kabes 2y ago
      Sure, if you're like uber at the peak of over-hiring and have hundreds of engineers more than you actually need. Then go ahead and try to reinvent things and hopefully you'll be able to improve the status quo. 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.

Muromec 2y ago

It sounds like people having fun, which means they would care more and ship faster if it works out. If it doesn't work out, they will do something boring. 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?

pwdisswordfishz 2y ago
Why call every little disagreement and pointing out of inconsistency "hate"?
- politelemon 2y ago
  The comment in GP is not a 'disagreement', it is just bad faith. "Not sure what their definition of shipping fast is, since this just sounds like resume oriented programming."
  - pwdisswordfishz 2y ago
    It's not allowed to disbelieve someone's claims, especially given evidence to the contrary?
- Muromec 2y ago
  Disagreement on values, especially coupled with outright dismissal falls into the hate category for me.

andrewstuart 2y ago

What could this company possibly doing that can't be handled by react or Vue or Vanilla or whatever the myriad other ones are?

pjmlp 2y ago

Definitely, if there as a gold lesson I had with WebForms and JSF, was that frameworks that abstract the way that browser APIs work, without debugging tool for those additional cake layers are not what I want to spend my time on, unless I am told that is the way by higher ups.

vito 2y ago

What you aren't including is the chronic cost of maintaining the status quo, which is the entire reason for making the change. Sometimes making no decision costs you more than making a risky one - and if the decision is risky, you'll want to investigate it first. 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.

groby_b 2y ago

I mean, with selective quoting you can make any point you want. Let's do the full quote: > 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.