11 ms·

This had me for the first half, where the author walks you through the 'case study' applications that offer minimal functionality despite shipping with an entir

by niftich 10y ago

This had me for the first half, where the author walks you through the 'case study' applications that offer minimal functionality despite shipping with an entire browser inside. But then the essay turns into a rant. It's 2016, people, the ship has sailed on pretending JS isn't a real programming language. Phrasing the argument the way he does just betrays his smug elitism. The fact is, for many types of applications, Electron is a really good fit: for example, shipping a single-page webapp as a desktop app, a need that surfaces often in today's world, despite his derision of this concept. An Electron-wrapped SPA is safer than going to the same website in a multi-tabbed browser and co-mingling your disparate cookies in the same jar, not to mention more convenient for the users, because they can treat it like any other desktop application -- with hardware access, and subject to the OS' native task management. For other apps, Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages. This is a huge boon for re-using knowledge, and perhaps does lead to some amateurish projects. Similar criticisms were leveled towards Visual Basic, where drag-and-drop composing and a good IDE enabled people to quickly crank out a GUI app from an idea.

ivan_gammel 10y ago
>Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages Just wanted to name the most obvious alternative: embedded browser component like QtWebKit, which allows to code most of the application logic on the language of your choice. Embedded browsers are the way people have been doing it since circa 2000 (by then, Windows was dominating platform and you could use embedded IE for rendering - the typical app size was much smaller than 200 Mb btw). I remember earning some money on a side project around that time - the CD catalog of bathroom equipment, which I implemented by borrowing huge part of my customer's website and embedding it in CBuilder app with few improvements for richer UX.
- mateuszf 10y ago
  But then you can't share the same code between your web application and desktop application. As a company you would have to pay two separate teams to develop each - developer time is expensive. Yes - electron apps are slower and eat more ram - but someone else is paying for that.
  - alexchamberlain 10y ago
    Should you be sharing that code? Should there be any business logic in the UI, or should it be pushed back into services that can be shared across both?
    - mateuszf 10y ago
      Maybe not all the code, but you can share lot of the UI behaviour, which is usually quite complicated. This kind of sharing allows you to to have a very similar experience in both places too.
  - ivan_gammel 10y ago
    Valid argument, but only in case if that web app exists. But if it exists and you want to share the code, there's no point in using Electron or building a desktop app at all: you can just create a shortcut on the desktop or even turn it into offline web app in Chrome.
    - bryanrasmussen 10y ago
      not really, there can be lots of reuse of code between the two apps without them being exactly the same. Reuse of major parts of your codebase have been a business case for many years, without requiring that you reuse all that codebase.
  - Splines 10y ago
    > Yes - electron apps are slower and eat more ram - but someone else is paying for that. I hope you're being facetious here. If you develop any kind of desktop application and truly believe this, honestly this is disappointing to read.
    - bryanrasmussen 10y ago
      well if the developers or company don't actually use the app then their users are the ones paying for the ram, aren't they?
    - 10y ago
- jeremiep 10y ago
  I'm fairly certain electron could easily be modified to be installed once and used as the launcher for its applications. I'm also fairly certain we'll see this in the future. Therefore all claims that electron bloats 200Mb are just temporary. Its still a relatively young technology with huge potential (which also means huge potential for misuse!) I spent 5+ years writing native GUI apps in half a dozen frameworks, I hope to never do so again unless the project's requirements ask for it, which I don't see happening for most use-cases out there. Besides, almost nobody writes true native applications anymore - its all C# now which is ironic as its also extremely bloated with huge pools of average developers at best.
  - Mithaldu 10y ago
    Even if the app is smaller on drive, it still takes ~200mb in ram for even the smallest apps.
    - jeremiep 10y ago
      Dropbox itself takes 200Mb and its a simple python app. Google drive takes 300Mb. VSCode takes about 100Mb of ram with a project opened right now. Even my Emacs takes 250Mb and I literally live inside it. All of them have at least 2Gb of virtual memory being mapped to them. Yet I still have 9Gb of free ram. If you want to go against bloat, you might just as well uninstall every single software from your computer, including its OS.
      - roryisok 10y ago
        Literally? I demand a photo of you inside emacs
      - Mithaldu 10y ago
        Each of those apps does a lot more than the most common use for electron: "online messengers" Also, you're arguing in typical FYGM fashion. Not a good look.
        10y ago
- hajile 10y ago
  Qt now just embeds an outdated version of blink and v8. Not really a better solution.
TAForObvReasons 10y ago
I disagree, the first case study app revealed flawed logic. lossless-cut is a _visual_ tool for trimming videos. Author derides it by comparing it to the underlying ffmpeg command but that misses the point entirely: I can't magically divine where the start and end is. I need to see the video to determine the times. This tool provides an easy way to see the video and step until I find the right start and end points. There are plenty of frontends to ffmpeg that do similar tasks, and I really wish the author explored some of them to see how they compare to the electron solution.
Ianvdl 10y ago
> It's 2016, people, the ship has sailed on pretending JS isn't a real programming language. Phrasing the argument the way he does just betrays his smug elitism. Using the date as an argument is also poor form. JS is a terrible programming language (I'm not denying that it is a programming language though) regardless of how popular it is (although I think I might be going against the grain here on HN, many people here seem to enjoy node.js). > The fact is, for many types of applications, Electron is a really good fit: for example, shipping a single-page webapp as a desktop app, a need that surfaces often in today's world, despite his derision of this concept. I feel it's unreasonable to turn a single web page into a desktop app by bundling an entire web browser with it. > ...because they can treat it like any other desktop application -- with hardware access, and subject to the OS' native task management. If you need direct hardware access it probably isn't well-suited to being a web app in the first place? Why use web technologies for it then? > For other apps, Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages. This is a huge boon for re-using knowledge, and perhaps does lead to some amateurish projects. Similar criticisms were leveled towards Visual Basic, where drag-and-drop composing and a good IDE enabled people to quickly crank out a GUI app from an idea. HTML/CSS can be nice to have in such a situation, although a refusal to learn other GUI frameworks probably makes for a poor (native) developer. The resource bloat and (usually) extreme disparity with the native user interface rarely makes it worthwhile for me to use an electron app. It feels like forcing a square peg into a round hole because the developer is seemingly unwilling to consider more appropriate technologies outside of their comfort zone. Yes, there are well-made electron apps (like VS Code mentioned in the article), but I, personally, would hate for it to become the norm.
- FrancoDiaz 10y ago
  JS is a terrible programming language I can never see the point of comments like these. Not one person who reads that will have his mind changed. HTML/CSS can be nice to have in such a situation, although a refusal to learn other GUI frameworks probably makes for a poor (native) developer. No it doesn't. Either the developer benefits or doesn't benefit from "refusing". There's only so much time in the day. I'll refuse to to learn Qt or gtk+, unless there is some overwhelming benefit for me to learn it.
zedred 10y ago
Essays like these, along with Thanksgiving conversations with older extended family, are what really make me question the wisdom of eternal life. What if all the people stuck in the past like this were with us forever?
- ethbro 10y ago
  Then we might not be doomed to make the same mistakes again every 40 or so years?
tonyjstark 10y ago
I think the author really has some valid points and he warns you about the rant part. Valid points are: * Electron is often too much for the purpose * it does not look native and the devs don't care * often there are better tools His points about JS being not a good programming language, meh, the language wars are probably never over #SmalltalkIsStillTheBest
- catshirt 10y ago
  > it does not look native and the devs don't care this is not valid. no need to limit our use case to devs, either. at worst, users don't care. at best, users prefer it. see Spotify, Discord, Skype, Sublime, Chrome, Steam... should i keep going? whenever i open an app that uses entirely native controls i just expect the author didn't want to invest any time into making their app look good.
  - Klathmon 10y ago
    I agree. I never thought about it before, but I have to say that the vast majority of the apps I like the usability in do not look or feel native. I don't know if there are any studies into what "users" want, but I'm with you. I prefer a UX that fits the app best, not the OS. Especially because in my experience I'm using the same app across multiple OSs and I'd like the same layout in each (within reason)
  - heroprotagonist 10y ago
    > at worst, users don't care Well, if you'll accept a single data point, I dislike using them. If there's a native alternative I will always go for that. If there is not, then sometimes this tips the decision to not install.
  - kitsunesoba 10y ago
    Native with minimal custom styled accents can be good looking, polished, and professional, and it doesn't throw platform conventions and features out the window to boot. Native looks bad only when the developer doesn't care. I really don't think its such a great idea to reinvent the UI wheel, throwing the decades of research and refinement represented by native UI toolkits under the bus for the sake of branding and aesthetics, unless you have a good reason — a really good reason, like having to create brand new UI for a task that prior hadn't been performed on computers before. I also see electron apps as stopgap measure, not a solution, and this feeling is reinforced every time I open up Activity Monitor and see Slack or Spotify sucking up upwards of half a gig of memory while sitting there doing nothing.
ChuckMcM 10y ago
"Electron is a really good fit: for example, shipping a single-page webapp as a desktop app, a need that surfaces often in today's world, despite his derision of this concept." From a systems perspective that is emminently rant worthy, it indicates the system has completely failed the developer who cannot easily express what they can in a single page web app as a real application in the system.
- nilliams 10y ago
  Yep, all the native toolkits failed, that's worthy of ranting about, but that is not what OP was doing.
  - m_fayer 10y ago
    The only native toolkit I've ever tried that I thought could compete with web is wpf. It was slow and cludgy but way ahead of its time, and the web is only now starting to approach its power.
    - sixbrx 10y ago
      I think WPF is nice but has actually fallen behind a bit on binding vs. some of the web toolkits like React/Redux, Angular 2, Ember. It's been a while since I messed with it, but MVVM didn't work so well for some kinds of things, which seemed to be why for example selected items property is often not a dependency property of MS supplied widgets (so can't be participate in binding). For example see http://stackoverflow.com/questions/22868445/wpf-binding-selecteditems-in-mvvm http://stackoverflow.com/questions/22868445/wpf-binding-sele... (from what I remember this accepted solution also has a subtle bug of double notification (or was it lack of notification on one side?)).
    - mwcampbell 10y ago
      Perhaps WPF was the Electron of its time, in terms of being a resource hog. I remember how one particular WPF-based application hastened the obsolescence of my brother's laptop some years ago. [1] [1]: https://news.ycombinator.com/item?id=8444494 https://news.ycombinator.com/item?id=8444494
solatic 10y ago
The point you're actually making is that the decision to build a desktop app with Electron is almost always a business decision and not a technical one. If you already have all this SPA code that you built, it's going to be cheaper to re-use it and provide the same UI to the end user that they already know from your SPA. Forget for a second that the performance will be terrible because it's not native code. Forget for a second that a desktop application typically benefits from a more dense UI than a web application, and may benefit from such desktop-only UI features such as separate tooltip windows or OpenGL rendering (yes you can do that in a browser but come on it's not the same). The fact of the matter is that the beancounters typically care less about delivering the best possible UX and more about how their bottom line is going to be affected as they continue the corporate strategy of expending 20% of the effort to get 80% of the potential business benefit. Electron was built for the beancounters. Not for the HN purists. Simple as that.
- vvanders 10y ago
  > Not for the HN purists. Is that necessarily a bad thing? I'll throw a great counter-example to you, Mattermost. It's a great open source project that uses Electron to build a client app for just about every single platform. Have you maintained a cross-platform app for Windows, OSX, and all the various flavor of linux? I have, it's hell. You have compiler differences, ui semantic differences and a litany of per-platform quirks. Does Electron solve every single use case? No. However in the cases where it makes sense it's a great tool.
  - pjmlp 10y ago
    I also have, and would keep on using Java, Qt, wxWidgets than bothering with Electron, and I do have my share of web projects. Also for all the kids out there, Electron is the second coming of the MSHTML ActiveX engine. I didn't like it then, surely don't like it now.
    - mixedCase 10y ago
      >Electron is the second coming of the MSHTML ActiveX engine. Really? I've always thought of it as the "blinders-on dev's XULRunner".
roryisok 10y ago
On the topic of tiny apps that shouldn't need electron, I found another one - catlight.io This is a status bar icon that notifies you when your build is broken. Cool idea, but what the heck does it need electron for? http://catlight.helprace.com/i15-why-is-setup-so-big http://catlight.helprace.com/i15-why-is-setup-so-big Electron is useful for some cases, but this is not one of them

by niftich 10y ago

ivan_gammel 10y ago

>Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages Just wanted to name the most obvious alternative: embedded browser component like QtWebKit, which allows to code most of the application logic on the language of your choice. Embedded browsers are the way people have been doing it since circa 2000 (by then, Windows was dominating platform and you could use embedded IE for rendering - the typical app size was much smaller than 200 Mb btw). I remember earning some money on a side project around that time - the CD catalog of bathroom equipment, which I implemented by borrowing huge part of my customer's website and embedding it in CBuilder app with few improvements for richer UX.

mateuszf 10y ago
But then you can't share the same code between your web application and desktop application. As a company you would have to pay two separate teams to develop each - developer time is expensive. Yes - electron apps are slower and eat more ram - but someone else is paying for that.
- alexchamberlain 10y ago
  Should you be sharing that code? Should there be any business logic in the UI, or should it be pushed back into services that can be shared across both?
  - mateuszf 10y ago
    Maybe not all the code, but you can share lot of the UI behaviour, which is usually quite complicated. This kind of sharing allows you to to have a very similar experience in both places too.
- ivan_gammel 10y ago
  Valid argument, but only in case if that web app exists. But if it exists and you want to share the code, there's no point in using Electron or building a desktop app at all: you can just create a shortcut on the desktop or even turn it into offline web app in Chrome.
  - bryanrasmussen 10y ago
    not really, there can be lots of reuse of code between the two apps without them being exactly the same. Reuse of major parts of your codebase have been a business case for many years, without requiring that you reuse all that codebase.
- Splines 10y ago
  > Yes - electron apps are slower and eat more ram - but someone else is paying for that. I hope you're being facetious here. If you develop any kind of desktop application and truly believe this, honestly this is disappointing to read.
  - bryanrasmussen 10y ago
    well if the developers or company don't actually use the app then their users are the ones paying for the ram, aren't they?
  - 10y ago
jeremiep 10y ago
I'm fairly certain electron could easily be modified to be installed once and used as the launcher for its applications. I'm also fairly certain we'll see this in the future. Therefore all claims that electron bloats 200Mb are just temporary. Its still a relatively young technology with huge potential (which also means huge potential for misuse!) I spent 5+ years writing native GUI apps in half a dozen frameworks, I hope to never do so again unless the project's requirements ask for it, which I don't see happening for most use-cases out there. Besides, almost nobody writes true native applications anymore - its all C# now which is ironic as its also extremely bloated with huge pools of average developers at best.
- Mithaldu 10y ago
  Even if the app is smaller on drive, it still takes ~200mb in ram for even the smallest apps.
  - jeremiep 10y ago
    Dropbox itself takes 200Mb and its a simple python app. Google drive takes 300Mb. VSCode takes about 100Mb of ram with a project opened right now. Even my Emacs takes 250Mb and I literally live inside it. All of them have at least 2Gb of virtual memory being mapped to them. Yet I still have 9Gb of free ram. If you want to go against bloat, you might just as well uninstall every single software from your computer, including its OS.
    - roryisok 10y ago
      Literally? I demand a photo of you inside emacs
    - Mithaldu 10y ago
      Each of those apps does a lot more than the most common use for electron: "online messengers" Also, you're arguing in typical FYGM fashion. Not a good look.
      - 10y ago
hajile 10y ago
Qt now just embeds an outdated version of blink and v8. Not really a better solution.

TAForObvReasons 10y ago

I disagree, the first case study app revealed flawed logic. lossless-cut is a _visual_ tool for trimming videos. Author derides it by comparing it to the underlying ffmpeg command but that misses the point entirely: I can't magically divine where the start and end is. I need to see the video to determine the times. This tool provides an easy way to see the video and step until I find the right start and end points. There are plenty of frontends to ffmpeg that do similar tasks, and I really wish the author explored some of them to see how they compare to the electron solution.

Ianvdl 10y ago

> It's 2016, people, the ship has sailed on pretending JS isn't a real programming language. Phrasing the argument the way he does just betrays his smug elitism. Using the date as an argument is also poor form. JS is a terrible programming language (I'm not denying that it is a programming language though) regardless of how popular it is (although I think I might be going against the grain here on HN, many people here seem to enjoy node.js). > The fact is, for many types of applications, Electron is a really good fit: for example, shipping a single-page webapp as a desktop app, a need that surfaces often in today's world, despite his derision of this concept. I feel it's unreasonable to turn a single web page into a desktop app by bundling an entire web browser with it. > ...because they can treat it like any other desktop application -- with hardware access, and subject to the OS' native task management. If you need direct hardware access it probably isn't well-suited to being a web app in the first place? Why use web technologies for it then? > For other apps, Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages. This is a huge boon for re-using knowledge, and perhaps does lead to some amateurish projects. Similar criticisms were leveled towards Visual Basic, where drag-and-drop composing and a good IDE enabled people to quickly crank out a GUI app from an idea. HTML/CSS can be nice to have in such a situation, although a refusal to learn other GUI frameworks probably makes for a poor (native) developer. The resource bloat and (usually) extreme disparity with the native user interface rarely makes it worthwhile for me to use an electron app. It feels like forcing a square peg into a round hole because the developer is seemingly unwilling to consider more appropriate technologies outside of their comfort zone. Yes, there are well-made electron apps (like VS Code mentioned in the article), but I, personally, would hate for it to become the norm.

FrancoDiaz 10y ago
JS is a terrible programming language I can never see the point of comments like these. Not one person who reads that will have his mind changed. HTML/CSS can be nice to have in such a situation, although a refusal to learn other GUI frameworks probably makes for a poor (native) developer. No it doesn't. Either the developer benefits or doesn't benefit from "refusing". There's only so much time in the day. I'll refuse to to learn Qt or gtk+, unless there is some overwhelming benefit for me to learn it.

zedred 10y ago

Essays like these, along with Thanksgiving conversations with older extended family, are what really make me question the wisdom of eternal life. What if all the people stuck in the past like this were with us forever?

ethbro 10y ago
Then we might not be doomed to make the same mistakes again every 40 or so years?

tonyjstark 10y ago

I think the author really has some valid points and he warns you about the rant part. Valid points are: * Electron is often too much for the purpose * it does not look native and the devs don't care * often there are better tools His points about JS being not a good programming language, meh, the language wars are probably never over #SmalltalkIsStillTheBest

catshirt 10y ago
> it does not look native and the devs don't care this is not valid. no need to limit our use case to devs, either. at worst, users don't care. at best, users prefer it. see Spotify, Discord, Skype, Sublime, Chrome, Steam... should i keep going? whenever i open an app that uses entirely native controls i just expect the author didn't want to invest any time into making their app look good.
- Klathmon 10y ago
  I agree. I never thought about it before, but I have to say that the vast majority of the apps I like the usability in do not look or feel native. I don't know if there are any studies into what "users" want, but I'm with you. I prefer a UX that fits the app best, not the OS. Especially because in my experience I'm using the same app across multiple OSs and I'd like the same layout in each (within reason)
- heroprotagonist 10y ago
  > at worst, users don't care Well, if you'll accept a single data point, I dislike using them. If there's a native alternative I will always go for that. If there is not, then sometimes this tips the decision to not install.
- kitsunesoba 10y ago
  Native with minimal custom styled accents can be good looking, polished, and professional, and it doesn't throw platform conventions and features out the window to boot. Native looks bad only when the developer doesn't care. I really don't think its such a great idea to reinvent the UI wheel, throwing the decades of research and refinement represented by native UI toolkits under the bus for the sake of branding and aesthetics, unless you have a good reason — a really good reason, like having to create brand new UI for a task that prior hadn't been performed on computers before. I also see electron apps as stopgap measure, not a solution, and this feeling is reinforced every time I open up Activity Monitor and see Slack or Spotify sucking up upwards of half a gig of memory while sitting there doing nothing.

ChuckMcM 10y ago

"Electron is a really good fit: for example, shipping a single-page webapp as a desktop app, a need that surfaces often in today's world, despite his derision of this concept." From a systems perspective that is emminently rant worthy, it indicates the system has completely failed the developer who cannot easily express what they can in a single page web app as a real application in the system.

nilliams 10y ago
Yep, all the native toolkits failed, that's worthy of ranting about, but that is not what OP was doing.
- m_fayer 10y ago
  The only native toolkit I've ever tried that I thought could compete with web is wpf. It was slow and cludgy but way ahead of its time, and the web is only now starting to approach its power.
  - sixbrx 10y ago
    I think WPF is nice but has actually fallen behind a bit on binding vs. some of the web toolkits like React/Redux, Angular 2, Ember. It's been a while since I messed with it, but MVVM didn't work so well for some kinds of things, which seemed to be why for example selected items property is often not a dependency property of MS supplied widgets (so can't be participate in binding). For example see http://stackoverflow.com/questions/22868445/wpf-binding-selecteditems-in-mvvm http://stackoverflow.com/questions/22868445/wpf-binding-sele... (from what I remember this accepted solution also has a subtle bug of double notification (or was it lack of notification on one side?)).
  - mwcampbell 10y ago
    Perhaps WPF was the Electron of its time, in terms of being a resource hog. I remember how one particular WPF-based application hastened the obsolescence of my brother's laptop some years ago. [1] [1]: https://news.ycombinator.com/item?id=8444494 https://news.ycombinator.com/item?id=8444494

solatic 10y ago

The point you're actually making is that the decision to build a desktop app with Electron is almost always a business decision and not a technical one. If you already have all this SPA code that you built, it's going to be cheaper to re-use it and provide the same UI to the end user that they already know from your SPA. Forget for a second that the performance will be terrible because it's not native code. Forget for a second that a desktop application typically benefits from a more dense UI than a web application, and may benefit from such desktop-only UI features such as separate tooltip windows or OpenGL rendering (yes you can do that in a browser but come on it's not the same). The fact of the matter is that the beancounters typically care less about delivering the best possible UX and more about how their bottom line is going to be affected as they continue the corporate strategy of expending 20% of the effort to get 80% of the potential business benefit. Electron was built for the beancounters. Not for the HN purists. Simple as that.

vvanders 10y ago
> Not for the HN purists. Is that necessarily a bad thing? I'll throw a great counter-example to you, Mattermost. It's a great open source project that uses Electron to build a client app for just about every single platform. Have you maintained a cross-platform app for Windows, OSX, and all the various flavor of linux? I have, it's hell. You have compiler differences, ui semantic differences and a litany of per-platform quirks. Does Electron solve every single use case? No. However in the cases where it makes sense it's a great tool.
- pjmlp 10y ago
  I also have, and would keep on using Java, Qt, wxWidgets than bothering with Electron, and I do have my share of web projects. Also for all the kids out there, Electron is the second coming of the MSHTML ActiveX engine. I didn't like it then, surely don't like it now.
  - mixedCase 10y ago
    >Electron is the second coming of the MSHTML ActiveX engine. Really? I've always thought of it as the "blinders-on dev's XULRunner".

roryisok 10y ago

On the topic of tiny apps that shouldn't need electron, I found another one - catlight.io This is a status bar icon that notifies you when your build is broken. Cool idea, but what the heck does it need electron for? http://catlight.helprace.com/i15-why-is-setup-so-big http://catlight.helprace.com/i15-why-is-setup-so-big Electron is useful for some cases, but this is not one of them