3 ms·
The problem with Electron are the large resulting binaries. Sure, it gives you everything, but you don't want to ship a whole browser engine every-time you ship
by akandiah 9y ago
The problem with Electron are the large resulting binaries. Sure, it gives you everything, but you don't want to ship a whole browser engine every-time you ship a small app.
- colejohnson66 9y agoBut that’s the enterprise way!
- userbinator 9y agoThat's not enterprise enough. Shipping a whole JVM with your app, now that is Enterprise.
- tracker1 9y agoDepending on deployments, aren't VMs and Docker like that in practical use?
- pjmlp 9y agoYeah, but J2EE servers are bad, while Docker is cool.
- tonyedgecombe 9y agoOur industry really is this bonkers.
- oblio 9y agoCan J2EE servers package Ruby, Python, PHP, etc.? :)
- pjmlp 9y agoYes, JRuby, Jython, Quercus, the remaining etc might also have a JVM implementation. :)
- pjmlp 9y agoThe problem with Electron is that I already have a browser on my computer, actually three (FF, IE, Chrome), I don't need more. Plus it doesn't add anything positive the UI/UX beyond a few devs wanting a .exe instead of an URL, and not having to deal with the quirks of each browser/OS. I never liked MSHTML, Active Destkop, XUL, and I really don't see why Electron should be treated in any different way, just because learning how to use native APIS or writing an simple abstraction layer is "too complicated". If devs want to do a web app, do a web app, deal with browser quirks, use web workers, just don't package a browser with it.