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.<p>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.<p>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.<p>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!<p>If you have a free afternoon, I <i>definitely</i> recommend playing around with Electron. It will likely change your outlook on the future of desktop software. :)
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:<p>Electron is the cancer that is killing desktop computing.<p>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.<p>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!<p>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.<p>Cancer, I say!<p>Kill it with fire!
While there are many awesome things about Electron, I still give native desktop app advantage. Native apps just <i>feel</i> 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.
I can definitely see a niche in which Electron serves well.<p>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.<p>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.<p>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.
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.<p>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?<p>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.<p>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! <a href="http://www.meetup.com/Bay-Area-Electron-User-Group/" rel="nofollow">http://www.meetup.com/Bay-Area-Electron-User-Group/</a>
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.<p>* JavaScript-heavy Spotify now vs. Spotify a few years ago<p>* Atom vs. something like Sublime Text<p>* Or, Slack that takes the cake especially if you log in to multiple Slacks.<p>It's cool for developers. It's not cool for the users.
I know this is not really electron's fault, but could there be way to shrink these run times to a lot smaller?<p>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.<p>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.
"Electron has lowered the barrier to developing desktop applications". Nope, I don't think so. Perhaps for web developers.<p>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.<p>Please, use the right tool for the right job.
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.<p>With Qt, just watch this 30 minutes presentation about Qt and HiDPI, while ok there are some parts which unnecessarily complicate matters: <a href="https://www.youtube.com/watch?v=2XPpp4yD_M4" rel="nofollow">https://www.youtube.com/watch?v=2XPpp4yD_M4</a>
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.<p>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...
Congratulations on reaching 1.0. Electron is really interesting, but until memory usage can be curbed, it's going to be a limiting factor.<p>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.<p>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...
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.
Burn this.<p>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?<p>PLEASE. I BEG YOU. DON'T EVEN TAKE CREDITS FROM ME. IT IS SO WE CAN SAVE THE WORLD.
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.<p>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.<p>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.<p>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.<p>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.<p>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: <a href="http://www.meetup.com/Bay-Area-Electron-User-Group/events/230303142/" rel="nofollow">http://www.meetup.com/Bay-Area-Electron-User-Group/events/23...</a>
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.<p>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.
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?
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... (<a href="https://fman.io" rel="nofollow">https://fman.io</a>)
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:<p>* Your can now make your web devs (HTML/CSS/JS etc) do your application development as well<p>* General popularity of web development is exploding<p>* There's no comparable free, permissive native framework. The closest thing is Qt and its LGPL. No one wants to touch the GPL.
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.
I just came across a great Electron app called Nativefier (<a href="https://github.com/jiahaog/nativefier" rel="nofollow">https://github.com/jiahaog/nativefier</a> <a href="https://news.ycombinator.com/item?id=10930718" rel="nofollow">https://news.ycombinator.com/item?id=10930718</a>) last night. It's a super easy way to make dedicated browsers & launchers for certain web apps. (very anti-web, I know)<p>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
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.
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.
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?
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.<p>Is there an equivalent to this but with Python or C# ?
One of the things I really like about Electron apps is they <i>look good</i> consistently across platforms, which is something I don't often see for cross-platform apps.<p>QT seems to be the other major cross-platform framework, but I've never seen one that looks good IMO.<p>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).
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.<p>www.meetup.com/Bay-Area-Electron-User-Group/
Related to another comment I posted here, what's the opinion lately on native controls/UI widgets vs something cross-platform like this?<p>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.<p>The reverse seems to be true on mobile platforms, where people seem to be preferring native UI widgets and behaviour.
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. :/
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.<p>1: <a href="https://catlight.io/" rel="nofollow">https://catlight.io/</a>
Hmm? Slack's MacApp purports to use MacGap not Electron (<a href="https://github.com/MacGapProject/MacGap1" rel="nofollow">https://github.com/MacGapProject/MacGap1</a>).
Congrats to the Electron community!<p>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
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?
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.
"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.
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).
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.<p>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.<p>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.