26 ms·

Electron 1.0 is here

679 points by alanfranz 10y ago

iamcreasy 10y ago
Electron looks like it has for both worlds, but what is the drawback of this(kind of) system(s)?
- LeoPanthera 10y ago
  Electron apps are huge and incredibly resource hungry. This makes it hard to recommend most electron apps.
  - oceanswave 10y ago
    Source? VS Code is taking up 26/86mb of memory and weighs in at 143mb on disk... not really the most CPU intensive program either
- Xiol 10y ago
  You have to write Javascript.
  - dchest 10y ago
    Or Go, Dart, TypeScript, PureScript, Elm, CoffeeScript, Oberon, or any other language which can be compiled to it.
    - iamcreasy 10y ago
      I am guessing I can use GWT as well, right?
    - oceanswave 10y ago
      Or, create a C or C++ NodeJS module and use it from your JS, or interop using EdgeJS or python-shell
  - damptowel 10y ago
    And css...
- bengotow 10y ago
  There are a couple of things to consider: 1. Electron is not necessarily the best choice if all you want to do is "put your website in the Dock." In Electron, JavaScript on the page can do anything native code could do, like write to the filesystem unless you explicitly disable node integration. Just loading up your website inside an Electron window could be a disastrous security hole. 2. Electron apps run at least 50MB, and take at least 100MB of RAM. (Equivalent to one tab in Chromium) 3. JavaScript is single threaded. Node's event-driven / async design makes is a good fit for most things, but considers all work equal. You have to bend over backwards to do things that a nice threading abstraction would make easy (like Regexp find/replace in a huge directory tree. Atom actually spawns a separate process to do it so it doesn't consume the JavaScript process.)
- galad87 10y ago
  Non native UI. Probably not a big issue on Windows where every app use a different UI toolkit, but on OS X is kinda nice to have native apps.
  - oceanswave 10y ago
    http://photonkit.com/ http://photonkit.com/
    - galad87 10y ago
      That's even worse. The almost "native" look but with the wrong spacing, wrong colors, and wrong behavior.
fsloth 10y ago
What do you think the suitability of Electron is for software that is designed to provide revenue with per seat licences and no service component? I.e. 'traditional desktop app'. It seems to me, given how easy it seems to be to copy and modify an Electron application a third party could always copy an application, whitewash it and capture a portion of the market. The counter point to this is that ownership of the developer brand and distribution channel is which will always drive sales. I'm not sure which aspect is more important when planning a technology platform and revenue model...
- grinich 10y ago
  People can crack/clone desktop apps regardless of the language they're written in. You can certainly add the same types of protection to Electron apps that might be found in traditional native apps, but it just makes things harder and not necessarily impossible. One of the benefits of Electron is the updater system, which allows you to release updates pretty frequently. You could tie that to the paid user account and just innovate faster than people cloning your app! Electron also uses a specific binary packing system (ASAR) to ship app code, so cloning is also a bit harder than just copying a bunch of JS files. https://github.com/electron/electron/blob/master/docs/tutorial/application-packaging.md https://github.com/electron/electron/blob/master/docs/tutori...
  - tehno 10y ago
    Cloning is as simple as "npm install asar && asar extract app.asar", modify what you want and "asar pack" again. So the packing system is really no protection in itself. See https://github.com/electron/asar https://github.com/electron/asar
- voltagex_ 10y ago
  That seems like a legal problem rather than a technical one. People who want to crack or even rebadge your software will always be able to.
  - soundwave106 10y ago
kristianp 10y ago
It would be nice if Electron could enable cross-platform apps, written in languages other than javascript, that compile to native for the back end and to javascript for the front-end.
- grinich 10y ago
  Wagon actually does this with Haskell: https://www.wagonhq.com/blog/first-two-weeks-haskell-wagon https://www.wagonhq.com/blog/first-two-weeks-haskell-wagon
- calsy 10y ago
  The big thing with javascript is that it has truely become a platform 'agnostic' language. It covers all bases in frontend (web, mobile and desktop) and backend development. No other language is in such a unique situation, so its wise for Electron to be JS centric moving towards the future.
  - vesak 10y ago
    Why does it happen so often that the technically weak languages get picked and become widely used? Why Javascript? Is there something about technical superiority that makes less business value?
    - deleted 10y ago
      [deleted]
    - bengotow 10y ago
      Honestly, I think JavaScript was just in the right place at the right time. If you haven't seen ES2016 yet though, it's really worth a look. Electron JavaScript isn't the jQuery crap of the 1990's. It's got destructuring assignment, classes, template strings, let / const, you name it... https://github.com/lukehoban/es6features https://github.com/lukehoban/es6features
      - nathancahill 10y ago
stuaxo 10y ago
Are there plans for electron with the servo browser ?
- Crespyl 10y ago
  I believe the plan is for Servo to support the Chromium Embedded Framework interface, so theoretically it could be a pretty straightforward drop-in replacement.
  - stuaxo 10y ago
    I think it already does support CEF to an extent - no idea if it's enough https://blogs.s-osg.org/servo-the-embeddable-browser-engine/ https://blogs.s-osg.org/servo-the-embeddable-browser-engine/ https://github.com/servo/servo/labels/A-embedding https://github.com/servo/servo/labels/A-embedding
- pcwalton 10y ago
  No plans, but it sure would be sweet, wouldn't it? :)
calsy 10y ago
This is awesome! I wish I had something more constructive to say but thats all I could think of at the moment.
grinich 10y ago
Our team at Nylas has been incredibly lucky to build on the shoulders of the folks at GitHub and I'd just like to thank Kevin, zcbenz, Jessica, and their entire team. They've been awesome to work with and super supportive of this new community. Our early prototypes of Nylas N1 were built on Angular in the browser, and then Adobe Brackets, but we couldn't really get it to a level that felt great and worked offline. It wasn't until we decided to fork Atom (the previous base of Electron) that we started breaking past the "uncanny valley" of wrapped webviews and discovered an application stack that allowed quick cross-platform deployment alongside native code modules. After building on Electron/AtomShell for 18 months and seeing the community grow, I can definitely say there is something really special here. We've still got a lot of work to do on N1 (email is hard!) but we're confident Electron is the right platform for this type of extensible app. A secondary reason we open sourced N1 was to serve as a reference implementation of a large Electron app. There still isn't a great resource for "best practices" when creating complex Electron apps with lots of moving parts. Now that we've hit 1.0, I think it's time to change that! If you have a free afternoon, I definitely recommend playing around with Electron. It will likely change your outlook on the future of desktop software. :)
- t3nary 10y ago
  Keep up the good work on N1, it's a great app :) I also enjoyed reading parts of the source code, it's awesome that you open sourced it!
  - iamcreasy 10y ago
    Indeed. I am always surprised by the responsiveness of this app. Even when the rest of the system has slowed down to a crawl it's never too much to open up N1.
- kuschku 10y ago
  Well, it still doesn’t feel native on linux. You get 2 window bars, and 2 toolbars, nested in each other. http://i.imgur.com/2C769ex.png http://i.imgur.com/2C769ex.png It might be "best practices" on Mac, maybe even on Windows, but it definitely looks out of place on Linux. Especially when compared to native Qt apps.
crisnoble 10y ago
Is there a "built with electron" type directory out there somewhere?
- Zirro 10y ago
  https://github.com/sindresorhus/awesome-electron https://github.com/sindresorhus/awesome-electron
- lauritzsh 10y ago
  http://electron.atom.io/apps/ http://electron.atom.io/apps/
- deleted 10y ago
  [deleted]
colordrops 10y ago
My team is trying to use Electron to build and deploy apps for Linux, Mac, and Windows, but running into issues with the Mac build. Getting a dmg built on Linux (our build server) is apparently not trivial. Is there a docker image or some other project that wraps all the dependencies up to build Electron apps for all major platforms?
- grinich 10y ago
  We've open sourced the build scripts for Nylas N1, which actually just builds on Travis/AppVeyor for Windows, Mac, and Linux. We originally had an internal Jenkins server doing the builds and it was way easier to just configure hosted services to do this for us. It's free if your project is open source, and you can do some clever things to keep signing keys private and include private source paths during compilation. Here's the grunt task for Mac DMGs. The parent directory has a similar script for Windows and Linux (and lots of other utilities too). https://github.com/nylas/N1/blob/master/build/tasks/mkdmg-task.coffee https://github.com/nylas/N1/blob/master/build/tasks/mkdmg-ta...
- unindented 10y ago
  Have you tried electron-builder? https://github.com/electron-userland/electron-builder https://github.com/electron-userland/electron-builder
voltagex_ 10y ago
So CatLight [1] seems to be a C# app using Electron for UI. I'm assuming there's a local web server running, but I wonder how this works from a build perspective? I wonder if Electron can be built with MSBuild. 1: https://catlight.io/ https://catlight.io/
bengotow 10y ago
I've been building on Electron for the last 18 months (@Nylas), and it's really impressive how far it's come in the last year. Coming from native Mac OS X development, Electron is an breath of fresh air. There's an incredible amount of energy and momentum in the web development community these days, and things like Flexbox, ES2016, React, and ESLint make it possible to ship fast and iterate quickly. Who would have thought JavaScript would be achieving what Java/Swing set out to do in the 90's? I've had a chance to work with the core team on a handful of bug fixes and new features, and they've been incredibly kind and welcoming. I think Electron will go far as an open source project, and I'm excited that GitHub is growing it beyond Atom. If you're in the SF Bay Area and interested in learning more about Electron, there's a meet-up coming up later this month! http://www.meetup.com/Bay-Area-Electron-User-Group/ http://www.meetup.com/Bay-Area-Electron-User-Group/
- sievebrain 10y ago
  I would argue that what Java/Swing set out to do in the 1990's was done already. You can ship Swing apps and make lots of money selling them to lots of people - JetBrains being a case in point. You don't get many people starting new projects that way (and Swing has been replaced by JFX anyway), but this seems more related to fashion than the merits of the various technologies. The energy and "momentum" in the web community is something that has been discussed extensively on HN and elsewhere, so I won't comment on that. Suffice it to say that motion is not always the same thing as progress.
  - blub 10y ago
    Let's be fair and admit that the typical Java app doesn't have all the features of a modern Electron app. For instance, I downloaded Atom and after starting it, it wanted to connect to atom.io and then Google analytics. Now Google not only knows which web pages one visits, but also which apps one uses. Electron is win/win - for web developers and Google, of course.
    - sievebrain 10y ago
      Hah. In fairness though, most apps do want to report back usage stats and other telemetry these days. That doesn't sound entirely unreasonable.... though it's conventional for desktop apps to ask first (perhaps one reason people developers like web apps, the social conventions are different)
felixrieseberg 10y ago
If you're based in San Francisco, come to our next meetup! We'll have a bunch of people working on and with Electron there. www.meetup.com/Bay-Area-Electron-User-Group/
uola 10y ago
To me, unless things have changed, electron is crazy. Many people today use some sort of abstraction layer that generates their html/css. I really hope they move towards interfacing js or node.js directly with skia (which is the graphics engine for chrome and used by, I think, sublime text).
gbugniot 10y ago
"Electron has lowered the barrier to developing desktop applications". Nope, I don't think so. Perhaps for web developers. For non-web developers, there are already well-suited technologies to develop desktop applications: Swing, Qt, Cocoa, GTK, WPF/WinRT, and so on. Maybe theses technologies seem less sexy but there are here from the beginning to do that kind of job. Please, use the right tool for the right job.
- serge2k 10y ago
  > Please, use the right tool for the right job. Which part of Electron makes it wrong?
- spiderfarmer 10y ago
  As as webdeveloper, I am now starting to think about desktop applications, where I would have ignored the platform before. It's not at all about how sexy a technology or framework is. I just think I can do a better job in a framework that's adapted to my skillset, instead of adapting myself to a new framework.
- usaphp 10y ago
  Why didn't you quote the full sentence: "Electron has lowered the barrier to developing desktop applications, making it possible for developers to build cross-platform apps using HTML, CSS, and JavaScript" I don't see anything wrong with that statement, Electron really lowered the barrier of entry by allowing using HTML, CSS and Javascript to build cross platform apps, before you had to learn a new language to make it happen (Swift, QT etc). > "Please, use the right tool for the right job." I would rather use a tool that I know and build something functional fast, than spending many months learning new language just to make my app cross platform and losing interest because of that.
  - gbugniot 10y ago
    It's wrong because that tends to persuade developers that there is one tool for every situation. If you build something functional fast with your favorite tool (not suited for the job), then you will probably spend many months maintaining/hacking your codebase to keep it functional and well designed.
albeva 10y ago
Slow, sluggish, resource hungry and looks alien everywhere. Yeah right. Progress ... If there is one thing its done is lower standard for native applications everywhere.
- serge2k 10y ago
  As someone above said, they have achieved what Java/Swing set out to do in the 90s.
- spiderfarmer 10y ago
  Just like websites. They'll never succeed. /s
  - blub 10y ago
    Quality of implementation has some correlation with market success, but ultimately there are many variables involved. Just the other day someone had detailed that they have a business based on Delphi with some ancient database. Can't be rewritten, but it brings in revenue.
    - TeMPOraL 10y ago
      > Just the other day someone had detailed that they have a business based on Delphi with some ancient database. Can't be rewritten, but it brings in revenue. And quality-wise it's probably better than any alternative "cloud-based" solution they could buy these days.
  - izacus 10y ago
    Just because something is "succeeding" it doesn't mean it's not bads qualitywise or it provides a good experience. (Case in point - Windows Vista :P )
  - pritambaral 10y ago
    Websites don't take up 30+ MB disk and 100+ MB RAM (well, not in Firefox anyway, and that's another thing Electron is missing: switchable runtimes and rendering engines, unlike the web)
staticelf 10y ago
One issue I have with Electron is that if I put my computer to sleep without restarting it and have all the applications up all the time, Electron apps gets very slow and sluggish and lags very much. Slack is a good example of this. I have to restart my computer every now and then in order to keep using Slack and Atom, because otherwise it lags so much. I don't know, I think I prefer UWP apps instead.
- k__ 10y ago
  VSCode doesn't seem to suffer from this and isn't it also running on Electron? Maybe it's more of a memory leak thing that TypeScript doesn't have.
  - oceanswave 10y ago
    Pssst. TypeScript is JavaScript.
  - staticelf 10y ago
    No idea, don't use it. But the two applications I use that I know use Electron suffer from the issue I am experiencing.
marcosscriven 10y ago
One of the things I really like about Electron apps is they look good consistently across platforms, which is something I don't often see for cross-platform apps. QT seems to be the other major cross-platform framework, but I've never seen one that looks good IMO. Would be very curious if any fellow HNers could point to good alternatives (preferably C++ based, but as I allude to, I'd compromise by using something like Javascript if it meant a better real world outcome for the user).
- albeva 10y ago
  "looks constantly good" is debatable. I find that it looks generic and web like. It has none or very little native look & feel to it. Coupled with being slow, resource hungry long loading times ...
  - marcosscriven 10y ago
    To put it another way, can you name any applications you feel do cross-platform right? Are there any example you feel tick all the boxes for you, and do they use any framework?
    - Mister_Snuggles 10y ago
      It's far from perfect, but Corel AfterShot Pro[0] is an example of commercial software that uses Qt and ships for Linux, Mac, and Windows. Some of the imperfections I notice are: * The options dialog has a lot of things that just look "different". The controls are native, but the way they're positioned, etc, clearly isn't. The Mac has a lot of common things, like which order the Yes/No/Cancel buttons would appear in a dialog box, that aren't done the same in AfterShot. * Being a photo management/editing application, it naturally uses a dark theme that looks out of place everywhere. Adobe Lightroom and Apple's now-discontinued Aperture both do this. It seems to be a normal thing with this type of application. * On Linux, the window decorations come from AfterShot, not from the window manager. It also has the Windows close/minimize/maximize buttons. * On an old-enough Mac, the integrated GPU doesn't provide the OpenCL stuff that AfterShot requires. This causes it to crash at startup, whereas a real Mac application would tell the OS to fire up the discrete GPU. * I seriously doubt that it exposes any of its API to AppleScript/COM/DBUS, but I haven't checked. I know that it doesn't register itself as a source for the system-wide photo browser on the Mac (as an example, Insert > Pictures > Photo Browser in Microsoft Word on the Mac will show your Aperture, Photos, and iPhoto libraries as whatever structure they have in that application, not just as files on disk). [0] http://www.aftershotpro.com/en/products/aftershot-pro/ http://www.aftershotpro.com/en/products/aftershot-pro/
ksec 10y ago
I know this is not really electron's fault, but could there be way to shrink these run times to a lot smaller? Like Whatsapp App on Desktop you literally have a 60MB download and 200MB install just for a screen that is EXACTLY the same as the Web Version of Whatsapp. While I dont expect all the apps are like CCleaner or the old uTorrent which is only a few MB in size, 200MB is just redicously large.
- marcosscriven 10y ago
  Not trolling, but do you find 200MB is actually a burden? Here in London cable or fibre links means that downloads in seconds. EDIT - Ok, sorry, it seems quite a few people do have pretty horrendous bandwidth issues.
  - slowmotiony 10y ago
    Not trolling, but do you realize that not every human lives in a major European city connected to a fiber link?
    - marcosscriven 10y ago
      Of course :) I lived in Sydney for a year, but even there I had a 24Mbit ADSL2+ line, which is still under a minute to download this.
      - marcosscriven 10y ago
        I don't think people believed I wasn't trolling. Sorry.
      - venamresm__ 10y ago
        200MB takes around 1hour to download where I'm living.
      - oblio 10y ago
        You were comparing London (huge metropolis) with Sydney (another huge metropolis). Those data points aren't really as different as you seem to think :)
marcosscriven 10y ago
Related to another comment I posted here, what's the opinion lately on native controls/UI widgets vs something cross-platform like this? It always used to be argued (and maybe still is) that using the UI framework of the platform is preferable, but IMO the results of Electron apps I've seen look great, and I don't find them confusing to use. The reverse seems to be true on mobile platforms, where people seem to be preferring native UI widgets and behaviour.
- VeejayRampay 10y ago
  I think you're raising a valid point here. Electron apps are not confusing because they do look like "applications" in the broader sense. Built on web technologies, they end up looking like your average well-conceived and well-designed website out there. And that look is something that all users have now become accustomed to, so it does help bridge the platform gaps tremendously.
porker 10y ago
Congratulations on reaching 1.0. Electron is really interesting, but until memory usage can be curbed, it's going to be a limiting factor. I have been going back and forth with Slack over their desktop client; on Windows when signed into 5 groups it uses 1GB RAM. For a rich-chat client. And if you're thinking "But RAM is cheap these days" -- well yes it is, but by the time you've got 15 Chrome tabs open, a Jetbrains IDE and 3 VMs, plus assorted other software running, 16GB disappears very fast...
lpsz 10y ago
Am I the only one unhappy with the trend of moving toward web-wrapper applications? As a developer, I also love the idea of cross-platform, and of more elegant frameworks, but it pains me to run things that are slower or hog the battery. * JavaScript-heavy Spotify now vs. Spotify a few years ago * Atom vs. something like Sublime Text * Or, Slack that takes the cake especially if you log in to multiple Slacks. It's cool for developers. It's not cool for the users.
- TeMPOraL 10y ago
  You're not the only one. I'm very unhappy with this trend myself. Just when you thought people can't invent any new ways of slowing present machines down to a crawl, this happens.
  - damptowel 10y ago
    I used to think faster computers meant faster programs...
    - Aldo_MX 10y ago
      well, the programs are faster to develop
- marknutter 10y ago
  > Am I the only one unhappy with the trend of moving toward web-wrapper applications? No, you're not. In fact, every time any link shows up on the Hacker News front page that has to do with using HTML/JS/CSS to build native applications the comments on it are usually dominated by people who are "unhappy with the trend toward web-wrapper applications". > It's cool for developers. It's not cool for the users. Here's the thing, if it's not cool for developers, then it might not even get built, and that's really not cool for the users. So if I had to choose between less performant code but more software options for users and more performant code but some software people really want or need not being developed, I'd choose the former.
  - deleted 10y ago
Philipp__ 10y ago
While there are many awesome things about Electron, I still give native desktop app advantage. Native apps just feel better. It's all those ms (miliseconds) here and there that in the end make huge difference. Still best showcase is Sublime v Atom. I use Atom, because it's free and open-source, but when I fire up Sublime from time to time, it is amazing how better it feels. It feels right! Guess like everything else in life everything has it's good and bad sides.
- threatofrain 10y ago
  I wish to go on a slight tangent and offer Visual Studio Code to your comparison, because while it's still slower than Sublime but faster than Atom, it also offers unique features that I predict won't be replicated by Atom / Sublime for awhile, if ever.
  - Philipp__ 10y ago
    Tried it. It feels different. I see Atom replicated Sublime's workflow, so I guess I am too used to that. I check VSCode from time to time, but not yet ready to jump on it. Only vim is permanent on my machine, all of the other editors are here to play with. :)
    - threatofrain 10y ago
      I also find Visual Studio Code's UI to be lacking in some ways, like the lack of some editing hotkeys or tabs. The reason why I'm pulled between Visual Studio Code and Sublime is because while Sublime is easier for me on some editing tasks, I find the "intellisense" feature to be very helpful for Javascript / Typescript.
      - seanclayton 10y ago
        Just a heads up: VS Code is starting to implement tabs in the next milestone (not sure what that means as for when users will see it, though). [0] [0]: http://code.visualstudio.com/Updates http://code.visualstudio.com/Updates
greenspot 10y ago
My biggest gripe with Qt is HiDPI support which was introduced just 6 months ago, so quite late. It feels cumbersome compared to HTML/CSS which have native HiDPI support built-in for years. Also the implementation in HTML/CSS is straightforward. You don't need to think about it a second, it just works. Actually this is my number one feature of web tech, it's HiDPI ready and websites and apps like Slack look always slick, crisp and clear, on any platform. With Qt, just watch this 30 minutes presentation about Qt and HiDPI, while ok there are some parts which unnecessarily complicate matters: https://www.youtube.com/watch?v=2XPpp4yD_M4 https://www.youtube.com/watch?v=2XPpp4yD_M4
rufb 10y ago
This reminds me of Shoes. Of course, Javascript isn't designed for simplicity like Ruby, and Electron is aimed at serious product development rather than novice and weekend programmers. The product design just isn't "there" yet if we are to measure it by _why's standards. But it's nice to see an ACCESSIBLE actively-maintained tool for making cross-OS apps that "just work" again. In fact, _why released Shoes around 2007 and disappeared in 2009. To put this in perspective, Google Chrome and the 1st iPhone were released in 2008. The web standard mess (JS in particular) was only beginning to be untangled back in 2007. Maybe today's _why would have preferred to try and make Javascript more approachable rather than choose a simple language like Ruby and make it more powerful. I don't know. At any rate, the trend for things like Electron is to become increasingly complicated to the point where it merits a mention in developers' CVs — as it happened with Rails and Node and countless other frameworks before. Hopefully at this point there are players with stakes high enough at making things accessible to push for an entry-level version of Electron. Maybe Codecademy or one of its cousins.
Longwelwind 10y ago
I find it more comfortable to make a GUI using HTML/CSS, but I wish I could use a more modern and more reliable language than Javascript. Is there an equivalent to this but with Python or C# ?
- prees 10y ago
  ClojureScript
- sotojuan 10y ago
  TypeScript?
- deleted 10y ago
  [deleted]
- oceanswave 10y ago
  Using a similar technique, you could use http://coherent-labs.com/dotnet-browser-controls/ http://coherent-labs.com/dotnet-browser-controls/ but you'll also pay out the nose for it.
  - oceanswave 10y ago
    Oh, forgot about https://github.com/cefsharp/CefSharp https://github.com/cefsharp/CefSharp, but theoretically anything that uses Chromium Extensibility Framework (CEF).
cdnsteve 10y ago
I haven't used Electron, but what about mobile apps? I have a need for an app that works on desktop and mobile. So is the recommended option Electron for desktop and for mobile PhoneGap/Cordova?
- stefano 10y ago
  PhoneGap/Cordova apps are slow. Very slow. And even a hello world app can weigh tens of MB. Debugging is painful compared to a native app. The thing is, you won't notice how bad the situation actually is until your code base has grown. Performance can seem acceptable at first, when there's very little code to load and run. When your codebase inevitably grows, you'll start noticing slow start up times (> 10 seconds) and a laggy UI. If you have to do any computationally intensive operation, you'll have to resort to cordova plugins because JS running in the UI thread is a non-starter.
- proyb2 10y ago
  Have you try Android Studio?
theknarf 10y ago
I like the idea of making desktop apps with html, css and JavaScript. I just wish that Electron/Atom wasn't so horrible slow. It shouldn't take me more time to open up a desktop app than a webpage.
StevePerkins 10y ago
I can definitely see a niche in which Electron serves well. However, it seems weird that when talking about mobile apps, the PhoneGap/Cardova "web wrapper" concept is derided as awful compared to native code or maybe cross-plat frameworks. From my anecdotal experience, those same people tend to think that Electron or NW.js are the greatest thing since sliced bread. Electron is PhoneGap for the desktop. That's not necessarily a bad thing or a good thing, it's just a thing that makes sense in certain use cases and not others. The fact that web wrappers have different levels of "street cred" across mobile/desktop contexts feels more subjective than objective. I suspect it's simply a matter of the younger crowd having more exposure to native mobile development, and little or no experience with native desktop development... so this discrepancy reflects those different comfort levels.
- kayoone 10y ago
  I don't think it's the same people that dislike Cordova and like Electron at the same time. Usually the native-only crowd is against the bloat and performance issues that these wrappers bring in general but of course it is more of a problem on mobile where resources are way more constrained and good UX at the same time is a lot harder to do.
- spot 10y ago
  desktop is not so cpu constrained, so perceived performance of electron is "fast enough" but on mobile need native code and APIs to get there.
- felixrieseberg 10y ago
  I'm not sure that that's entirely fair. I for instance don't dislike Cordova for some philosophical reason, but because I have so far hated every single iOS/Android Cordova app - mostly for performance and polish reasons. I do enjoy Visual Studio Code, Atom, Slack, and other apps built with Electron. Yes, people also use it to build horrible apps, but Electron has proven that it's capable of powering apps people love. I have yet to see a Cordova app people love. TL;DR: I love various Electron apps. If I see an amazing Cordova app, I will reconsider my position towards Cordova.
mgkimsal 10y ago
It's too bad the titanium platform with desktop/mobile/js/web combo never got more momentum. Building a 'web' app - with php or ruby - and bundling as desktop app was pretty darn cool. I only dipped my toes in around 2011 or so, and was sad to see it never get more traction. :/
robotnoises 10y ago
Anyone with experience with Electron and NW.js have an opinion on which is better?
- gaving 10y ago
  If you don't have to support win32 platforms, I'd say go with Electron. Other than that, features pretty similar.
- paulbjensen 10y ago
  Hi, I'm writing a book comparing them both at the moment: https://www.manning.com/books/cross-platform-desktop-applications https://www.manning.com/books/cross-platform-desktop-applica... Having built apps in both, my view is that if you want the tool that fits best with Node.js' conventions, Electron is closer to that philosophy. I say this because of the way that the Node.js contexts of the main (backend) process and the renderer (front-end) process are kept separate. This is different to the way that NW.js has managed to blend the Javascript contexts of both into one, which can lead to odd behaviour when it comes to apps that run with multiple windows. In terms of momentum, Electron is definitely capturing the most attention and it looks like it will eventually become the goto framework for cross-platform desktop applications over NW.js, which is a shame because NW.js has been around for a while now and was the pioneer of being able to build desktop applications with Node.js.
mherrmann 10y ago
Electron is really cool, unfortunately its startup performance is slow (several seconds on a ~2010 machine). That's why I had to pick Qt for a file manager I'm launching... (https://fman.io https://fman.io)
e0m 10y ago
Think about how much time people spend in front of 24" screens with a keyboard. "Desktop", or whatever that evolves into, is overwhelmingly where real work still gets done. For as critical as that environment is in the modern workplace it's historically been drastically underserved by this community. Yes, there are a lot of tools like Swing, Qt, Cocoa, GTK, WPF/WinRT, but their development communities are much smaller than the javascript/web ecosystem. They also create enormous portability problems, particularly in an environment (especially in the business world) so heavily dominated by Windows machines. This community is acutely aware of what happens when the barrier to entry is lowered and the development tooling improved. The tooling that Electron provides via Chromium is also something that should not be understated. Chromium's dev tools are remarkable and improving every day. Few other ecosystems, especially old desktop ones, have debugging environments as rich. The painting performance / profiling tools alone go to great lengths to keeping everything running at 60fps. Furthermore modern CSS layout engines like FlexBox give you an enormous head start on a notoriously difficult problem and is a joy to work with when you don't have to worry about browser compatibility. I will admit, the getting-started cost of Electron is high. Shipping all of Chromium and Node is no small feat and frankly probably not suited for a minor utility. However once an app crosses even a modest level of sophistication the benefits of this environment are definitely worth it. There are also several specialized tasks that Node probably isn't suited for. Luckily, since you have full process control and the ability to compile native modules any additional specialized task can be run on the side. The past 18 months working with Electron at Nylas have been some of the most enjoyable development experiences of my life. Much of the crap that frustrates people out of web development (compatibility issues) go away. Being able to build an app at the core of people's day-long experiences is deeply satisfying and something I'm indebted to the Electron team for. If you're in the Bay Area and still have questions or are just curious, come join us at the Electron Meetup on Wed May 25: http://www.meetup.com/Bay-Area-Electron-User-Group/events/230303142/ http://www.meetup.com/Bay-Area-Electron-User-Group/events/23...
tmarkovich 10y ago
On a slightly unrelated note, I love the theme of the Electron plot. Is there any place where I could find it?
svink 10y ago
I can write Photoshop with Electron if I live long enough to finish it. Hell, I can write it in x86 assembly. But why? You are acting like a child, notice that nobody except for you is talking about what is or isn't "impossible". Apart from Hyper V, any application I use could probably be rewritten in javascript. But for many of them, it would be unnecessarily hard and they would run way less efficiently - so why would any sane person do this? And so they don't. That's why the list of applications someone posted looks the way it does. If Autodesk ever requires a web version of 3DS Max, sure, they will do it. If someone decides the next Call of Duty must run in the browser, they will do it. Hell, even if VMWare decides they must provide a VMWare player on the web, they will use javascript and to an extent they could make it work. All of them might suck, but if you want it on the web, you don't have much choice. But we are not talking about web sites here. We are talking about Electron. They sure as hell are not going to write a web version just to have it run on the desktop in a container. That would be retarded unless someone is emotionally attached to only ever using web technologies in any circumstances.
- egeozcan 10y ago
  > I can write Photoshop with Electron if I live long enough to finish it. Hell, I can write it in x86 assembly. But why? Writing graphics-intensive apps is actually the aim of WebGL. > You are acting like a child > That would be retarded I would like to remind you that here, we try to keep it civil.
- dang 10y ago
  This breaks the HN guidelines, which ask you not to call names ("you are acting like a child", etc.) in comments here. Please post civilly and substantively, or not at all. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html We detached this subthread from https://news.ycombinator.com/item?id=11674670 https://news.ycombinator.com/item?id=11674670 and marked it off-topic.
- deleted 10y ago
  [deleted]
jweinstein 10y ago
Congrats to the Electron community! We've been excitingly using Electron at Wagon to build SQL analytics tools. We're using Haskell + React + Electron as our primary technologies: wagonhq.com/blog/electron
mixmastamyk 10y ago
Interesting, reminds me a bit of XUL and XULRunner from the old days, which sort-of failed. What does this have in common, or is different this time?
- simonw 10y ago
  Today's HTML, CSS and JavaScript is a much more powerful and mature platform than XUL ever was. The number of developers with the skills to build a native-quality interface using the web platform is hundreds of times the number of developers who ever learned XUL. Using HTML and CSS for desktop UIs is a proven pattern now. Even Apple used WebKit views for iMessage on OS X.
  - mixmastamyk 10y ago
    Yes, I've even done it myself a few times over the years. But one thing I don't like is that most don't follow the OS theme. I'm not a fan of every app having its own, ala "skinz."
etatoby 10y ago
I'm happy and grateful for any and all open source software, because it enriches everybody, well beyond the scope of its creators. But someone has to say it: Electron is the cancer that is killing desktop computing. It all started years ago with Firefox, whose interface itself was built using web technologies, in a "brilliant stroke." DOM, CSS, Javascript... maybe not HTML per se, but an XML substitute, and so on. I dare anybody say that Firefox's interface has ever felt as fast as IE, Chrome, Opera, or Safari (on Mac.) It never did and still does not. Then someone at GitHub had the bright idea to take this "winning" concept and apply it to a developer's text editor, of all things! I still cannot fathom how Atom can have more than 3 users. Every time I've tried it, I've ditched it after 30 seconds. Slooooooooooow! Fast-forward to 2016: now I see new Electron apps popping up every other day. Even something as simple as a text-only WhatsApp IM client, which could be written in a dozen of C++ files, is a bloated monstrosity that eats RAM for breakfast and contains an entire Node.js interpreter and a Webkit layout engine. Cancer, I say! Kill it with fire!
- oceanswave 10y ago
  And this is only one example, there's NW.JS too, and Coherent Labs and Awesomium.. not to mention UWP apps... plus look at all the apps that leverage some sort of extensibility through JavaScript (Looking at you Creative Cloud and Office suites) Burn them all down BURRRRRRRNNNNNN!!! /s
- tracker1 10y ago
  I agree that Atom itself seems very slow, but VS Code tends to run great, and I really appreciate the feature set that it offers. As it stands, it's not a great use case for many types of applications, but I would say that it's good enough for most of them. Beyond this, people are building useful things with it quickly. Far more quickly than they would be able to if they were targeting a custom UI platform, or with a lower level language like C/C++ etc. All this with the ability to relatively easily build for Windows, OSX and Linux deployments. I don't mind people using XML based UI composition, as it works pretty well. Flex, XAML, and many other UI builders are XML based, simply because the structure corresponds well to the rendering hierarchy of components, and allows for easier understanding of their relative interactions. I am half surprised there isn't a path towards a ReactNative for Desktop (OSX, Windows, Linix) at this point, that is similar to Electron, Node/V8 core, but with a common/reduced component set that just works. It's worth mentioning that the underlying platform is C/C++ based with a very flexible UI kit (HTML) and a DSL (JavaScript + DOM) that is also flexible.
hs86 10y ago
Would a dynamically linked, system-wide Electron installation help with the extensive resource usage of Electron apps? It would decrease the installation size but what about the runtime performance?
- oceanswave 10y ago
  not sure where the red herring came from. VS Code uses less system resources than a blank excel document for me. Opening up another tab in a browser can spawn another browser process, which is done for isolation. Same example, 142MB is the footprint for VS Code. VLC is bigger. Where is this "extensive resource usage" that people seem to be concerned about even apply to Electron? Metrics? A similar paradigm would be to create a Chrome Packaged App, but you're going to still have the same resource utilization as another browser tab.
john_reel 10y ago
Electron has gotten a lot of criticism for being bloated. Are there any good alternatives for making desktop apps that are scripting language based? I’d especially like to use Lua(JIT), but I’m not aware of anything anywhere near as reliable, cross-platform, easily deployed, and easy to build interfaces in as Electron. I’m not the biggest fan of the JS and/or the JS ecosystem, but I would love the speed, lightness, and convenience of another language (just look at how fast and lean Lua with LuaJIT is!) with the power that some JS tools like Electron have to offer.
- infinite8s 10y ago
  You can use Lua with Qt (Torch has some bindings), but it's nowhere near as well tested.
- jventura 10y ago
  For Python you have PyQt (https://riverbankcomputing.com/software/pyqt/intro https://riverbankcomputing.com/software/pyqt/intro)
pj_mukh 10y ago
Hmm? Slack's MacApp purports to use MacGap not Electron (https://github.com/MacGapProject/MacGap1 https://github.com/MacGapProject/MacGap1).
- oceanswave 10y ago
  https://slack.com/jobs/69902/desktop-application-engineer https://slack.com/jobs/69902/desktop-application-engineer "The Slack Desktop apps are built using diverse technologies such as Electron, node.js, ES6, RxJS, C#, and Objective-C,"
webXL 10y ago
I just came across a great Electron app called Nativefier (https://github.com/jiahaog/nativefier https://github.com/jiahaog/nativefier https://news.ycombinator.com/item?id=10930718 https://news.ycombinator.com/item?id=10930718) last night. It's a super easy way to make dedicated browsers & launchers for certain web apps. (very anti-web, I know) My first use case for it was making a dedicated Amazon Video client for my wife's laptop (although Nativefier doesn't have one of the necessary plugins) so we can have our regular Amazon accounts separate without switching credentials all the time. But I can think of a bunch more for this
twotavol 10y ago
Every Electron application I've used has been sluggish and straight up pathetically slow compared to any native counterparts. I think there are two reasons its picking up steam: * Your can now make your web devs (HTML/CSS/JS etc) do your application development as well * General popularity of web development is exploding * There's no comparable free, permissive native framework. The closest thing is Qt and its LGPL. No one wants to touch the GPL.
iconjack 10y ago
Microsoft tried something similar years ago with HTML Applications (.HTA), essentially web apps that could talk to the file system. Didn't seem to work out, though.
- oceanswave 10y ago
  Microsoft also had smart watches, mobile phones and tablets years ago, and none of them really panned out either. ¯\_(ツ)_/¯
- proyb2 10y ago
  Microsoft have too many mistep in technology over the years due to my perception that each products is a utilizes/tools rather than a products. Apple got the products right
jokoon 10y ago
Burn this. Instead, please, can any investor just hire any computer science PhD (who eventually specialized in compiler engineering), and tell him to work on PREPARSED or COMPILED HTML, and make a browser module out of it, for the sake of speed and memory footprint? PLEASE. I BEG YOU. DON'T EVEN TAKE CREDITS FROM ME. IT IS SO WE CAN SAVE THE WORLD.
gontard 10y ago
"any application that can be written in JavaScript, will eventually be written in JavaScript" this seems to be more and more true and depressing. A JavaScript hegemonia.
justncase80 10y ago
Congrats! This is an awesome tool and I hope it ushers in a whole new generation of desktop apps!

679 points by alanfranz 10y ago

iamcreasy 10y ago

Electron looks like it has for both worlds, but what is the drawback of this(kind of) system(s)?

LeoPanthera 10y ago
Electron apps are huge and incredibly resource hungry. This makes it hard to recommend most electron apps.
- oceanswave 10y ago
  Source? VS Code is taking up 26/86mb of memory and weighs in at 143mb on disk... not really the most CPU intensive program either
Xiol 10y ago
You have to write Javascript.
- dchest 10y ago
  Or Go, Dart, TypeScript, PureScript, Elm, CoffeeScript, Oberon, or any other language which can be compiled to it.
  - iamcreasy 10y ago
    I am guessing I can use GWT as well, right?
  - oceanswave 10y ago
    Or, create a C or C++ NodeJS module and use it from your JS, or interop using EdgeJS or python-shell
- damptowel 10y ago
  And css...
bengotow 10y ago
There are a couple of things to consider: 1. Electron is not necessarily the best choice if all you want to do is "put your website in the Dock." In Electron, JavaScript on the page can do anything native code could do, like write to the filesystem unless you explicitly disable node integration. Just loading up your website inside an Electron window could be a disastrous security hole. 2. Electron apps run at least 50MB, and take at least 100MB of RAM. (Equivalent to one tab in Chromium) 3. JavaScript is single threaded. Node's event-driven / async design makes is a good fit for most things, but considers all work equal. You have to bend over backwards to do things that a nice threading abstraction would make easy (like Regexp find/replace in a huge directory tree. Atom actually spawns a separate process to do it so it doesn't consume the JavaScript process.)
galad87 10y ago
Non native UI. Probably not a big issue on Windows where every app use a different UI toolkit, but on OS X is kinda nice to have native apps.
- oceanswave 10y ago
  http://photonkit.com/ http://photonkit.com/
  - galad87 10y ago
    That's even worse. The almost "native" look but with the wrong spacing, wrong colors, and wrong behavior.

fsloth 10y ago

What do you think the suitability of Electron is for software that is designed to provide revenue with per seat licences and no service component? I.e. 'traditional desktop app'. It seems to me, given how easy it seems to be to copy and modify an Electron application a third party could always copy an application, whitewash it and capture a portion of the market. The counter point to this is that ownership of the developer brand and distribution channel is which will always drive sales. I'm not sure which aspect is more important when planning a technology platform and revenue model...

grinich 10y ago
People can crack/clone desktop apps regardless of the language they're written in. You can certainly add the same types of protection to Electron apps that might be found in traditional native apps, but it just makes things harder and not necessarily impossible. One of the benefits of Electron is the updater system, which allows you to release updates pretty frequently. You could tie that to the paid user account and just innovate faster than people cloning your app! Electron also uses a specific binary packing system (ASAR) to ship app code, so cloning is also a bit harder than just copying a bunch of JS files. https://github.com/electron/electron/blob/master/docs/tutorial/application-packaging.md https://github.com/electron/electron/blob/master/docs/tutori...
- tehno 10y ago
  Cloning is as simple as "npm install asar && asar extract app.asar", modify what you want and "asar pack" again. So the packing system is really no protection in itself. See https://github.com/electron/asar https://github.com/electron/asar
voltagex_ 10y ago
That seems like a legal problem rather than a technical one. People who want to crack or even rebadge your software will always be able to.
- soundwave106 10y ago

kristianp 10y ago

It would be nice if Electron could enable cross-platform apps, written in languages other than javascript, that compile to native for the back end and to javascript for the front-end.

grinich 10y ago
Wagon actually does this with Haskell: https://www.wagonhq.com/blog/first-two-weeks-haskell-wagon https://www.wagonhq.com/blog/first-two-weeks-haskell-wagon
calsy 10y ago
The big thing with javascript is that it has truely become a platform 'agnostic' language. It covers all bases in frontend (web, mobile and desktop) and backend development. No other language is in such a unique situation, so its wise for Electron to be JS centric moving towards the future.
- vesak 10y ago
  Why does it happen so often that the technically weak languages get picked and become widely used? Why Javascript? Is there something about technical superiority that makes less business value?
  - deleted 10y ago
    [deleted]
  - bengotow 10y ago
    Honestly, I think JavaScript was just in the right place at the right time. If you haven't seen ES2016 yet though, it's really worth a look. Electron JavaScript isn't the jQuery crap of the 1990's. It's got destructuring assignment, classes, template strings, let / const, you name it... https://github.com/lukehoban/es6features https://github.com/lukehoban/es6features
    - nathancahill 10y ago

stuaxo 10y ago

Are there plans for electron with the servo browser ?

Crespyl 10y ago
I believe the plan is for Servo to support the Chromium Embedded Framework interface, so theoretically it could be a pretty straightforward drop-in replacement.
- stuaxo 10y ago
  I think it already does support CEF to an extent - no idea if it's enough https://blogs.s-osg.org/servo-the-embeddable-browser-engine/ https://blogs.s-osg.org/servo-the-embeddable-browser-engine/ https://github.com/servo/servo/labels/A-embedding https://github.com/servo/servo/labels/A-embedding
pcwalton 10y ago
No plans, but it sure would be sweet, wouldn't it? :)

calsy 10y ago

This is awesome! I wish I had something more constructive to say but thats all I could think of at the moment.

grinich 10y ago

Our team at Nylas has been incredibly lucky to build on the shoulders of the folks at GitHub and I'd just like to thank Kevin, zcbenz, Jessica, and their entire team. They've been awesome to work with and super supportive of this new community. Our early prototypes of Nylas N1 were built on Angular in the browser, and then Adobe Brackets, but we couldn't really get it to a level that felt great and worked offline. It wasn't until we decided to fork Atom (the previous base of Electron) that we started breaking past the "uncanny valley" of wrapped webviews and discovered an application stack that allowed quick cross-platform deployment alongside native code modules. After building on Electron/AtomShell for 18 months and seeing the community grow, I can definitely say there is something really special here. We've still got a lot of work to do on N1 (email is hard!) but we're confident Electron is the right platform for this type of extensible app. A secondary reason we open sourced N1 was to serve as a reference implementation of a large Electron app. There still isn't a great resource for "best practices" when creating complex Electron apps with lots of moving parts. Now that we've hit 1.0, I think it's time to change that! If you have a free afternoon, I definitely recommend playing around with Electron. It will likely change your outlook on the future of desktop software. :)

t3nary 10y ago
Keep up the good work on N1, it's a great app :) I also enjoyed reading parts of the source code, it's awesome that you open sourced it!
- iamcreasy 10y ago
  Indeed. I am always surprised by the responsiveness of this app. Even when the rest of the system has slowed down to a crawl it's never too much to open up N1.
kuschku 10y ago
Well, it still doesn’t feel native on linux. You get 2 window bars, and 2 toolbars, nested in each other. http://i.imgur.com/2C769ex.png http://i.imgur.com/2C769ex.png It might be "best practices" on Mac, maybe even on Windows, but it definitely looks out of place on Linux. Especially when compared to native Qt apps.

crisnoble 10y ago

Is there a "built with electron" type directory out there somewhere?

Zirro 10y ago
https://github.com/sindresorhus/awesome-electron https://github.com/sindresorhus/awesome-electron
lauritzsh 10y ago
http://electron.atom.io/apps/ http://electron.atom.io/apps/
deleted 10y ago
[deleted]

colordrops 10y ago

My team is trying to use Electron to build and deploy apps for Linux, Mac, and Windows, but running into issues with the Mac build. Getting a dmg built on Linux (our build server) is apparently not trivial. Is there a docker image or some other project that wraps all the dependencies up to build Electron apps for all major platforms?

grinich 10y ago
We've open sourced the build scripts for Nylas N1, which actually just builds on Travis/AppVeyor for Windows, Mac, and Linux. We originally had an internal Jenkins server doing the builds and it was way easier to just configure hosted services to do this for us. It's free if your project is open source, and you can do some clever things to keep signing keys private and include private source paths during compilation. Here's the grunt task for Mac DMGs. The parent directory has a similar script for Windows and Linux (and lots of other utilities too). https://github.com/nylas/N1/blob/master/build/tasks/mkdmg-task.coffee https://github.com/nylas/N1/blob/master/build/tasks/mkdmg-ta...
unindented 10y ago
Have you tried electron-builder? https://github.com/electron-userland/electron-builder https://github.com/electron-userland/electron-builder

voltagex_ 10y ago

So CatLight [1] seems to be a C# app using Electron for UI. I'm assuming there's a local web server running, but I wonder how this works from a build perspective? I wonder if Electron can be built with MSBuild. 1: https://catlight.io/ https://catlight.io/

bengotow 10y ago

I've been building on Electron for the last 18 months (@Nylas), and it's really impressive how far it's come in the last year. Coming from native Mac OS X development, Electron is an breath of fresh air. There's an incredible amount of energy and momentum in the web development community these days, and things like Flexbox, ES2016, React, and ESLint make it possible to ship fast and iterate quickly. Who would have thought JavaScript would be achieving what Java/Swing set out to do in the 90's? I've had a chance to work with the core team on a handful of bug fixes and new features, and they've been incredibly kind and welcoming. I think Electron will go far as an open source project, and I'm excited that GitHub is growing it beyond Atom. If you're in the SF Bay Area and interested in learning more about Electron, there's a meet-up coming up later this month! http://www.meetup.com/Bay-Area-Electron-User-Group/ http://www.meetup.com/Bay-Area-Electron-User-Group/

sievebrain 10y ago
I would argue that what Java/Swing set out to do in the 1990's was done already. You can ship Swing apps and make lots of money selling them to lots of people - JetBrains being a case in point. You don't get many people starting new projects that way (and Swing has been replaced by JFX anyway), but this seems more related to fashion than the merits of the various technologies. The energy and "momentum" in the web community is something that has been discussed extensively on HN and elsewhere, so I won't comment on that. Suffice it to say that motion is not always the same thing as progress.
- blub 10y ago
  Let's be fair and admit that the typical Java app doesn't have all the features of a modern Electron app. For instance, I downloaded Atom and after starting it, it wanted to connect to atom.io and then Google analytics. Now Google not only knows which web pages one visits, but also which apps one uses. Electron is win/win - for web developers and Google, of course.
  - sievebrain 10y ago
    Hah. In fairness though, most apps do want to report back usage stats and other telemetry these days. That doesn't sound entirely unreasonable.... though it's conventional for desktop apps to ask first (perhaps one reason people developers like web apps, the social conventions are different)

felixrieseberg 10y ago

If you're based in San Francisco, come to our next meetup! We'll have a bunch of people working on and with Electron there. www.meetup.com/Bay-Area-Electron-User-Group/

uola 10y ago

To me, unless things have changed, electron is crazy. Many people today use some sort of abstraction layer that generates their html/css. I really hope they move towards interfacing js or node.js directly with skia (which is the graphics engine for chrome and used by, I think, sublime text).

gbugniot 10y ago

"Electron has lowered the barrier to developing desktop applications". Nope, I don't think so. Perhaps for web developers. For non-web developers, there are already well-suited technologies to develop desktop applications: Swing, Qt, Cocoa, GTK, WPF/WinRT, and so on. Maybe theses technologies seem less sexy but there are here from the beginning to do that kind of job. Please, use the right tool for the right job.

serge2k 10y ago
> Please, use the right tool for the right job. Which part of Electron makes it wrong?
spiderfarmer 10y ago
As as webdeveloper, I am now starting to think about desktop applications, where I would have ignored the platform before. It's not at all about how sexy a technology or framework is. I just think I can do a better job in a framework that's adapted to my skillset, instead of adapting myself to a new framework.
usaphp 10y ago
Why didn't you quote the full sentence: "Electron has lowered the barrier to developing desktop applications, making it possible for developers to build cross-platform apps using HTML, CSS, and JavaScript" I don't see anything wrong with that statement, Electron really lowered the barrier of entry by allowing using HTML, CSS and Javascript to build cross platform apps, before you had to learn a new language to make it happen (Swift, QT etc). > "Please, use the right tool for the right job." I would rather use a tool that I know and build something functional fast, than spending many months learning new language just to make my app cross platform and losing interest because of that.
- gbugniot 10y ago
  It's wrong because that tends to persuade developers that there is one tool for every situation. If you build something functional fast with your favorite tool (not suited for the job), then you will probably spend many months maintaining/hacking your codebase to keep it functional and well designed.

albeva 10y ago

Slow, sluggish, resource hungry and looks alien everywhere. Yeah right. Progress ... If there is one thing its done is lower standard for native applications everywhere.

serge2k 10y ago
As someone above said, they have achieved what Java/Swing set out to do in the 90s.
spiderfarmer 10y ago
Just like websites. They'll never succeed. /s
- blub 10y ago
  Quality of implementation has some correlation with market success, but ultimately there are many variables involved. Just the other day someone had detailed that they have a business based on Delphi with some ancient database. Can't be rewritten, but it brings in revenue.
  - TeMPOraL 10y ago
    > Just the other day someone had detailed that they have a business based on Delphi with some ancient database. Can't be rewritten, but it brings in revenue. And quality-wise it's probably better than any alternative "cloud-based" solution they could buy these days.
- izacus 10y ago
  Just because something is "succeeding" it doesn't mean it's not bads qualitywise or it provides a good experience. (Case in point - Windows Vista :P )
- pritambaral 10y ago
  Websites don't take up 30+ MB disk and 100+ MB RAM (well, not in Firefox anyway, and that's another thing Electron is missing: switchable runtimes and rendering engines, unlike the web)

staticelf 10y ago

One issue I have with Electron is that if I put my computer to sleep without restarting it and have all the applications up all the time, Electron apps gets very slow and sluggish and lags very much. Slack is a good example of this. I have to restart my computer every now and then in order to keep using Slack and Atom, because otherwise it lags so much. I don't know, I think I prefer UWP apps instead.

k__ 10y ago
VSCode doesn't seem to suffer from this and isn't it also running on Electron? Maybe it's more of a memory leak thing that TypeScript doesn't have.
- oceanswave 10y ago
  Pssst. TypeScript is JavaScript.
- staticelf 10y ago
  No idea, don't use it. But the two applications I use that I know use Electron suffer from the issue I am experiencing.

marcosscriven 10y ago

One of the things I really like about Electron apps is they look good consistently across platforms, which is something I don't often see for cross-platform apps. QT seems to be the other major cross-platform framework, but I've never seen one that looks good IMO. Would be very curious if any fellow HNers could point to good alternatives (preferably C++ based, but as I allude to, I'd compromise by using something like Javascript if it meant a better real world outcome for the user).

albeva 10y ago
"looks constantly good" is debatable. I find that it looks generic and web like. It has none or very little native look & feel to it. Coupled with being slow, resource hungry long loading times ...
- marcosscriven 10y ago
  To put it another way, can you name any applications you feel do cross-platform right? Are there any example you feel tick all the boxes for you, and do they use any framework?
  - Mister_Snuggles 10y ago
    It's far from perfect, but Corel AfterShot Pro[0] is an example of commercial software that uses Qt and ships for Linux, Mac, and Windows. Some of the imperfections I notice are: * The options dialog has a lot of things that just look "different". The controls are native, but the way they're positioned, etc, clearly isn't. The Mac has a lot of common things, like which order the Yes/No/Cancel buttons would appear in a dialog box, that aren't done the same in AfterShot. * Being a photo management/editing application, it naturally uses a dark theme that looks out of place everywhere. Adobe Lightroom and Apple's now-discontinued Aperture both do this. It seems to be a normal thing with this type of application. * On Linux, the window decorations come from AfterShot, not from the window manager. It also has the Windows close/minimize/maximize buttons. * On an old-enough Mac, the integrated GPU doesn't provide the OpenCL stuff that AfterShot requires. This causes it to crash at startup, whereas a real Mac application would tell the OS to fire up the discrete GPU. * I seriously doubt that it exposes any of its API to AppleScript/COM/DBUS, but I haven't checked. I know that it doesn't register itself as a source for the system-wide photo browser on the Mac (as an example, Insert > Pictures > Photo Browser in Microsoft Word on the Mac will show your Aperture, Photos, and iPhoto libraries as whatever structure they have in that application, not just as files on disk). [0] http://www.aftershotpro.com/en/products/aftershot-pro/ http://www.aftershotpro.com/en/products/aftershot-pro/

ksec 10y ago

I know this is not really electron's fault, but could there be way to shrink these run times to a lot smaller? Like Whatsapp App on Desktop you literally have a 60MB download and 200MB install just for a screen that is EXACTLY the same as the Web Version of Whatsapp. While I dont expect all the apps are like CCleaner or the old uTorrent which is only a few MB in size, 200MB is just redicously large.

marcosscriven 10y ago
Not trolling, but do you find 200MB is actually a burden? Here in London cable or fibre links means that downloads in seconds. EDIT - Ok, sorry, it seems quite a few people do have pretty horrendous bandwidth issues.
- slowmotiony 10y ago
  Not trolling, but do you realize that not every human lives in a major European city connected to a fiber link?
  - marcosscriven 10y ago
    Of course :) I lived in Sydney for a year, but even there I had a 24Mbit ADSL2+ line, which is still under a minute to download this.
    - marcosscriven 10y ago
      I don't think people believed I wasn't trolling. Sorry.
    - venamresm__ 10y ago
      200MB takes around 1hour to download where I'm living.
    - oblio 10y ago
      You were comparing London (huge metropolis) with Sydney (another huge metropolis). Those data points aren't really as different as you seem to think :)

marcosscriven 10y ago

Related to another comment I posted here, what's the opinion lately on native controls/UI widgets vs something cross-platform like this? It always used to be argued (and maybe still is) that using the UI framework of the platform is preferable, but IMO the results of Electron apps I've seen look great, and I don't find them confusing to use. The reverse seems to be true on mobile platforms, where people seem to be preferring native UI widgets and behaviour.

VeejayRampay 10y ago
I think you're raising a valid point here. Electron apps are not confusing because they do look like "applications" in the broader sense. Built on web technologies, they end up looking like your average well-conceived and well-designed website out there. And that look is something that all users have now become accustomed to, so it does help bridge the platform gaps tremendously.

porker 10y ago

Congratulations on reaching 1.0. Electron is really interesting, but until memory usage can be curbed, it's going to be a limiting factor. I have been going back and forth with Slack over their desktop client; on Windows when signed into 5 groups it uses 1GB RAM. For a rich-chat client. And if you're thinking "But RAM is cheap these days" -- well yes it is, but by the time you've got 15 Chrome tabs open, a Jetbrains IDE and 3 VMs, plus assorted other software running, 16GB disappears very fast...

lpsz 10y ago

Am I the only one unhappy with the trend of moving toward web-wrapper applications? As a developer, I also love the idea of cross-platform, and of more elegant frameworks, but it pains me to run things that are slower or hog the battery. * JavaScript-heavy Spotify now vs. Spotify a few years ago * Atom vs. something like Sublime Text * Or, Slack that takes the cake especially if you log in to multiple Slacks. It's cool for developers. It's not cool for the users.

TeMPOraL 10y ago
You're not the only one. I'm very unhappy with this trend myself. Just when you thought people can't invent any new ways of slowing present machines down to a crawl, this happens.
- damptowel 10y ago
  I used to think faster computers meant faster programs...
  - Aldo_MX 10y ago
    well, the programs are faster to develop
marknutter 10y ago
> Am I the only one unhappy with the trend of moving toward web-wrapper applications? No, you're not. In fact, every time any link shows up on the Hacker News front page that has to do with using HTML/JS/CSS to build native applications the comments on it are usually dominated by people who are "unhappy with the trend toward web-wrapper applications". > It's cool for developers. It's not cool for the users. Here's the thing, if it's not cool for developers, then it might not even get built, and that's really not cool for the users. So if I had to choose between less performant code but more software options for users and more performant code but some software people really want or need not being developed, I'd choose the former.
- deleted 10y ago

Philipp__ 10y ago

While there are many awesome things about Electron, I still give native desktop app advantage. Native apps just feel better. It's all those ms (miliseconds) here and there that in the end make huge difference. Still best showcase is Sublime v Atom. I use Atom, because it's free and open-source, but when I fire up Sublime from time to time, it is amazing how better it feels. It feels right! Guess like everything else in life everything has it's good and bad sides.

threatofrain 10y ago
I wish to go on a slight tangent and offer Visual Studio Code to your comparison, because while it's still slower than Sublime but faster than Atom, it also offers unique features that I predict won't be replicated by Atom / Sublime for awhile, if ever.
- Philipp__ 10y ago
  Tried it. It feels different. I see Atom replicated Sublime's workflow, so I guess I am too used to that. I check VSCode from time to time, but not yet ready to jump on it. Only vim is permanent on my machine, all of the other editors are here to play with. :)
  - threatofrain 10y ago
    I also find Visual Studio Code's UI to be lacking in some ways, like the lack of some editing hotkeys or tabs. The reason why I'm pulled between Visual Studio Code and Sublime is because while Sublime is easier for me on some editing tasks, I find the "intellisense" feature to be very helpful for Javascript / Typescript.
    - seanclayton 10y ago
      Just a heads up: VS Code is starting to implement tabs in the next milestone (not sure what that means as for when users will see it, though). [0] [0]: http://code.visualstudio.com/Updates http://code.visualstudio.com/Updates

greenspot 10y ago

My biggest gripe with Qt is HiDPI support which was introduced just 6 months ago, so quite late. It feels cumbersome compared to HTML/CSS which have native HiDPI support built-in for years. Also the implementation in HTML/CSS is straightforward. You don't need to think about it a second, it just works. Actually this is my number one feature of web tech, it's HiDPI ready and websites and apps like Slack look always slick, crisp and clear, on any platform. With Qt, just watch this 30 minutes presentation about Qt and HiDPI, while ok there are some parts which unnecessarily complicate matters: https://www.youtube.com/watch?v=2XPpp4yD_M4 https://www.youtube.com/watch?v=2XPpp4yD_M4

rufb 10y ago

This reminds me of Shoes. Of course, Javascript isn't designed for simplicity like Ruby, and Electron is aimed at serious product development rather than novice and weekend programmers. The product design just isn't "there" yet if we are to measure it by _why's standards. But it's nice to see an ACCESSIBLE actively-maintained tool for making cross-OS apps that "just work" again. In fact, _why released Shoes around 2007 and disappeared in 2009. To put this in perspective, Google Chrome and the 1st iPhone were released in 2008. The web standard mess (JS in particular) was only beginning to be untangled back in 2007. Maybe today's _why would have preferred to try and make Javascript more approachable rather than choose a simple language like Ruby and make it more powerful. I don't know. At any rate, the trend for things like Electron is to become increasingly complicated to the point where it merits a mention in developers' CVs — as it happened with Rails and Node and countless other frameworks before. Hopefully at this point there are players with stakes high enough at making things accessible to push for an entry-level version of Electron. Maybe Codecademy or one of its cousins.

Longwelwind 10y ago

I find it more comfortable to make a GUI using HTML/CSS, but I wish I could use a more modern and more reliable language than Javascript. Is there an equivalent to this but with Python or C# ?

prees 10y ago
ClojureScript
sotojuan 10y ago
TypeScript?
deleted 10y ago
[deleted]
oceanswave 10y ago
Using a similar technique, you could use http://coherent-labs.com/dotnet-browser-controls/ http://coherent-labs.com/dotnet-browser-controls/ but you'll also pay out the nose for it.
- oceanswave 10y ago
  Oh, forgot about https://github.com/cefsharp/CefSharp https://github.com/cefsharp/CefSharp, but theoretically anything that uses Chromium Extensibility Framework (CEF).

cdnsteve 10y ago

I haven't used Electron, but what about mobile apps? I have a need for an app that works on desktop and mobile. So is the recommended option Electron for desktop and for mobile PhoneGap/Cordova?

stefano 10y ago
PhoneGap/Cordova apps are slow. Very slow. And even a hello world app can weigh tens of MB. Debugging is painful compared to a native app. The thing is, you won't notice how bad the situation actually is until your code base has grown. Performance can seem acceptable at first, when there's very little code to load and run. When your codebase inevitably grows, you'll start noticing slow start up times (> 10 seconds) and a laggy UI. If you have to do any computationally intensive operation, you'll have to resort to cordova plugins because JS running in the UI thread is a non-starter.
proyb2 10y ago
Have you try Android Studio?

theknarf 10y ago

I like the idea of making desktop apps with html, css and JavaScript. I just wish that Electron/Atom wasn't so horrible slow. It shouldn't take me more time to open up a desktop app than a webpage.

StevePerkins 10y ago

I can definitely see a niche in which Electron serves well. However, it seems weird that when talking about mobile apps, the PhoneGap/Cardova "web wrapper" concept is derided as awful compared to native code or maybe cross-plat frameworks. From my anecdotal experience, those same people tend to think that Electron or NW.js are the greatest thing since sliced bread. Electron is PhoneGap for the desktop. That's not necessarily a bad thing or a good thing, it's just a thing that makes sense in certain use cases and not others. The fact that web wrappers have different levels of "street cred" across mobile/desktop contexts feels more subjective than objective. I suspect it's simply a matter of the younger crowd having more exposure to native mobile development, and little or no experience with native desktop development... so this discrepancy reflects those different comfort levels.

kayoone 10y ago
I don't think it's the same people that dislike Cordova and like Electron at the same time. Usually the native-only crowd is against the bloat and performance issues that these wrappers bring in general but of course it is more of a problem on mobile where resources are way more constrained and good UX at the same time is a lot harder to do.
spot 10y ago
desktop is not so cpu constrained, so perceived performance of electron is "fast enough" but on mobile need native code and APIs to get there.
felixrieseberg 10y ago
I'm not sure that that's entirely fair. I for instance don't dislike Cordova for some philosophical reason, but because I have so far hated every single iOS/Android Cordova app - mostly for performance and polish reasons. I do enjoy Visual Studio Code, Atom, Slack, and other apps built with Electron. Yes, people also use it to build horrible apps, but Electron has proven that it's capable of powering apps people love. I have yet to see a Cordova app people love. TL;DR: I love various Electron apps. If I see an amazing Cordova app, I will reconsider my position towards Cordova.

mgkimsal 10y ago

It's too bad the titanium platform with desktop/mobile/js/web combo never got more momentum. Building a 'web' app - with php or ruby - and bundling as desktop app was pretty darn cool. I only dipped my toes in around 2011 or so, and was sad to see it never get more traction. :/

robotnoises 10y ago

Anyone with experience with Electron and NW.js have an opinion on which is better?

gaving 10y ago
If you don't have to support win32 platforms, I'd say go with Electron. Other than that, features pretty similar.
paulbjensen 10y ago
Hi, I'm writing a book comparing them both at the moment: https://www.manning.com/books/cross-platform-desktop-applications https://www.manning.com/books/cross-platform-desktop-applica... Having built apps in both, my view is that if you want the tool that fits best with Node.js' conventions, Electron is closer to that philosophy. I say this because of the way that the Node.js contexts of the main (backend) process and the renderer (front-end) process are kept separate. This is different to the way that NW.js has managed to blend the Javascript contexts of both into one, which can lead to odd behaviour when it comes to apps that run with multiple windows. In terms of momentum, Electron is definitely capturing the most attention and it looks like it will eventually become the goto framework for cross-platform desktop applications over NW.js, which is a shame because NW.js has been around for a while now and was the pioneer of being able to build desktop applications with Node.js.

mherrmann 10y ago

Electron is really cool, unfortunately its startup performance is slow (several seconds on a ~2010 machine). That's why I had to pick Qt for a file manager I'm launching... (https://fman.io https://fman.io)

e0m 10y ago

Think about how much time people spend in front of 24" screens with a keyboard. "Desktop", or whatever that evolves into, is overwhelmingly where real work still gets done. For as critical as that environment is in the modern workplace it's historically been drastically underserved by this community. Yes, there are a lot of tools like Swing, Qt, Cocoa, GTK, WPF/WinRT, but their development communities are much smaller than the javascript/web ecosystem. They also create enormous portability problems, particularly in an environment (especially in the business world) so heavily dominated by Windows machines. This community is acutely aware of what happens when the barrier to entry is lowered and the development tooling improved. The tooling that Electron provides via Chromium is also something that should not be understated. Chromium's dev tools are remarkable and improving every day. Few other ecosystems, especially old desktop ones, have debugging environments as rich. The painting performance / profiling tools alone go to great lengths to keeping everything running at 60fps. Furthermore modern CSS layout engines like FlexBox give you an enormous head start on a notoriously difficult problem and is a joy to work with when you don't have to worry about browser compatibility. I will admit, the getting-started cost of Electron is high. Shipping all of Chromium and Node is no small feat and frankly probably not suited for a minor utility. However once an app crosses even a modest level of sophistication the benefits of this environment are definitely worth it. There are also several specialized tasks that Node probably isn't suited for. Luckily, since you have full process control and the ability to compile native modules any additional specialized task can be run on the side. The past 18 months working with Electron at Nylas have been some of the most enjoyable development experiences of my life. Much of the crap that frustrates people out of web development (compatibility issues) go away. Being able to build an app at the core of people's day-long experiences is deeply satisfying and something I'm indebted to the Electron team for. If you're in the Bay Area and still have questions or are just curious, come join us at the Electron Meetup on Wed May 25: http://www.meetup.com/Bay-Area-Electron-User-Group/events/230303142/ http://www.meetup.com/Bay-Area-Electron-User-Group/events/23...

tmarkovich 10y ago

On a slightly unrelated note, I love the theme of the Electron plot. Is there any place where I could find it?

svink 10y ago

I can write Photoshop with Electron if I live long enough to finish it. Hell, I can write it in x86 assembly. But why? You are acting like a child, notice that nobody except for you is talking about what is or isn't "impossible". Apart from Hyper V, any application I use could probably be rewritten in javascript. But for many of them, it would be unnecessarily hard and they would run way less efficiently - so why would any sane person do this? And so they don't. That's why the list of applications someone posted looks the way it does. If Autodesk ever requires a web version of 3DS Max, sure, they will do it. If someone decides the next Call of Duty must run in the browser, they will do it. Hell, even if VMWare decides they must provide a VMWare player on the web, they will use javascript and to an extent they could make it work. All of them might suck, but if you want it on the web, you don't have much choice. But we are not talking about web sites here. We are talking about Electron. They sure as hell are not going to write a web version just to have it run on the desktop in a container. That would be retarded unless someone is emotionally attached to only ever using web technologies in any circumstances.

egeozcan 10y ago
> I can write Photoshop with Electron if I live long enough to finish it. Hell, I can write it in x86 assembly. But why? Writing graphics-intensive apps is actually the aim of WebGL. > You are acting like a child > That would be retarded I would like to remind you that here, we try to keep it civil.
dang 10y ago
This breaks the HN guidelines, which ask you not to call names ("you are acting like a child", etc.) in comments here. Please post civilly and substantively, or not at all. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html We detached this subthread from https://news.ycombinator.com/item?id=11674670 https://news.ycombinator.com/item?id=11674670 and marked it off-topic.
deleted 10y ago
[deleted]

jweinstein 10y ago

Congrats to the Electron community! We've been excitingly using Electron at Wagon to build SQL analytics tools. We're using Haskell + React + Electron as our primary technologies: wagonhq.com/blog/electron

mixmastamyk 10y ago

Interesting, reminds me a bit of XUL and XULRunner from the old days, which sort-of failed. What does this have in common, or is different this time?

simonw 10y ago
Today's HTML, CSS and JavaScript is a much more powerful and mature platform than XUL ever was. The number of developers with the skills to build a native-quality interface using the web platform is hundreds of times the number of developers who ever learned XUL. Using HTML and CSS for desktop UIs is a proven pattern now. Even Apple used WebKit views for iMessage on OS X.
- mixmastamyk 10y ago
  Yes, I've even done it myself a few times over the years. But one thing I don't like is that most don't follow the OS theme. I'm not a fan of every app having its own, ala "skinz."

etatoby 10y ago

I'm happy and grateful for any and all open source software, because it enriches everybody, well beyond the scope of its creators. But someone has to say it: Electron is the cancer that is killing desktop computing. It all started years ago with Firefox, whose interface itself was built using web technologies, in a "brilliant stroke." DOM, CSS, Javascript... maybe not HTML per se, but an XML substitute, and so on. I dare anybody say that Firefox's interface has ever felt as fast as IE, Chrome, Opera, or Safari (on Mac.) It never did and still does not. Then someone at GitHub had the bright idea to take this "winning" concept and apply it to a developer's text editor, of all things! I still cannot fathom how Atom can have more than 3 users. Every time I've tried it, I've ditched it after 30 seconds. Slooooooooooow! Fast-forward to 2016: now I see new Electron apps popping up every other day. Even something as simple as a text-only WhatsApp IM client, which could be written in a dozen of C++ files, is a bloated monstrosity that eats RAM for breakfast and contains an entire Node.js interpreter and a Webkit layout engine. Cancer, I say! Kill it with fire!

oceanswave 10y ago
And this is only one example, there's NW.JS too, and Coherent Labs and Awesomium.. not to mention UWP apps... plus look at all the apps that leverage some sort of extensibility through JavaScript (Looking at you Creative Cloud and Office suites) Burn them all down BURRRRRRRNNNNNN!!! /s
tracker1 10y ago
I agree that Atom itself seems very slow, but VS Code tends to run great, and I really appreciate the feature set that it offers. As it stands, it's not a great use case for many types of applications, but I would say that it's good enough for most of them. Beyond this, people are building useful things with it quickly. Far more quickly than they would be able to if they were targeting a custom UI platform, or with a lower level language like C/C++ etc. All this with the ability to relatively easily build for Windows, OSX and Linux deployments. I don't mind people using XML based UI composition, as it works pretty well. Flex, XAML, and many other UI builders are XML based, simply because the structure corresponds well to the rendering hierarchy of components, and allows for easier understanding of their relative interactions. I am half surprised there isn't a path towards a ReactNative for Desktop (OSX, Windows, Linix) at this point, that is similar to Electron, Node/V8 core, but with a common/reduced component set that just works. It's worth mentioning that the underlying platform is C/C++ based with a very flexible UI kit (HTML) and a DSL (JavaScript + DOM) that is also flexible.

hs86 10y ago

Would a dynamically linked, system-wide Electron installation help with the extensive resource usage of Electron apps? It would decrease the installation size but what about the runtime performance?

oceanswave 10y ago
not sure where the red herring came from. VS Code uses less system resources than a blank excel document for me. Opening up another tab in a browser can spawn another browser process, which is done for isolation. Same example, 142MB is the footprint for VS Code. VLC is bigger. Where is this "extensive resource usage" that people seem to be concerned about even apply to Electron? Metrics? A similar paradigm would be to create a Chrome Packaged App, but you're going to still have the same resource utilization as another browser tab.

john_reel 10y ago

Electron has gotten a lot of criticism for being bloated. Are there any good alternatives for making desktop apps that are scripting language based? I’d especially like to use Lua(JIT), but I’m not aware of anything anywhere near as reliable, cross-platform, easily deployed, and easy to build interfaces in as Electron. I’m not the biggest fan of the JS and/or the JS ecosystem, but I would love the speed, lightness, and convenience of another language (just look at how fast and lean Lua with LuaJIT is!) with the power that some JS tools like Electron have to offer.

infinite8s 10y ago
You can use Lua with Qt (Torch has some bindings), but it's nowhere near as well tested.
jventura 10y ago
For Python you have PyQt (https://riverbankcomputing.com/software/pyqt/intro https://riverbankcomputing.com/software/pyqt/intro)

pj_mukh 10y ago

Hmm? Slack's MacApp purports to use MacGap not Electron (https://github.com/MacGapProject/MacGap1 https://github.com/MacGapProject/MacGap1).

oceanswave 10y ago
https://slack.com/jobs/69902/desktop-application-engineer https://slack.com/jobs/69902/desktop-application-engineer "The Slack Desktop apps are built using diverse technologies such as Electron, node.js, ES6, RxJS, C#, and Objective-C,"

webXL 10y ago

I just came across a great Electron app called Nativefier (https://github.com/jiahaog/nativefier https://github.com/jiahaog/nativefier https://news.ycombinator.com/item?id=10930718 https://news.ycombinator.com/item?id=10930718) last night. It's a super easy way to make dedicated browsers & launchers for certain web apps. (very anti-web, I know) My first use case for it was making a dedicated Amazon Video client for my wife's laptop (although Nativefier doesn't have one of the necessary plugins) so we can have our regular Amazon accounts separate without switching credentials all the time. But I can think of a bunch more for this

twotavol 10y ago

Every Electron application I've used has been sluggish and straight up pathetically slow compared to any native counterparts. I think there are two reasons its picking up steam: * Your can now make your web devs (HTML/CSS/JS etc) do your application development as well * General popularity of web development is exploding * There's no comparable free, permissive native framework. The closest thing is Qt and its LGPL. No one wants to touch the GPL.

iconjack 10y ago

Microsoft tried something similar years ago with HTML Applications (.HTA), essentially web apps that could talk to the file system. Didn't seem to work out, though.

oceanswave 10y ago
Microsoft also had smart watches, mobile phones and tablets years ago, and none of them really panned out either. ¯\_(ツ)_/¯
proyb2 10y ago
Microsoft have too many mistep in technology over the years due to my perception that each products is a utilizes/tools rather than a products. Apple got the products right

jokoon 10y ago

Burn this. Instead, please, can any investor just hire any computer science PhD (who eventually specialized in compiler engineering), and tell him to work on PREPARSED or COMPILED HTML, and make a browser module out of it, for the sake of speed and memory footprint? PLEASE. I BEG YOU. DON'T EVEN TAKE CREDITS FROM ME. IT IS SO WE CAN SAVE THE WORLD.

gontard 10y ago

"any application that can be written in JavaScript, will eventually be written in JavaScript" this seems to be more and more true and depressing. A JavaScript hegemonia.

justncase80 10y ago

Congrats! This is an awesome tool and I hope it ushers in a whole new generation of desktop apps!