4 ms·

* 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 j

by 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)...

by pikzen 10y ago

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)...