3 ms·

Problem: Product was created with the modern idea that optimization=evil. Solution: Rewrite product, using essentially the same architecture (Chrome renderer w

by nikanj 5y ago

Problem: Product was created with the modern idea that optimization=evil. Solution: Rewrite product, using essentially the same architecture (Chrome renderer wrapped in native exe) We'll end up with similar levels of performance, but an entirely new host of exciting bugs

vineyardmike 5y ago
> optimization=evil Is that really why people turn to electron though? I'm pretty sure its not.
- kasabali 5y ago
  It may not be the reason but it sure is used as a justification.
- nikanj 5y ago
  The main problem with Teams isn't Electron. The Chrome renderer is state-of-the art and V8 is an excellent JS runtime. The problem is writing code for code reviews, not for users. You can't add a performance-aware architecture as an afterthought, and it's really hard to fix your code with a profiler if every single operation is slower than necessary. On a very general level, modern development often encourages "elegance" as in "code looks nice". Small things like looping through an array by creating an anonymous lambda function, creating an array-looping promise using that lambda, etc. What used to be one int, one comparison and one increment, is now fifteen objects created, seven levels of indirection and at least a few library calls. This gets you software that manages to not keep up with my typing speed on a multi-gigahertz processor. It's not any single line of code that's hogging the cycles, and it's not fixable by changing the runtime from one Chrome variant to another. The code looks much nicer though, I'm not denying that.
  - ptx 5y ago
    > V8 is an excellent JS runtime Doesn't Electron use two instances of it though, one for Node.js and one for the browser UI, with some sort of message-passing inbetween? That would tend to slow things down.
  - carlmr 5y ago
    >What used to be one int, one comparison and one increment, is now fifteen objects created, seven levels of indirection and at least a few library calls. This sounds like the 90s-2000s enterprise OOP GoF pattern nightmares. I'm not sure lambdas are at fault here, since most languages can efficiently handle those. To me the not too crazy functional programming resurgence is actually relief from these object hierarchies distributed over many files which the computer and I don't like. Of course the architecture astronauts are still out and about talking about adding levels of indirection we can't even imagine yet

by nikanj 5y ago

vineyardmike 5y ago

> optimization=evil Is that really why people turn to electron though? I'm pretty sure its not.

kasabali 5y ago
It may not be the reason but it sure is used as a justification.
nikanj 5y ago
The main problem with Teams isn't Electron. The Chrome renderer is state-of-the art and V8 is an excellent JS runtime. The problem is writing code for code reviews, not for users. You can't add a performance-aware architecture as an afterthought, and it's really hard to fix your code with a profiler if every single operation is slower than necessary. On a very general level, modern development often encourages "elegance" as in "code looks nice". Small things like looping through an array by creating an anonymous lambda function, creating an array-looping promise using that lambda, etc. What used to be one int, one comparison and one increment, is now fifteen objects created, seven levels of indirection and at least a few library calls. This gets you software that manages to not keep up with my typing speed on a multi-gigahertz processor. It's not any single line of code that's hogging the cycles, and it's not fixable by changing the runtime from one Chrome variant to another. The code looks much nicer though, I'm not denying that.
- ptx 5y ago
  > V8 is an excellent JS runtime Doesn't Electron use two instances of it though, one for Node.js and one for the browser UI, with some sort of message-passing inbetween? That would tend to slow things down.
- carlmr 5y ago
  >What used to be one int, one comparison and one increment, is now fifteen objects created, seven levels of indirection and at least a few library calls. This sounds like the 90s-2000s enterprise OOP GoF pattern nightmares. I'm not sure lambdas are at fault here, since most languages can efficiently handle those. To me the not too crazy functional programming resurgence is actually relief from these object hierarchies distributed over many files which the computer and I don't like. Of course the architecture astronauts are still out and about talking about adding levels of indirection we can't even imagine yet