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. :)
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.
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.
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.
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.
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.
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.
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.
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.
Usually people copy most of the node_modules over.
Ideally it should be run through webpack/etc and only a bundled, minimized version of the app is shipped. In practice some modules may have native compiled addons.
I'm working on an app right now and it ships at 247MB which is way too big.
"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.
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.
It's certainly lowered the barrier of entry for me, and I'm no web developer - my background is mostly back-end Java. Sure, I started out by making websites when I was younger, and a few of my jobs have involved a bit of front end, but I'd be surprised if there are many developers that don't know the basics of HTML, CSS, and JavaScript.
Using web technologies to develop a GUI has been so much easier than learning a new toolkit, or even language. For one thing, some of the options you mentioned are OS specific. There are benefits to OS-native toolkits, but as a one-man team with a small project, the benefits are small and the time investment large. With Electron, I can build on Linux and release for Win/Mac without any concerns.
Qt is the best option of those you mentioned, and I considered it. But I was never great with C++, and learning a whole new markup language (or being tied to Qt Creator) for the UI was an extra barrier for entry. And I've often found that Qt programs don't look or feel right outside of Linux.
Personally, I find developing a UI on HTML/CSS/JS much easier than any desktop UI toolkit I've tried in the past. Updating the UI from the code, and calling code from the UI is s simple, because that's what it was designed to do. And having a browser console makes debugging and trying things so much easier.
I was never a fan of using JS for anything but websites before, but I decided to give Electron a try and I'm a convert. Perhaps there's enough of a speed difference between JS and native code that it would matter for more complex programs, but for my uses I don't notice a difference, thanks to the speed of JS engines now.
Maybe from someone that's starting with no coding knowledge would find Qt and C++ just as easy to pick up as HTML and JS, and certainly a C++ developer would find Qt a better choice. And sure, I don't expect anyone to be able to build Photoshop on top of Electron. But there are plenty of programs that aren't that complex.
While in theory I agree with not using the "new sexy technologies" for the sake of it, and "using the right tool for the job", I don't think that applies here. It works both ways, don't stick with old technologies just because that's what you're used to. What specific benefits do you get from using one of those toolkits for a simple desktop program?
I think it's easy to argue about tools, but take a look at popular desktop apps these days: Slack, Atom, VSCode, Spotify, WhatsApp Desktop... they're all built on Electron or the Chromium Embedded Framework. It seems the community has spoken, and no longer considers Java / Qt the right tool for many jobs.
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.
I'm someone who's cut his teeth developing desktop apps the 'old' way and came rather late to the whole modern web-development thing. And I have to say that going zero to a good enough prototype app is dramatically easier with web based stuff in most cases. Sure going from good enough to a polished high performing product can often be a massive pain, but that's a different story.
Honestly, at this point, HTML + associated frameworks like React/Angular are more mature for a lot of UI development than Qt is. Well, if you buy into the FRP/stateless UI things anyways.
Though interface builders help a lot, I've always had a problem building more dynamic interfaces through any of the native tools. React, for example, makes that a lot easier.
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
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...
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!
Trying to stop piracy through client-side technical means is always going to be a losing battle, becasue you can't trust the client. But you can embed native modules in Electron apps, so you can do whatever you were planning to do in native code to "verify" the installation, and then load JS only after decrypting it in native code. Compiling your licensing / decryption code for 3 platforms still beats having to maintain 3 copies of the whole app's source.
As others have said, you can never really truly protect things on the client side no matter what language tech you use.
We used Electron (well still called Atom-shell back when we started) for building Spectrum (https://www.devspectrum.com) which we charge per seat and it's been a great development experience and it's certainly performant enough to handle tons of local logging capture/filtering.
I've been thinking long and hard about this and I think one strategy, how stupid it might sound, is to release the software unfinished then make updates like SaaS.
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...
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.
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.
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.
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.
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?
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.
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)
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.
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.
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.
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
[+] [-] grinich|9 years ago|reply
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. :)
[+] [-] etatoby|9 years ago|reply
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!
[+] [-] Philipp__|9 years ago|reply
[+] [-] threatofrain|9 years ago|reply
[+] [-] Mister_Snuggles|9 years ago|reply
On the Mac: Can an Electron app be scripted with AppleScript? Can it hand off to a mobile app using the Handoff API? How is the accessibility?
Windows has similar things with COM and Continuity. Can an Electron app play nice with these technologies?
[+] [-] lawnchair_larry|9 years ago|reply
[+] [-] StevePerkins|9 years ago|reply
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.
[+] [-] bengotow|9 years ago|reply
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/
[+] [-] sievebrain|9 years ago|reply
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.
[+] [-] kuschku|9 years ago|reply
You practically have a window frame inside a window frame even! http://i.imgur.com/2C769ex.png
(Speed differences, the theming (dark theme for the whole UI, except for some electron apps?), etc are also issues.
[+] [-] lpsz|9 years ago|reply
* 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.
[+] [-] ksec|9 years ago|reply
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.
[+] [-] crucialfelix|9 years ago|reply
Ideally it should be run through webpack/etc and only a bundled, minimized version of the app is shipped. In practice some modules may have native compiled addons.
I'm working on an app right now and it ships at 247MB which is way too big.
release/darwin-x64/PlaySPLOM-darwin-x64/PlaySPLOM.app/Contents
107M ./Frameworks
12K ./MacOS
81M ./Resources
52M ./Resources/app/node_modules
[+] [-] marcosscriven|9 years ago|reply
EDIT - Ok, sorry, it seems quite a few people do have pretty horrendous bandwidth issues.
[+] [-] gbugniot|9 years ago|reply
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.
[+] [-] usaphp|9 years ago|reply
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.
[+] [-] wjoe|9 years ago|reply
Using web technologies to develop a GUI has been so much easier than learning a new toolkit, or even language. For one thing, some of the options you mentioned are OS specific. There are benefits to OS-native toolkits, but as a one-man team with a small project, the benefits are small and the time investment large. With Electron, I can build on Linux and release for Win/Mac without any concerns.
Qt is the best option of those you mentioned, and I considered it. But I was never great with C++, and learning a whole new markup language (or being tied to Qt Creator) for the UI was an extra barrier for entry. And I've often found that Qt programs don't look or feel right outside of Linux.
Personally, I find developing a UI on HTML/CSS/JS much easier than any desktop UI toolkit I've tried in the past. Updating the UI from the code, and calling code from the UI is s simple, because that's what it was designed to do. And having a browser console makes debugging and trying things so much easier.
I was never a fan of using JS for anything but websites before, but I decided to give Electron a try and I'm a convert. Perhaps there's enough of a speed difference between JS and native code that it would matter for more complex programs, but for my uses I don't notice a difference, thanks to the speed of JS engines now.
Maybe from someone that's starting with no coding knowledge would find Qt and C++ just as easy to pick up as HTML and JS, and certainly a C++ developer would find Qt a better choice. And sure, I don't expect anyone to be able to build Photoshop on top of Electron. But there are plenty of programs that aren't that complex.
While in theory I agree with not using the "new sexy technologies" for the sake of it, and "using the right tool for the job", I don't think that applies here. It works both ways, don't stick with old technologies just because that's what you're used to. What specific benefits do you get from using one of those toolkits for a simple desktop program?
[+] [-] bengotow|9 years ago|reply
[+] [-] spiderfarmer|9 years ago|reply
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.
[+] [-] dagw|9 years ago|reply
[+] [-] rtpg|9 years ago|reply
Though interface builders help a lot, I've always had a problem building more dynamic interfaces through any of the native tools. React, for example, makes that a lot easier.
[+] [-] based2|9 years ago|reply
[+] [-] Kiro|9 years ago|reply
[+] [-] serge2k|9 years ago|reply
Which part of Electron makes it wrong?
[+] [-] greenspot|9 years ago|reply
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
[+] [-] fsloth|9 years ago|reply
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|9 years ago|reply
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/tutori...
[+] [-] Sophistifunk|9 years ago|reply
[+] [-] frankwiles|9 years ago|reply
We used Electron (well still called Atom-shell back when we started) for building Spectrum (https://www.devspectrum.com) which we charge per seat and it's been a great development experience and it's certainly performant enough to handle tons of local logging capture/filtering.
[+] [-] voltagex_|9 years ago|reply
[+] [-] z3t4|9 years ago|reply
[+] [-] porker|9 years ago|reply
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...
[+] [-] albeva|9 years ago|reply
[+] [-] serge2k|9 years ago|reply
[+] [-] spiderfarmer|9 years ago|reply
[+] [-] proyb2|9 years ago|reply
[+] [-] asadlionpk|9 years ago|reply
[+] [-] jokoon|9 years ago|reply
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.
[+] [-] e0m|9 years ago|reply
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/23...
[+] [-] staticelf|9 years ago|reply
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__|9 years ago|reply
Maybe it's more of a memory leak thing that TypeScript doesn't have.
[+] [-] colordrops|9 years ago|reply
[+] [-] grinich|9 years ago|reply
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-ta...
[+] [-] unindented|9 years ago|reply
[+] [-] mherrmann|9 years ago|reply
[+] [-] twotavol|9 years ago|reply
* 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.
[+] [-] kristianp|9 years ago|reply
[+] [-] calsy|9 years ago|reply
No other language is in such a unique situation, so its wise for Electron to be JS centric moving towards the future.
[+] [-] grinich|9 years ago|reply
[+] [-] webXL|9 years ago|reply
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