Hacker News Reader

Comment by chrismorgan | Hacker News Reader

The problem isn’t web tech, but rather software (of any kind) that is designed without performance in mind from the start, and by large teams. Something functionally-similar, still using web tech, but produced by one or two developers who care about performance (and yes, I seriously suggest this would be feasible) and are given free rein to do so would be better, lighter and faster than something “native” produced by a similar team to that which has made their existing apps.

Web tech is easy. This incidentally makes stuff built with it likely to be slower. Especially when you have a whole bunch of developers working on a thing. I have come to the conclusion that large teams more or less cannot produce good results by these sorts of measures.

I suspect also (without ever having used it) that a good chunk of Teams’ slowness will be in communications pieces that are nothing to do with web tech.

View on HN

> I suspect also (without ever having used it) that a good chunk of Teams’ slowness will be in communications pieces that are nothing to do with web tech.

Ding ding ding. This is the winner. I have yet to see someone who is bitching about Electron actually show that the render time in the client is really what's causing the performance issues.

Almost always the issue is that fetching/updating a remote resource is just slow. It's SO freaking slow compared to local access.

Worse - almost every other aspect of computing is actually getting quite a bit faster, but RTT isn't going to change.

---

In this case, I'm willing to bet actual money that most of the speedup is hiding in what they're calling the "Client data layer" here: https://techcrunch.com/wp-content/uploads/2023/03/new_teams_...

It sort of is the webstack since most of it was designed when bandwidth was the biggest bottleneck.

No one planned for a situation where you have a rats nest or 100’s of MB and sometimes even GBs of JavaScript code running in a browser, since just like with the 140K of RAM or w/e it was is enough for everyone one then JavaScript and the existing patterns were good enough when no one could load enough of it to cause actual performance concerns in the first place.

Its absurd that these products whose companies get bought for Billion+ can't have a team of 3-5 engineers focused on performance.

I understand that you have lots of people building features but I'm sure the performance engineering efforts can be focused on the fundamental platform layers which are seen in most flame-graphs.

Its also exactly these companies that grill you on performance and leet-code type problems but ship nothing like what they interview for.

Companies are terrible at tech. They don't know enough to make informed reasonable decisions.

Picking good smart architectures is so hard. The people least capable of judging have tons of power & they almost all push for simpler, almost always minize the challenges.

I wonder if some of that is just part of the incentives of a 2 person team vs a 20-200 person team. 2 people get praise for shipping it, 20 people get (individual) praise for “managing complexity”.

Reply on news.ycombinator.com