5 ms·

http://pencil.evolus.vn/Next.html http://pencil.evolus.vn/Next.html > Electron as the new runtime No. Just no.

by pmlnr 10y ago

kagamine 10y ago
Why. Just why. edit: No really, why? Genuinely curious. You have to at least come with one reason after writing that.
- bruce_one 10y ago
  Indeed, seems like an odd complaint considering the existing application is just ZUL, so isn't it almost the same thing, but on FF instead?
- shakna 10y ago
  I've only seen one really well executed Electron-based tool: Visual Studio Code. It's fast, and isn't entirely an enormous executable (40-ish MB). However, most Electron apps are slow, laggy, and 100+ MB. It seems great when used by an expert, or great for a stopgap when you need to get something into public hands, but you plan on replacing it with something smaller and faster.
  - k__ 10y ago
    > most Electron apps are slow, laggy, and 100+ MB. Yes, because it's common in (Node)JS land to add many dependencies. I guess MS simply coded most of the stuff on their own, which keeps the size low. Also, they use TypeScript and I heard that it reduces function polymorphism, which can increase performance (but I don't know how much). Also, as far as I know, VSCode runs plugins in different processes, which makes the main process snappier.
    - smt88 10y ago
      TypeScript generates readable JS that is as close to the TypeScript source as possible. It doesn't do optimizations that I know of.
      - k__ 10y ago
        I know that. But I heard that the static typing (implicitly) leads devs to write more monomorphic functions, which seem to be much easier to optimize by the JavaScript-VMs. But yes, you can write such code in JavaScript yourself. The thing is that writing polymorphic stuff is a bit more effort in TypeScript, if you don't want to throw 'any' around everywhere.
  - hex13 10y ago
    I think in 2016 people most developers have disk space for install additional 100 or more megabytes for code editor (unless you're working on low end with very small disk size, but If you do, you would have more problems than freeing 100 megabytes of space)
    - shakna 10y ago
      Sure... But a larger program better come with benefits. VS Code does, its fast, extensible and has been the launching pad for some very cool things like a unified syntax protocol. Atom does, but quickly becomes unuseable with too many extensions, and so I find myself not using it. What did the extra bloat give it over something like Sublime?
- pmlnr 10y ago
  a, they are ginormous b, they are slow c, they don't integrate well with desktop d, they put 1 of not 2 additional layers to execution ( a browser in the background + the node nonsense stack ) In short, they are wasteful. I want to get the speed of my desktop back; it is ridiculous that a 3 year old laptop with a high end ssd lags running these crappy electron things; all of them just keep swallowing memory like there's no tomorrow.
  - pmlnr 10y ago
    Whoever downvotes this please give an explanation and a reasoning for why and how electron applications can beat, for example, QT apps.
  - neurotrace 10y ago
    Didn't downvote but you can't blame the framework for the work of other developers. a & b. Yes, Electron is going to be slower than writing something in a lower level language and yes, it's going to take more memory due to the JS runtime. But it's entirely possible to create an efficient piece of software that can be easily extended (examples: Visual Studio Code, Slack). c. I don't even know what this is supposed to mean. Electron is built _specifically_ as a way of writing desktop applications and it works on just about everything. I even wrote an Electron app that runs smoothly on my old Raspberry Pi 2. d. You don't get a full browser, just the WebKit rendering engine and V8 with Node.js bindings. Node.js has proven itself to be a worthwhile venture. A number of companies now use Node.js in their backend. It's definitely not perfect nor is it the fastest thing in the world but it isn't so terrible as to toss it out entirely.
    - pmlnr 10y ago
      c. The design. Every single electron app I've tried/launched have it's own aesthetics, which looks completely alien to my system. ( Which currently runs XFCE. )
      - pitaj 10y ago
        This applies to Java, QT, and almost any other cross-platform UI library.
- jsight 10y ago
  The problem with Electron is that people are able to identify the framework. If a few popular apps using the same framework have similar flaws, people will then blame the framework. It happens frequently, regardless of platform and regardless of the underlying platform's actual strengths and weaknesses.
k__ 10y ago
Wasn't it a Firefox extension before? Seems like a step forward to me.
- kagamine 10y ago
  There was a FF extension version alongside the install to OS version. It won a Best FF Extension prize in ~2012.
murukesh_s 10y ago
What is wrong with that? Visual studio code runs on Electron. I bet it looks much more polished and performant than many native editors out there.
- k__ 10y ago
  Problem with Electron is, that some stuff implemented on it is really slow. Look how Atom compares to VSCode, one is really snappy, the other starts lagging when you installed a bunch of extensions. Also, companies like Slack just use Electron as a 60MB wrapper for their website.
  - murukesh_s 10y ago
    That could be an issue with any language or platform. Sloppy programming (Not meaning to say Atom guys are sloppy) can cause bloat irrespective of the underlying platform. Electron magnifies it because well there are layers and layers of abstraction. But if you do it correctly, it's quite good, as proven by the VSCode team. So we can stop bashing it purely for performance reasons. Size is still on higher side than desired, but not really much, especially in today's context. If you package it lean, it could come around 40-50mb compressed. That's downloadable in couple of seconds on modern networks and desktop devices. But the convenience it offers is huge. Same codebase for Linux, Windows, Mac and most importantly Web. Want to convert your project into a SaaS offering? Don't rewrite it, just ship it with an abstraction layer to swap the Native file system calls with Ajax. You can't beat that (yet).
    - k__ 10y ago
      Can't the "cool new Microsoft" write a "Electron Best Practices" book? :)
      - murukesh_s 10y ago
        Indeed, It's exactly what I was thinking..
      - 10y ago
d1sciple 10y ago
but isn't XUL getting phased out? back in 2008-09, ported a bunch of Delphi apps to XUL. Took longer to develop than Delphi but with mozrepl and a live connection to emacs, it wasn't a bad experience at all. js-ctypes made talking to native libs fairly easy without having to resort to XPCOM extensions. Sure, XUL felt over-engineered and was heavy but it is (was?) an acceptable cross-platform toolkit for a large class of applications. Gecko embedding API was another thing that Mozilla started and then dropped it. Once Chrome arrived on the scene, Moz just turned into a Wile E. Coyote... sigh.

http://pencil.evolus.vn/Next.html http://pencil.evolus.vn/Next.html > Electron as the new runtime No. Just no.

by pmlnr 10y ago

http://pencil.evolus.vn/Next.html http://pencil.evolus.vn/Next.html > Electron as the new runtime No. Just no.

kagamine 10y ago

Why. Just why. edit: No really, why? Genuinely curious. You have to at least come with one reason after writing that.

bruce_one 10y ago
Indeed, seems like an odd complaint considering the existing application is just ZUL, so isn't it almost the same thing, but on FF instead?
shakna 10y ago
I've only seen one really well executed Electron-based tool: Visual Studio Code. It's fast, and isn't entirely an enormous executable (40-ish MB). However, most Electron apps are slow, laggy, and 100+ MB. It seems great when used by an expert, or great for a stopgap when you need to get something into public hands, but you plan on replacing it with something smaller and faster.
- k__ 10y ago
  > most Electron apps are slow, laggy, and 100+ MB. Yes, because it's common in (Node)JS land to add many dependencies. I guess MS simply coded most of the stuff on their own, which keeps the size low. Also, they use TypeScript and I heard that it reduces function polymorphism, which can increase performance (but I don't know how much). Also, as far as I know, VSCode runs plugins in different processes, which makes the main process snappier.
  - smt88 10y ago
    TypeScript generates readable JS that is as close to the TypeScript source as possible. It doesn't do optimizations that I know of.
    - k__ 10y ago
      I know that. But I heard that the static typing (implicitly) leads devs to write more monomorphic functions, which seem to be much easier to optimize by the JavaScript-VMs. But yes, you can write such code in JavaScript yourself. The thing is that writing polymorphic stuff is a bit more effort in TypeScript, if you don't want to throw 'any' around everywhere.
- hex13 10y ago
  I think in 2016 people most developers have disk space for install additional 100 or more megabytes for code editor (unless you're working on low end with very small disk size, but If you do, you would have more problems than freeing 100 megabytes of space)
  - shakna 10y ago
    Sure... But a larger program better come with benefits. VS Code does, its fast, extensible and has been the launching pad for some very cool things like a unified syntax protocol. Atom does, but quickly becomes unuseable with too many extensions, and so I find myself not using it. What did the extra bloat give it over something like Sublime?
pmlnr 10y ago
a, they are ginormous b, they are slow c, they don't integrate well with desktop d, they put 1 of not 2 additional layers to execution ( a browser in the background + the node nonsense stack ) In short, they are wasteful. I want to get the speed of my desktop back; it is ridiculous that a 3 year old laptop with a high end ssd lags running these crappy electron things; all of them just keep swallowing memory like there's no tomorrow.
- pmlnr 10y ago
  Whoever downvotes this please give an explanation and a reasoning for why and how electron applications can beat, for example, QT apps.
- neurotrace 10y ago
  Didn't downvote but you can't blame the framework for the work of other developers. a & b. Yes, Electron is going to be slower than writing something in a lower level language and yes, it's going to take more memory due to the JS runtime. But it's entirely possible to create an efficient piece of software that can be easily extended (examples: Visual Studio Code, Slack). c. I don't even know what this is supposed to mean. Electron is built _specifically_ as a way of writing desktop applications and it works on just about everything. I even wrote an Electron app that runs smoothly on my old Raspberry Pi 2. d. You don't get a full browser, just the WebKit rendering engine and V8 with Node.js bindings. Node.js has proven itself to be a worthwhile venture. A number of companies now use Node.js in their backend. It's definitely not perfect nor is it the fastest thing in the world but it isn't so terrible as to toss it out entirely.
  - pmlnr 10y ago
    c. The design. Every single electron app I've tried/launched have it's own aesthetics, which looks completely alien to my system. ( Which currently runs XFCE. )
    - pitaj 10y ago
      This applies to Java, QT, and almost any other cross-platform UI library.
jsight 10y ago
The problem with Electron is that people are able to identify the framework. If a few popular apps using the same framework have similar flaws, people will then blame the framework. It happens frequently, regardless of platform and regardless of the underlying platform's actual strengths and weaknesses.

k__ 10y ago

Wasn't it a Firefox extension before? Seems like a step forward to me.

kagamine 10y ago
There was a FF extension version alongside the install to OS version. It won a Best FF Extension prize in ~2012.

murukesh_s 10y ago

What is wrong with that? Visual studio code runs on Electron. I bet it looks much more polished and performant than many native editors out there.

k__ 10y ago
Problem with Electron is, that some stuff implemented on it is really slow. Look how Atom compares to VSCode, one is really snappy, the other starts lagging when you installed a bunch of extensions. Also, companies like Slack just use Electron as a 60MB wrapper for their website.
- murukesh_s 10y ago
  That could be an issue with any language or platform. Sloppy programming (Not meaning to say Atom guys are sloppy) can cause bloat irrespective of the underlying platform. Electron magnifies it because well there are layers and layers of abstraction. But if you do it correctly, it's quite good, as proven by the VSCode team. So we can stop bashing it purely for performance reasons. Size is still on higher side than desired, but not really much, especially in today's context. If you package it lean, it could come around 40-50mb compressed. That's downloadable in couple of seconds on modern networks and desktop devices. But the convenience it offers is huge. Same codebase for Linux, Windows, Mac and most importantly Web. Want to convert your project into a SaaS offering? Don't rewrite it, just ship it with an abstraction layer to swap the Native file system calls with Ajax. You can't beat that (yet).
  - k__ 10y ago
    Can't the "cool new Microsoft" write a "Electron Best Practices" book? :)
    - murukesh_s 10y ago
      Indeed, It's exactly what I was thinking..
    - 10y ago

d1sciple 10y ago

but isn't XUL getting phased out? back in 2008-09, ported a bunch of Delphi apps to XUL. Took longer to develop than Delphi but with mozrepl and a live connection to emacs, it wasn't a bad experience at all. js-ctypes made talking to native libs fairly easy without having to resort to XPCOM extensions. Sure, XUL felt over-engineered and was heavy but it is (was?) an acceptable cross-platform toolkit for a large class of applications. Gecko embedding API was another thing that Mozilla started and then dropped it. Once Chrome arrived on the scene, Moz just turned into a Wile E. Coyote... sigh.