5 ms·

>It will likely change your outlook on the future of desktop software. :) Slow, with a 100MB node runtime eating up an entire CPU, piling hacks on hacks on Rea

by pikzen 10y ago

>It will likely change your outlook on the future of desktop software. :) Slow, with a 100MB node runtime eating up an entire CPU, piling hacks on hacks on React on top of the DOM, being dependant on Google's will to develop V8, written in JavaScript? That sounds like a pretty damn bleak future to me.

moondev 10y ago
A whole 100MB... GASP! Meanwhile native MS Office on osx takes up almost 7GB.
- pikzen 10y ago
  * I meant 100MB memory footprint. Office doesn't have a 7GB footprint. * Office being a behemoth doesn't give a right to other apps to be whales. * 100MB is just the runtime. Then you've got your application running on top of that, using whatever memory you want. The C/C++ runtime is not 100MB. * Those 7GB probably include examples, layouts, whatever. Actual content. As opposed to Electron apps which are rarely more than just pretty interfaces making requests to a server. (With some high profile exceptions, like Atom, VSCode, ... Although they do send data to outside servers anyways :^)) * The Office suite is infinitely more complicated than anything done with Electron. That means features, technical debt, everything. * Office isn't running in fucking Javascript
  - oceanswave 10y ago
    Oh really? * Excel alone uses 86.1MB of private memory, and 142MB on a Blank Workbook. * Where did you get this 100MB metric? VS Code uses 24MB Private, 86MB shared and I've got a ton of extensions added. * No, most electron apps are offline apps. * I doubt it. Creating performant HTML layouts and WebGL rendering all verified by independent 3rd party test suites is hard, dude. If someone came to you and said "Build a HTML engine or build Word" which would you choose? * O'rly? Office 2016 add ins are built in JS, and there are built-in "addins"
    - pikzen 10y ago
      >Excel alone uses 86.1MB of private memory, and 142MB on a Blank Workbook. That is excel. With all its features. 100MB is Electron's base footprint. Running absolutely nothing. Write something as complex as excel with the same feature set, you're going to be way over 142MB with a blank workbook ;) The 100MB metric comes from experimentation with both electron and electron based apps (VS Code, Atom, N1, Slack, ...). The main process hovers at around 80MB, but you also have countless node processes running. When node will be a default on machines (please, never), I'll stop adding those processes to the total, but meanwhile, they do count. >I doubt it. Creating performant HTML layouts and WebGL rendering all verified by independent 3rd party test suites is hard, dude. If someone came to you and said "Build a HTML engine or build Word" which would you choose? A) The electron developers do not develop a rendering engine. They do not develop a JS VM either. They develop a toolkit for desktop apps, which uses nodejs (which is highly dependent on Google not pulling the plug on V8) as well as Blink (which is highly dependent on Google). While I am not discounting their work, they are absolutely not the ones with their hands in the engine internals. B) I would honestly build a rendering engine. Word has 25 years of backwards compatibility to keep, features and integrations with lots of other office software, etc. Rendering engines have a clear and defined spec. Microsoft hasn't clearly defined the DOCX spec (well, they did, but keep adding undocumented surprises. Just like XLS :^). C) I'd ask for a team, because no single human being can replicate the feature set of either in his lifetime. Add-ins in JS? Sure, run them in an another thread and keep them out of performant code and we'll be friends.
  - TheCoreh 10y ago
    > Office isn't running in fucking Javascript Yet. ;)
    - moondev 10y ago
      Already is! https://office.live.com/start/Word.aspx https://office.live.com/start/Word.aspx
  - ConAntonakos 10y ago
    Why the aversion towards JavaScript? It's steadily improving, albeit slowly, with massive support from many players.
    - ntauthority 10y ago
      Not in the least, it's dynamically-typed with ecosystem libraries removing APIs by the dozen (upgrade your dependencies? prepare for days of verifying runtime errors of missing functions), and TypeScript is still a second-class citizen even despite the increasing amount of TypeScript-first libraries (like Angular2)...
tracker1 10y ago
Other than a little startup lag VS Code which runs on top of Electron performs very well on my computers, though they all have SSDs. As to performance and memory footprint vs. a statically compiled language/platform, yes, it's a bit heavier... that said, people are writing useful software with it, and able to deploy it cross platform, with minimal additional effort, and able to re-use components build for web based versions. It's not ideal for some apps, but it's completely serviceable for most apps.
- pikzen 10y ago
  Oh I'm not contesting the fact that it's serviceable. Our job is to deliver software. I'm just slightly concerned by the absolute disregard for performance and power usage that is implied by using Electron.
ConAntonakos 10y ago
Isn't V8 open source? https://github.com/v8/v8 https://github.com/v8/v8

by pikzen 10y ago

moondev 10y ago

A whole 100MB... GASP! Meanwhile native MS Office on osx takes up almost 7GB.

pikzen 10y ago
* I meant 100MB memory footprint. Office doesn't have a 7GB footprint. * Office being a behemoth doesn't give a right to other apps to be whales. * 100MB is just the runtime. Then you've got your application running on top of that, using whatever memory you want. The C/C++ runtime is not 100MB. * Those 7GB probably include examples, layouts, whatever. Actual content. As opposed to Electron apps which are rarely more than just pretty interfaces making requests to a server. (With some high profile exceptions, like Atom, VSCode, ... Although they do send data to outside servers anyways :^)) * The Office suite is infinitely more complicated than anything done with Electron. That means features, technical debt, everything. * Office isn't running in fucking Javascript
- oceanswave 10y ago
  Oh really? * Excel alone uses 86.1MB of private memory, and 142MB on a Blank Workbook. * Where did you get this 100MB metric? VS Code uses 24MB Private, 86MB shared and I've got a ton of extensions added. * No, most electron apps are offline apps. * I doubt it. Creating performant HTML layouts and WebGL rendering all verified by independent 3rd party test suites is hard, dude. If someone came to you and said "Build a HTML engine or build Word" which would you choose? * O'rly? Office 2016 add ins are built in JS, and there are built-in "addins"
  - pikzen 10y ago
    >Excel alone uses 86.1MB of private memory, and 142MB on a Blank Workbook. That is excel. With all its features. 100MB is Electron's base footprint. Running absolutely nothing. Write something as complex as excel with the same feature set, you're going to be way over 142MB with a blank workbook ;) The 100MB metric comes from experimentation with both electron and electron based apps (VS Code, Atom, N1, Slack, ...). The main process hovers at around 80MB, but you also have countless node processes running. When node will be a default on machines (please, never), I'll stop adding those processes to the total, but meanwhile, they do count. >I doubt it. Creating performant HTML layouts and WebGL rendering all verified by independent 3rd party test suites is hard, dude. If someone came to you and said "Build a HTML engine or build Word" which would you choose? A) The electron developers do not develop a rendering engine. They do not develop a JS VM either. They develop a toolkit for desktop apps, which uses nodejs (which is highly dependent on Google not pulling the plug on V8) as well as Blink (which is highly dependent on Google). While I am not discounting their work, they are absolutely not the ones with their hands in the engine internals. B) I would honestly build a rendering engine. Word has 25 years of backwards compatibility to keep, features and integrations with lots of other office software, etc. Rendering engines have a clear and defined spec. Microsoft hasn't clearly defined the DOCX spec (well, they did, but keep adding undocumented surprises. Just like XLS :^). C) I'd ask for a team, because no single human being can replicate the feature set of either in his lifetime. Add-ins in JS? Sure, run them in an another thread and keep them out of performant code and we'll be friends.
- TheCoreh 10y ago
  > Office isn't running in fucking Javascript Yet. ;)
  - moondev 10y ago
    Already is! https://office.live.com/start/Word.aspx https://office.live.com/start/Word.aspx
- ConAntonakos 10y ago
  Why the aversion towards JavaScript? It's steadily improving, albeit slowly, with massive support from many players.
  - ntauthority 10y ago
    Not in the least, it's dynamically-typed with ecosystem libraries removing APIs by the dozen (upgrade your dependencies? prepare for days of verifying runtime errors of missing functions), and TypeScript is still a second-class citizen even despite the increasing amount of TypeScript-first libraries (like Angular2)...

tracker1 10y ago

Other than a little startup lag VS Code which runs on top of Electron performs very well on my computers, though they all have SSDs. As to performance and memory footprint vs. a statically compiled language/platform, yes, it's a bit heavier... that said, people are writing useful software with it, and able to deploy it cross platform, with minimal additional effort, and able to re-use components build for web based versions. It's not ideal for some apps, but it's completely serviceable for most apps.

pikzen 10y ago
Oh I'm not contesting the fact that it's serviceable. Our job is to deliver software. I'm just slightly concerned by the absolute disregard for performance and power usage that is implied by using Electron.

ConAntonakos 10y ago

Isn't V8 open source? https://github.com/v8/v8 https://github.com/v8/v8