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!
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
This is true given a dedicated enough programmer. Since most programmers aren't quite this dedicated, however, this isn't 100% true.
From what I am aware, in lower level (C++) development there are some definite strategies to "deter" piracy even at a technical level. Stuff that Urs (developer of u-He software synthesizers) talks about here, eg:
Basically:
A) Make the protective schemes as non-obvious as possible in a disassembler (obfuscation, making the copy protection part of some core routines etc.)
B) Provide a few obvious "sweeteners" that "pretend crack" the software for a period, but then show a "whoops your copy is pirated here's a offer to purchase it" later. (EG: a time bomb.) This allows the crackers to get their 0 day warez thrillz, without actually truly cracking the program.
Of course, none of this is 100% insurmountable. That's not the point of this exercise. The goal is to basically make cracking the software a chore more beyond usual, and therefore, not worth the typical cracker's time.
I am not sure how one would approach this with managed software or web-wrapped software (although if you can run the copy protection in a native module, that would be the way to go.)
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.
I don't think the issue is piracy per se. People want the ability to compile down the JS into native code for obfuscation reasons to prevent/discourage derivative works.
I know you can do that to some extent by minifying your JS code and I also know that no obfuscation or compilation technique is going to 100% prevent derivative works, but it helps a lot and it's a feature that many wish the Electron team would look into.
NW.js has it, but it's super hacky as it uses (abuses) the V8 snapshot feature to deliver the functionality, seriously degrading performance in the process.
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.
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.
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.
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?
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...
tl;dr: Ubiquity is a feature. Implementation simplicity enables ubiquity by making it easy to port and easy to bring new people on board. Implementation simplicity also frequently results in technical inferiority, but it doesn't matter, because users would rather have substandard software that runs quickly on all devices they target than excellent software that is either slow or unavailable.
Yes as bengotow said, I don't think its a matter of whether the language is weak/strong, rather its just a matter of circumstance.
The holy grail of web development has always been the ability to write web apps that can run across all popular browsers. I think many have been waiting for JS to be the language it should have been for so long now. Its seems the time has finally arrived and BAM! JS explosion.
JS is not bad at all (JS now that is), its an incredibly flexible language. This obviously annoys many as there are no hard and fast rules for development (framework hell anyone?) but as a language you can apply it to most any environment.
It's not technically inferior. I think historically many have confused not-like-java with technically inferior in Javascripts case. Combined with the fact that people who make client-side JS are less Real Developers (no true scotsman would code in js!).
JS is a dynamically typed functional language. Not unlike Scheme or Clojure. It's long history has made the standard library be a mix of programming styles, but I usually make heavy use of Ramda or Lodash and other functional wrappers to get a coherent interface nowadays.
What was a mistake was including `this` keyword though. Never use it, just like you would never do so in Scheme or Clojure. Carthago delenda est.
No upsides compared to what? Faster development time compared to Java, C-family languages is an upside. Faster VM (V8) than Ruby MRI, and just about every other dynamic scripting language, is also an upside. It's also an incredibly easy language to learn and write. Many of the weird inherent flaws went away with strict mode and ES5, ES2015 has helped make it much more elegant to read. Of course, you can always switch to a superior language like Elm that benefits from the same VM.
Oh, I did not mean to say that Javascript has no upsides whatsoever. It clearly does.
I meant to say that it has problems which have no upsides. By which I mean that it has certain weaknesses that contribute nothing to its good features and that could have been designed correctly without negatively impacting anything. They are just plain mistakes.
The unique problem you mention I think is vocal commenters that see "JavaScript" and immediately take a one-sided mentality against any tech stack that uses it.
Try to work with Javascript's arrays, it's a nightmare.
Fun fact:
let list = new Array(5);
list.forEach(() => { console.log("foo"); })
Will display nothing, if you want to properly initialize an array with a defined length, you have to do:
let list = Array.apply(null, Array(5)).map(function () {})
I make web games in Typescript, and I get all sorts of problems like this everytime I have to work with 2D arrays, problems that I don't get when I do games in C# with Unity. Unity's modified Javascript actually implements better arrays and recommends not using Javascript's native arrays: http://docs.unity3d.com/ScriptReference/Array.html
You seem to be trying to fit a square peg into a star-shaped hole. Arrays in JS are actually misnamed, they are actually Lists. For game scripting you may want to make heavy use of Typed Arrays [1], which are more like the arrays you seem to be looking for.
If you're saying that "initialize an array with a defined length" should be "initialize an empty array of 5 values of undefined" then yeah, but you can also use:
let list = Array.from(Array(5));
as new Array(5) creates an array of length 5, but each is a "hole"
I know the syntax is similar to C# or other languages, but because it's slightly different doesn't mean it doesn't bring anything to the table. JS or TS != C# in a browser the syntax is similar...
for loops will yield better performance and the result you want to get. If you're trying to log 5 times you shouldn't be wasting memory with allocating an array or needlessly calling the forEach function or needlessly creating a callback. You're just wasting garbage collection and cpu time with this
I think we can blame smartphone operating system developers for this. For so long they dug their heals in on only allowing certain languages run on their systems. But they also put a web browser on the phone, and then worked to make that browser match the desktop version as closely as possible. It was an escape hatch to be able to write cross-platform code, once and for all. Oh, sure, Android ran "Java", but it didn't include enough library commonalities with desktop to work. Same with iOS and Objective-C (which is practically unheard of outside of the Apple sphere). I've had far easier times getting one binary to run in Windows Mobile, desktop Windows, and Linux.
So I think there are very good social reasons why JS "won out." Perhaps it was the weakness of the language itself that made it possible. It didn't seem like a threat in 2008.
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.
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. :)
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.
In comparison to most GUI apps on Linux, this looks pretty good. It might not be perfect, but if i had to choose between no linux port, and a good-enough linux port, i'll choose the latter.
It looks "good", but not, as claimed by the Nylas team, "native".
Even Swing and JavaFX manage to make better looking, faster running, easier to code UI apps, which can be distributed smaller (the Java Runtime, thanks to Jigsaw, is smaller than the node+Chrome runtime of electron)
There basically is. Linux per se is just not a desktop OS, like Windows or OS X. Ubuntu has a standard UI, Debian's default install has a standard UI, Kubuntu has a standard UI, and so on.
That's even worse though. You can't ask for a universal GNU/Linux native appearance since there are Debian/Kubuntu/Ubuntu standards for UI. The list goes on and on too.
The problem with asking for a GNU/Linux standard application is there are several toolkits for developing them that stand out when not in the same base as the desktop environment. There is a single concise appearance to certain distros (e.g. Elementary), then difference of appearance in desktop environments (e.g. GNOME, KDE) and then there are the toolkits that are written completely different and use separate libraries (e.g. Qt, GTK).
By asking for a "Linux native application", you would need to create forks for GTK/Qt theming at the minimum and change the appearance altogether. It's just an absurd request really. One thing Electron does not do well is per-system graphical elements. It renders the same on every system so you either have a unique application design or you're conforming more to Window, Mac, or GNU/Linux. Or doom yourself to an old stale design, which is bland enough to fit in every category, but isn't the aim of the project.
You realize that GTK and Qt are both compatible with the other?
Most GTK apps work nicely under Qt (although this is very suboptimal), but especially Qt apps look native everywhere. From windows to mac to KDE-environments to Gtk-environments.
What do you mean by gtk under Qt? What about Tk apps, or Athena apps, or Motif, or GNUStep, etc.? There really is no such thing as a native Linux look and feel, you just happen to use a consistent selection of apps on your own system.
What I mean is that a Qt app will look native everywhere, and Gtk apps will look native in most places.
Most other toolkits, as you mentioned, don’t look native in many places, but Qt natively supports the CDE style, the Motif style, all different Windows and Mac styles, etc.
A Qt app looks native on Mac OSX, on Solaris, under Gnome, under KDE, under Windows XP, under Windows 10.
That’s why I avoid apps that aren’t either native or Qt anywhere, no matter if I am running Gnome or Windows, KDE or Mac.
Can you point me at an example of an app that does it really well? We couldn't find any compelling ones when we were investigating platforms for N1. :/
That’s the KDE Plasma Desktop – I am running it on ARCH Linux, but the new Kubuntu (which I have on my laptop, and looks exactly the same) http://www.kubuntu.org/ has the same desktop.
I'm going a little off-topic here, but i just found out about Nylas. What i don't understand is the Cloud integration. If i use Nylas with my IMAP account, does Nylas upload any data to your cloud?
Can i use it as a basic Mail.app/Thunderbird alternative, without leaking my personal data to your cloud?
Not the OP, but AFAIK, Nylas does store your email in their cloud.
This allows the client to be thin, since it's only using the APIs and is shielded from the intricacies of dealing with mail protocols like IMAP and SMTP. It also allows Nylas to offer a single API that works across all your email.
Building a larger Electron app myself, thank you SO much for opening up your code. There's a ton to be learned, like you said, about best practices with Electron. I"ve spent so much time shuffling things around and refactoring that I can appreciate a good foundation for consistent file trees.
>It will likely change your outlook on the future of desktop software. :)
Slow, with a 100MB node runtime eating up an entire CPU, piling hacks on hacks on React on top of the DOM, being dependant on Google's will to develop V8, written in JavaScript? That sounds like a pretty damn bleak future to me.
* I meant 100MB memory footprint. Office doesn't have a 7GB footprint.
* Office being a behemoth doesn't give a right to other apps to be whales.
* 100MB is just the runtime. Then you've got your application running on top of that, using whatever memory you want. The C/C++ runtime is not 100MB.
* Those 7GB probably include examples, layouts, whatever. Actual content. As opposed to Electron apps which are rarely more than just pretty interfaces making requests to a server. (With some high profile exceptions, like Atom, VSCode, ... Although they do send data to outside servers anyways :^))
* The Office suite is infinitely more complicated than anything done with Electron. That means features, technical debt, everything.
* Excel alone uses 86.1MB of private memory, and 142MB on a Blank Workbook.
* Where did you get this 100MB metric? VS Code uses 24MB Private, 86MB shared and I've got a ton of extensions added.
* No, most electron apps are offline apps.
* I doubt it. Creating performant HTML layouts and WebGL rendering all verified by independent 3rd party test suites is hard, dude. If someone came to you and said "Build a HTML engine or build Word" which would you choose?
* O'rly? Office 2016 add ins are built in JS, and there are built-in "addins"
>Excel alone uses 86.1MB of private memory, and 142MB on a Blank Workbook.
That is excel. With all its features. 100MB is Electron's base footprint. Running absolutely nothing. Write something as complex as excel with the same feature set, you're going to be way over 142MB with a blank workbook ;)
The 100MB metric comes from experimentation with both electron and electron based apps (VS Code, Atom, N1, Slack, ...). The main process hovers at around 80MB, but you also have countless node processes running. When node will be a default on machines (please, never), I'll stop adding those processes to the total, but meanwhile, they do count.
>I doubt it. Creating performant HTML layouts and WebGL rendering all verified by independent 3rd party test suites is hard, dude. If someone came to you and said "Build a HTML engine or build Word" which would you choose?
A) The electron developers do not develop a rendering engine. They do not develop a JS VM either. They develop a toolkit for desktop apps, which uses nodejs (which is highly dependent on Google not pulling the plug on V8) as well as Blink (which is highly dependent on Google). While I am not discounting their work, they are absolutely not the ones with their hands in the engine internals.
B) I would honestly build a rendering engine. Word has 25 years of backwards compatibility to keep, features and integrations with lots of other office software, etc. Rendering engines have a clear and defined spec. Microsoft hasn't clearly defined the DOCX spec (well, they did, but keep adding undocumented surprises. Just like XLS :^).
C) I'd ask for a team, because no single human being can replicate the feature set of either in his lifetime.
Add-ins in JS? Sure, run them in an another thread and keep them out of performant code and we'll be friends.
Not in the least, it's dynamically-typed with ecosystem libraries removing APIs by the dozen (upgrade your dependencies? prepare for days of verifying runtime errors of missing functions), and TypeScript is still a second-class citizen even despite the increasing amount of TypeScript-first libraries (like Angular2)...
Other than a little startup lag VS Code which runs on top of Electron performs very well on my computers, though they all have SSDs. As to performance and memory footprint vs. a statically compiled language/platform, yes, it's a bit heavier... that said, people are writing useful software with it, and able to deploy it cross platform, with minimal additional effort, and able to re-use components build for web based versions.
It's not ideal for some apps, but it's completely serviceable for most apps.
Oh I'm not contesting the fact that it's serviceable. Our job is to deliver software. I'm just slightly concerned by the absolute disregard for performance and power usage that is implied by using Electron.
Electron saved my ass when I was trying to come up with a simple solution for non-technical people trying to get their things done. So, thank you and team for doing this. I would like to see this achieve what Java couldn't.
I'm curious, and not willing to fill out a form to find out... it looks like N1 uses Nylas Cloud for data/services... that said, there's no actual published cost for this. I have several email accounts and would love a cloud/web version to access them all, combined with a standalone (desktop-ish) app, as the electron one... But I'm concerned about the pricing model, and with no openly published price, and no apparent income source, I am hesitant to even try the application.
Thanks for the work you are doing here, I feel that Email is one area that could use a lot of work.
Thanks, I didn't see an obvious link (should have clicked "more"), wound up on NylasCloud page, which did have pricing, but that linked to a contact form.
Might be worth having a Pricing link/button next to download, and from the Free column, to the download screen.
Also, since the data is all in your cloud, would be nice to have a "web" version, so that I could use the app without needing to install. That would be ideal for me, a web-mail app that I can manage all my accounts from anywhere, even when I'm not on my home computer.
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.)
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.
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.
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.
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.
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)
It is not allowed in the EU to gather data without informing the user and (in some cases) requiring opt-in. I think this is a very sane decision, even if it makes developers uncomfortable, because it is a privacy issue.
It is not usual to gather telemetry on the desktop, with perhaps the exception of some AppStore apps. Of course now that Microsoft got greedy and web developers are starting to develop desktop apps, we might see a different trend.
That depends on the data. I believe Atom uses the analytics privacy feature that deletes the last digits of the IP. That way it doesn't fall under the privacy directive.
Atom and Slack don't "feel" normal to me, they feel sluggish. They also take up a lot of resources (CPU, RAM). With what I'm running on a daily basis, I need all the resources I can get.
I think lpsz said it best, "It's cool for developers. It's not cool for the users". I'd qualify that with "It's cool for web developers".
Atom hovers at less than 5% usage between at least 5 separate workers for me. It's no 'ed' in terms of RAM but if it's under a gig it's fine by me. Certainly better than IntelliJ was in that respect.
Works pretty perfectly with rust as well. I have both a vim and an atom rust setup and they have near total feature parity.
I've experienced this with Atom. Seems to happen when the syntax highlighting code spikes the CPU usage as it attempts to highlight what you've typed and as a result the app waits for the highlighting code and your most recent keystrokes show up with a noticeable delay.
I had this with the ternjs plugin. Out of the box atom is pretty snappy on OS X. I haven't used Windows in a decade but I often see comparisons to Visual Studio accompanying complaints about Atom so my best guess is that it's either due to environment or a heavy plugin.
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).
"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.
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.
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 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.
It's still better than spending many months learning new language and not building anything functional at all. I would rather build something functional fast and see if it works and has demand.
If someone spend many months learning a new language, but still can't be able to build something functional with it, I think he has a bigger problem...
An Electron app is not equal to a native app when it comes to UX and UI. Right off the bat: they require more resources to run, thus making your computer slower, a laptops battery last less on a single charge, and don't look and work like native apps thus requires the user to learn a new paradigm.
So instead of you, the developer, using a couple of months to learn a new paradigm, you put that burden on your users, and end up with something that is a whole lot worse than standard native apps on Mac, Linux and Windows.
If you only have 1 user, that is no hassle, but if you have 5 million users, that is a whole lot of time that a whole lot of users needs to spend collectively because you are lazy and want to ship something fast instead of shipping something great.
And no, I have never tried a great Electron app. I don't think they exist.
> If you only have 1 user, that is no hassle, but if you have 5 million users, that is a whole lot of time that a whole lot of users needs to spend collectively because you are lazy and want to ship something fast instead of shipping something great.
Exactly. That's the externality a lot of software companies nowadays generate.
What are you talking about? Are you saying that because someone is adept at browsing Wikipedia or Hacker News, they intuitively know how to use Spotify and Slack and Atom?
How are you evaluating tool fitness here? The ultimate criteria for fitness are organizational / business goals, and that business or organization may have to juggle various constraints. Electron offers extra flexibility for businesses to make tradeoffs on app performance and size versus engineering cost, and that's its most important value.
At first glance, Electron apps should be more maintainable, not less, because it's one toolset for multiple platforms, which should translate to faster development time and less total cost of maintenance at the tradeoff of app performance and size.
Also, whether an app is difficult to maintain ought owe more whether (1) you have multiple diverse codebases and toolchains to maintain, and (2) that you have a disciplined engineering strategy.
Again, whether or not Electron is the right tool for the job is a business decision based on business constraints.
> How are you evaluating tool fitness here? The ultimate criteria for fitness are organizational / business goals, and that business or organization may have to juggle various constraints
Unfortunately, usability and ergonomics are rarely reflected in business "fitness functions" (hell, even making an actually useful tool rarely is these days, thanks in part to marketing having better ROI than delivering value). Business people take care of business goals, and I think it's our responsibility as developers to make applications that don't suck, whether or not it is reflected in the organizational "fitness function".
You realize that maybe for someone, C++/QT isn't a new technology but HTML/CSS/JS are? Or neither are new, or both are new? The person who replied to you was right, you are making the assumption that everyone knows the web stack and knows nothing else.
Electron tries to break the same barrier WebForms did but in the opposite direction. Hopefully it turns out better and doesn't result in a bunch of shitty desktop apps like WebForms resulted in a bunch of shitty web sites.
In all fairness, that's still a lowered barrier. The barrier is the sum of all parts, if desktop gui dev is easy for systems programmers and really hard for web devs, and this project makes it easy for web devs, then it has objectively lowered the barrier for entry. It doesn't matter if it's still just as hard for systems programmers.
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.
I think you have a very narrow view of "the community" and what constitutes "popular desktop apps".
What about applications like Photoshop, Premiere, Cubase, Logic? Basically anything that does more than show a couple of editor panes. I'd love to see these kinds of things built in Electron but as far as I can tell this has not happened yet. In these areas languages like C++ and frameworks like Qt are still really really popular. Not to mention embedded development, of course.
> What about applications like Photoshop, Premiere, Cubase, Logic?
That's the difference between toys and tools. Most of the popular applications are toys, and this saddens me a lot personally, because humanity is wasting the potential it has with all that cheap computing available.
> I'd love to see these kinds of things built in Electron but as far as I can tell this has not happened yet.
I don't see it happening any time soon. Web is not meant for serious tools. Compare Microsoft Office and Google's butt office suite. One is a tool, other is a toy that looks nice for simple documents, but is utterly unusable when your document/spreadsheet grows beyond more than a couple of pages.
> That's the difference between toys and tools. Most of the popular applications are toys, and this saddens me a lot personally, because humanity is wasting the potential it has with all that cheap computing available.
I always wonder if pretentious people realize their pretentious and simply don't care, or they're actually oblivious. Perhaps you could enlighten me?
The difference between a "toy" and a "tool" is whether or not something is mainly for fun or mainly for being productive. It has nothing to do with the process used to build it.
> I always wonder if pretentious people realize their pretentious and simply don't care, or they're actually oblivious. Perhaps you could enlighten me?
They're just tired and try to highlight some problems that others don't care about.
> The difference between a "toy" and a "tool" is whether or not something is mainly for fun or mainly for being productive. It has nothing to do with the process used to build it.
The difference is the goal - is it supposed to help people be productive at their task, or is it just supposed to make such impression while in fact being there to extract money from naive customers? (Or is it a worse-is-better half-assed 20% solution?). Whether you like it or not, performance is a big part of usefulness of application. I brought up MS Office and Google's cloud-based solutions for a reason - only one of them can handle the load a professional user needs to handle.
Quite often it's literally like a difference between a metal hammer[0] and a plastic one[1]. Both can, in theory, be used to drive nails, but there is kind of a difference in performance.
So what you're saying is, all tools need to be designed for the power user or they're toys. I guess I should return my $10 hammer I bought from Home Depot and replace it with the $225 Stiletto TB15MS solid titanium hammer (http://www.amazon.com/Stiletto-TB15MS-TiBone-Titanium-Straig...).
No, I'm saying that plastic hammers shouldn't be sold in hardware stores, and also that trying to push plastic hammers on normal users and $10 hammers on power users is a very bad trend.
I think the previous author's point was more on point without using judgement-loaded words like "toy". There certainly are definitely classes of applications where sheer computing complexity or responsiveness probably means that we're a long way off from using web wrapped applications (eg Electron). High end graphics editing, video editing, and music DAWs certainly qualify in this category.
Then again, from what I know, Premiere, Photoshop, and DAWs like Cubase and Logic are straight-up C++ applications, and don't even go into Java / Qt territory.
I would say that something like Google Apps vs Microsoft Office is a lot closer than it used to be. Native-app Excel sheets for instance still have the edge in speed overall, especially for large datasets (say, >10,000 rows) better, and Excel has a pretty significant edge in my opinion for analysis (pivot tables, charts, etc.). Google Sheets however are very capable for a large percentage of documents, with the added benefit of being so much easier to share and collaborate. Neither use case is a "toy" scenario in my opinion.
Maybe I'm conflating several of my issues with webapps in the word "toy". One thing is ergonomics, bloat and lag issues. But the other thing is that webapps trying to fill in the role that originally belonged to desktop apps are more often than not pretty dumbed down. There are several reasons for that - one is performance, which makes you unable to add more complex features without making the entire webapp unbearably slow. Another is the business approach of sticking to MVPs and not really progressing beyond them.
Also, lag issues are not really limited to high-end graphics / video editing. Sure, lag/low performance makes those tasks basically not doable in the browser. But even "ordinary" webapps - like word processors or issue trackers - are annoyingly slow. Take Jira for example - I'm probably wasting a few (billable) hours every month just because it's not a desktop app. So are all of my co-workers. It's most likely also the reason people tend to batch time reporting and do it once a week or so (it's much less distracting then), which as a result precludes management from having access to up-to-date information about time spent on tasks.
Trivial inconveniences can have non-obvious impact.
Communication overhead (which could be reduced with some additional caching client-side) is not the only source of the lag. User interface is a problem too. Sure, with enough work you may be able to overcome the problem in this (and similar) cases - but web apps are usually developed around a particular style, which involves AJAXing around way too much data way too often.
I definitely get what is being said here about web apps feeling slower. I've personally found desktop apps to in general be more responsive / quicker than web apps, and I think it's more than the communication layer. (Actually, I think REST is far more responsive than some of the previous middle tier communication methods used by desktop apps...).
From what I've heard (no in depth knowledge so I welcome corrections), the DOM / CSS model itself really wasn't designed for fast, responsive applications and thus tends to under-perform in that department. So even a fully internal network app with comparable communication speed may seem slower on the browser from the get go.
Many web apps often also tend to be a little bit laggy just based on their cloud based nature. Load a random spreadsheet on Google docs, and you are probably talking 100-200 requests and (depending on your network) perhaps a 5-7 second delay. Change a tab, and you probably have another 2-4 second delay. Compared to the 1 second load time of a spreadsheet and nearly instantaneous tab switching time on a native spreadsheet app, it feels slower... especially for the power users, I'm sure...
> Web is not meant for serious tools. Compare Microsoft Office and Google's butt office suite.
Well, isn't that an ambiguous claim with a weak anecdotal evidence. What is a "serious tool"? We have our email, crm, analytics, (only) shop, document versioning, etc. online. Actually, the native applications I use are just Visual Studio (can be replaced by code), Sql Management Studio (many web-based alternatives) and the browser itself - that being the only type of application I use with no web-based alternative, which could be seen as an operating system.
> Well, isn't that an ambiguous claim with a weak anecdotal evidence.
Try working on a 20-page document or 5-page-long spreadsheet and see how long it takes before you get pissed off at the performance. Unless you're oblivious to it - I'm starting to believe more and more people don't even expect anymore that computers can work without constant lags and pauses.
> the native applications I use are just Visual Studio (can be replaced by code)
Now can it, really?
> Sql Management Studio (many web-based alternatives)
We have a giant list of archived support tickets in Office 365. They can be navigated nearly as fast as they can be navigated in native Excel app, through the 365 web app.
I replaced Visual Studio already with Code for my personal projects. I expect it is just a matter of time before companies start to consider doing that too. Is it feature-complete? No, but not because it is an Electron-app, but because it's just young.
SQL Server doesn't work on platforms other than Windows so the motivation for coming-up a feature-complete alternative is little. I could even then find a couple promising projects with a web search. For other databases such as Postgres and Mongo, there are many alternatives which provide more than their native GUIs. Rethink's main GUI is web-based, for example. A database management interface isn't challenging to implement as a web-app because web-apps are limited toys, but it is hard to do right in general.
Meh. Microsoft Office pisses me off more with its constant crashes and weird bugs than Google Docs does. The latter has less functionality, but at least it's stable. Not to mention the vast majority of users don't need the advanced functionality anyway. If you're doing serious publishing work, sure, go ahead and use MS office. But 90% of common use cases are easily satisfied with Google Docs.
> Microsoft Office pisses me off more with its constant crashes and weird bugs than Google Docs does.
Crashes / weird bugs and MS Office... that's something new to me. I always considered MS Office to be a set of some of the most stable applications I've ever seen. Do you do something atypical, so that the bugs/crashes could be related to a platform or some rarely used features? I'm asking out of curiosity.
Google Docs et al. don't just lack advanced functionality, they lack a lot of quite basic functionality too. But my point wrt. webapps is also one of ergonomics. I do a lot of work in Google Docs and Spreadsheets due to external reasons, and I absolutely hate the experience. No matter how fast a computer I use, the lag on the Google's office suite is very annoying and distracting. Like with some IDEs which are slow enough to make one unable to ever enter the state of flow, Google's spreadsheets routinely double the time I am spending on a task due to simple lag on almost every operation.
>>Do you do something atypical, so that the bugs/crashes could be related to a platform or some rarely used features? I'm asking out of curiosity.
Not that I can tell. I mean I run it inside a Windows 7 VM, but other than that, nothing atypical.
One example of a bug that I can think of (because it happens consistently) is that Outlook 2013 taskbar icon shows the orange envelope to indicate that I have unread mail... when I don't have any. It drives me absolutely bonkers. I've also ran into more serious issues, for example yesterday when I pasted something from a web page into MS Word and it froze and crashed.
My needs are pretty standard. I run an NGO and have some amount of paperwork and data tracking to do in a word processor and spreadsheet application. Due to the collaboration requirements, we're stuck with Google cloud suite (the choice was made back when there were zero reasonable cloud-enabled alternatives). Google's office suite is theoretically capable of doing most of the things I need[0], but the omnipresent lag when you try to work with a bigger document or (more often) several documents at once is very annoying and slows things down. Half a second here, five seconds there, and it all adds up to significant frustration.
There's a significant difference between "theoretically X can be done with it" and "it is useful for doing X". You can drive nails with a plastic hammer after all (and most people don't even need the "additional" feature of pulling them out).
[0] - which is partly because I reduce expectations of what I can do. Think of it as generalized Blub paradox - you think in terms of the tools you use. Get a better tool, and suddenly you can do more, do it better and do it faster.
Atom and VSCode despite all the hype are subpar editors. Slow and resource hungry. Maybe suitable for script kiddies of today ... Slack is by no means a good sample of solid engineering. Spotify last I checked was native app written in c++. What's App is just wrapped website.
Your examples kind of prove the opposite point, these are not ALL popular apps, they are just popular "toy" apps. You weren't able to give a single example of a popular major application.
There are many web based ERPs and CRMs, some of which are way, way more complex than Photoshop. Given one has access to their algorithms, I don't see why Photoshop would be impossible to implement on top of WebGL. Photoshop UI doesn't have the "native feel" anyway. I think it's just a matter of time until Adobe comes with a 90% feature-complete web-based PS.
I'm sorry I wasn't more clear but I'm not talking just about the UI. It's also being able to give realtime feedback and do hugely CPU consuming tasks, which is essentially the core of Photoshop.
Can you give examples of ERPs or CRMs that are "way, way more complex than Photoshop" though? It would be nice to be able to compare.
By "toy" I don't mean that their purpose is necessarily entertainment, but that the difficulty of building them is not comparable to many popular desktop apps - the list is not representative. Like building a toy plane vs a real plane - the difficulty, not the purpose. Major computer games are not "toy apps" in this sense. Sorry if I was unclear.
The world development community is a weee bit larger than five. Neither is text editor and wrapper for a website "many jobs" ;)
I've seen many complaints about Spotify on e.g. Reddit - specifically about the fact that it's no longer native.
Seen also many complaints about bloat and slowness in Atom & VScode.
I understand why this toolkit is chosen, but companies can only push so much before the customers also push back against the decrease in qulity.
Comparing the developer experience between them makes it hard to argue that HTML/CSS/JS are the right tool for building GUI apps. The awkwardness of the web 'platform' is just huge, in comparison, even ignoring the performance issues. Atom and VSCode, for instance, have a long way to go to catch up with the real Visual Studio or IntelliJ.
The real reason you're seeing apps based on Electron these days is that it's easy to hire HTML/CSS developers. That doesn't mean these are good platforms though. I remember when the bulk of apps were being written in Visual Basic because it was easy to hire VB devs (lots of people learned VBA via MS Office).
I love your comment. But it basically says something else : programming is a lot about fashion. And nowadays, HTML/JS/CSS is fashionable and Qt is not anymore.
Everybody can yell that Qt/Gtk or even the MS stuff is the better tool for desktop apps, it won't change anything.
There's 0 objectivity in the choice. The young boys just think in HTML/JS, so we'd better adapt :-)
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.
While I consider web-tech in native a cancer I can't help, but agree. There is no good cross platform native UI library today. Few that are are stuck in 90s metaphor or poorly designed. Which I think is partly the reason why html-css-js is spreading everywhere.
I ask because I quite like JavaFX. The developer/documentation website is fusty and old-fashioned looking, but the tech itself is just really solid. You can tell it's been made by people who have spent their whole careers doing UI toolkits.
Mature and old are not the same thing. I don't think TkInter is stronger than React +Electron for building stable, large apps despite the large age difference.
One thing is that React is the newest iteration of production-quality declarative UI management. Angular, Backbone, a lot of stuff came bdfore. And all that contributes to a mature understanding
That being said, I forgot about QT quick. That is also pretty powerful stuff. Though the web influence seems there ( correct me if the causality is wrong).
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'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.
You used to be able to use Delphi or VB6 to make working desktop apps in very short times. I'm sure other will reminisce about other older desktop techs that were a breeze to use.
MS severely dropped the ball with WPF by making it have a very high learning curve just when javascript was really exploding. So not only was it easier to distribute web apps, they were cross platform and it was easier to make them too (although the massive pain of SPAs has changed that).
There was also Adobe Flash Builder that very briefly looked like it would be a competitor when Balsamiq was a big new thing, but it never really took off (only other thing I've seen use it is salesforce's SOQL tool). At that point everyone hated Adobe though, so it didn't have much chance.
Yea, for all the flack VB gets, it was pretty amazing. VB4 was what got me from writing silly little scripts for my own amusement to writing applications that could actually be used for something.
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.
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.
> 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.
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)
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.
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).
"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 ...
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?
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).
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.
Sydney certainly didn't seem like a 'metropolis' when I was there :) But seriously, Australia in general has poor internet bandwidth, by dint of its limited transoceanic cables, so I thought it was a fair comparison!
Last time I was in London, company headquaters had worse connection than my old home one in Poland. Generally whenever I went for business purposes, I was always surprised how slow business connections were...
Woah - I know many don't have fibre/cable, but I thought at least ~20Mbit speeds were the majority.
Where are you may I ask? Is that common where you live? Is it costly?
Very common in "rural" UK, where rural means 5 miles away from a city. You'd expect to pay £20-25 per month for the privilege (although note that this includes a "line rental" charge paid to the layer 1 provider - BT - of approx £15 per month)
Actually 20Mbit/s is a lot even in germany...
More likely to see 6 Mbit-16Mbit while some cities have 25/50/100 but if you are living outside of bigger cities (which most people do) you will end up between 6 Mbit-16Mbit and some area's are worse.
There is a point when convenience for lazy developers becomes bloat. Emacs is probably at that point - a runtime feature-full enough that you can get both a web browser, mail/news reader, presumably an irc client as well as a half-decent editor in a few tens of megabytes. Significantly more than a small talk runtime, that fits it's own blitter, dcvs and full IDE in under 10 MB.
What does the order of magnitude really gain the end user? A slower, less powerful GUI system?
Personally I think frameworks like Electron lead to huge bloat in terms of download size, disk space, and system ram. However there is no doubt that it increases the accessibility of developing applications for multiple platforms.
Does download size necessarily mean more system ram usage?
I agree on page weight, but somehow I'm more sympathetic to downloading apps, perhaps because it's just downloading in the background, rather than me waiting to read the content.
From what I understand, each instance of an electron app essentially needs its own copy of the electron framework to work (which includes a web renderer, and javascript engine). So we're talking at least 50MB per instance, for applications which may have been 10MB if written in a native language. When you start running many applications, it can certainly add up. Users do notice this kind of stuff, they are just too adaptive to bad user experiences.
As for downloads, I remember using dialup and only getting one 1MB file per hour. It would take a lot of patience to even download a 10MB app on that. I don't tend to leave my computer on downloading overnight these days though, and I 'only' get 1MB/s (dslreports.com says I'm "faster download than 60% on DSL in australia").
I have found these nodejs desktop apps to use less RAM than other more traditional Toolkits like Qt. I can live with more disk space being used if it means better memory usage
That's good news. I did some searching to find some real comparisons, but most of the links I found were related to memory leaks (nothing from 2016 though, perhaps outdated).
Extraordinary claims such as these need at least some sort of evidence. It does not make sense intuitively that a browser engine has a lower memory footprint.
I live in zone 2 in London, and the fastest broadband I can get is ~2Mbit. Even in major cities, good - or I would argue, even acceptable - broadband is not ubiquitous.
Not the OP, but in the same situation until I moved: Close-ish to an exchange (so no street cabinet on the line for fibre equipment), no cable coverage (so Virgin is out), out of range of wherever the hell Relish's tower is, and ancient wiring in a block of flats (so can't reach sane ADSL speeds).
Other people have covered the bandwidth angle, but I also think the size itself is an issue because of memory. And the more Electron can load into memory out-of-the-box or via default coding conventions, the more opportunities for poor memory management from developers. Since Electron is being used for utility apps, its bloat multiplies on a system with a lot of apps on it.
Also, Electron's size means more power draw. When I want enough battery life to do some work and still watch a long video afterwards, I habitually close Slack because it makes a worthwhile energy difference. The app's size reduces my engagement with the app after install. I'm aware my behavior is unusual, but developers do need to keep this in mind, especially as Windows and OSX make app energy use more transparent.
Not trying to defend Electron or larger app frameworks here, just trying to learn.
How do you make the link between app size and power draw (as opposed to some other aspect of Electron causing draw)? And, what are you comparing Electron's power draw to?
It might be a stretch to assume the effect will be significant, but...
A larger application presumably uses more RAM to itself (especially if its instances of node/chrome/libraries are distinct and so do not share pages by reference or in a copy-on-write manner with other similar applications) so there is less room for cache and buffers so the machine as a while is likely to be hitting disk more often and so consuming more power that way.
Loading the app will obviously involve more IO too, though hopefully that is not a regular occurrence for a full desktop app (it may be for a smaller utility program though) so the running costs should dwarf any start-up costs over time.
I don't think download speed is that much of an issue, whether or not you have good internet service, because I think people are willing to wait a little to download an app. The issue is more app size on modern computers that come with limited size SSD's and steep upgrade tiers.
If your app becomes successful, and you host it on a CDN, 200MB will consume a lot of bandwidth, creating costs that may prevent you from distributing it for free.
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.
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.
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.
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...
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.
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.
> 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.
Here's the thing: What's the #1 application that people use today on their desktops? Browsers.
There's a really high chance that you had another browser process open that was dedicated to writing your comment. Mobile included as the HA app is a Cordova-based solution.
But you feel compelled to say that thing that you used to accomplish your reading and commenting task was somehow slower and hogged your battery.
It got the job done didn't it?
Further, what's the #1 tech that some really smart people are focused on optimizing because of its usage. Yeah, again, the browser.
Show me another standards-based general UI stack that has had as much man hours dedicated to optimization... AWT/Swing/JavaFX? laugh. WPF, also really slow. WinForms? Not a lot of dev going on there at the moment.
An internet comment is a great example of a use case the browser is good for because it's low effort, low in specialized skills, and disposable.
Now we're talking about writing applications with web technologies for high specialized skill and high effort tasks, e.g., code editors, photoshop clones, etc... Which is what a lot of us are skeptical of. These "professional" applications are designed to reward a huge investment in muscle memory, if you are putting so much effort into learning an application, you don't want the return on that investment to be stunted by limitations in the technology the tool is built with.
Not following that last statement. There's no guarantee if I build my desktop application with XYZ framework that some technological limitation will crop up with it.
How much emphasis is being placed on JavaFX/Swing/AWT these days. Not so much. WPF? Microsoft has said that "...we are not investing in any major changes to WPF"
There is so much effort being placed in HTML/JS optimizations by WK, Blink, Edge folks that it's hard to find another framework with as much emphasis placed on it.
I'm talking about limitations in web apps that exist right now. For example with browser-based apps:
* Lack of data ownership, how do you export/backup?
* Poor keyboard shortcut support, e.g., constant conflicts between the browser itself and the app being run in the browser
With Electron based apps:
* Performance obviously, this might get better in the future, but that's a big bet of your time investment in learning and building on the tool. The fact that Atom is slow on a top-of-the-line machine is concerning. Sure that'll improve in time, but what if I also want to run it on more constrained device, tablets, etc...
* Electron apps still have a long ways to go to support basic platform expectations, e.g., on OS X Atom doesn't Services, AppleScript, or piping to the command line utility.
The problem with Electron isn't just the fact that it's browser based. It's that it's a different browser. If I run slack, spotify, atom, and an actual browser all at once, my computer is going to slow to a halt. What electron needs is some way to run in concert with my actual browser, or some kind of hub process that coordinates them to reduce the absurd memory and disk space footprint.
generally Chrome and IE/Edge spawn separate processes per tab for isolation, but will sometimes group them based on some conditions. On the flipside I'd hate to have some 3rd party program bring down my browser.
So I get what you're saying, but the worst case is that your browser will do the same thing for each tab.
Software like Excel which will spawn a different instance of Excel for each workbook, even though it could theoretically be a single process... so it's not like native apps are a panacea in your argument.
Slack and Spotify are two examples of apps that have gotten worse and worse. Slack is CPU heavy as hell. Spotify is laggy and feels like a website rather than a native app.
Electron apps don't appear to play nice with the underlying API.
Take Spotify and Slack, for example. It makes sense that it should expose its API via AppleScript (on Mac), COM (on Windows), and DBUS (on Linux). These let you do neat things like, for example, use a PowerShell (or bash or AppleScript) script to update your Slack status to the name of the track that's playing.
Whether you'd WANT that specific functionality or not is beside the point, the fact that the functionality exists means that people will do cool things with it. More importantly, it means that people will do things the developer never thought of.
Except, the underlying backend of an electron app is a local node.js server. It's not only easy to open up a local API for an Electron app, it's platform independent.
Platform independence is nice, but generally that means it plays poorly on every platform.
Looking at Atom's API docs, for example, tells me that there's a very rich API that doesn't appear to be exposed in any way that's native to the underlying platform.
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.
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. :)
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.
I was always afraid to say it out loud, but look of text editor really matters to me. That's why I can't return to Sublime, because Atom got me used so much to that Material + One Dark combo that I can't go anywhere else now. My Vim config got quiet big over the years so now it looks really really nice, and uniform.
I think, because I spend a lot of time staring at text editor/terminal I really want it to look satisfying and pleasant to my eye. It is not main thing that decides, but definitely is up there.
Sublime (3) is incredibly fast, both at handling huge files, indexing file names in huge directory trees, files with huge lines, complicated syntax highlighting... you name it. In my experience it felt faster than MacVim (which it supplanted) so I don't know what you're talking about.
I tried both Atom (ditched it after 30 seconds) and VS Code (tried to use it for a few days) but they cannot compete with a well-written native app.
With effort Electron apps can make use of Node native modules and do just about anything you want them to do.
In the peculiar Windows case, you can share much of your JS code with a "proper" UWP app as JS is a supported platform choice. With a bit of shim work you could even support almost all of the Electron API directly on top of the UWP.
I imagine that supporting AppleScript, etc, is a lot more common amongst developers that focus on MacOS vs developers that develop an application for three platforms.
As with any application platform, in some cases developers benefit from community effort and (ahem) platform effects: if, for example, a Mac OS developer really cares about AppleScript and builds a very good, simple way to provide it from an Electron application other developers might just do it because it is easy low hanging fruit to make Mac users happy. Theoretically it's even the case that if such a thing were used enough it might get baked into the Electron platform itself making it even easier to support.
Certainly if you can find a way to make it apply to multiple platforms (ie, "oh and this AppleScript tooling is similar for what we might want for IFTT support and these IoT platforms too"), then it has more value to a developer to support and makes it more likely that a developer will support it. (One example in Electron today is that most platforms have a concept of indicating progress status in their launchers/docks/taskbars, so Electron makes it easy to support all of the variations of that.) The complaint can be that in trying to build multi-platform supporting code is sometimes you get a "lowest common denominator" approach, but that leads us back to the original question that I answered which is that Electron certainly gives you the opportunity for developers to do the more specific things when they want to and isn't necessarily locked into "lowest common denominator".
From a general power user perspective: a cross-platform toolkit makes it more likely I see the application at all on my chosen platform; whatever the developers add to make it feel more comfortable to work with on my platform is a bonus.
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
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.
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?
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.
406 comments
[ 2.9 ms ] story [ 283 ms ] threadThe 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...
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...
From what I am aware, in lower level (C++) development there are some definite strategies to "deter" piracy even at a technical level. Stuff that Urs (developer of u-He software synthesizers) talks about here, eg:
https://www.kvraudio.com/forum/viewtopic.php?f=4&t=400768&st...
Basically: A) Make the protective schemes as non-obvious as possible in a disassembler (obfuscation, making the copy protection part of some core routines etc.) B) Provide a few obvious "sweeteners" that "pretend crack" the software for a period, but then show a "whoops your copy is pirated here's a offer to purchase it" later. (EG: a time bomb.) This allows the crackers to get their 0 day warez thrillz, without actually truly cracking the program.
Of course, none of this is 100% insurmountable. That's not the point of this exercise. The goal is to basically make cracking the software a chore more beyond usual, and therefore, not worth the typical cracker's time.
I am not sure how one would approach this with managed software or web-wrapped software (although if you can run the copy protection in a native module, that would be the way to go.)
I know you can do that to some extent by minifying your JS code and I also know that no obfuscation or compilation technique is going to 100% prevent derivative works, but it helps a lot and it's a feature that many wish the Electron team would look into.
NW.js has it, but it's super hacky as it uses (abuses) the V8 snapshot feature to deliver the functionality, seriously degrading performance in the process.
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.
No other language is in such a unique situation, so its wise for Electron to be JS centric moving towards the future.
https://github.com/lukehoban/es6features
tl;dr: Ubiquity is a feature. Implementation simplicity enables ubiquity by making it easy to port and easy to bring new people on board. Implementation simplicity also frequently results in technical inferiority, but it doesn't matter, because users would rather have substandard software that runs quickly on all devices they target than excellent software that is either slow or unavailable.
The holy grail of web development has always been the ability to write web apps that can run across all popular browsers. I think many have been waiting for JS to be the language it should have been for so long now. Its seems the time has finally arrived and BAM! JS explosion.
JS is not bad at all (JS now that is), its an incredibly flexible language. This obviously annoys many as there are no hard and fast rules for development (framework hell anyone?) but as a language you can apply it to most any environment.
JS is a dynamically typed functional language. Not unlike Scheme or Clojure. It's long history has made the standard library be a mix of programming styles, but I usually make heavy use of Ramda or Lodash and other functional wrappers to get a coherent interface nowadays.
What was a mistake was including `this` keyword though. Never use it, just like you would never do so in Scheme or Clojure. Carthago delenda est.
Come on. It has plenty of unique problems with no upsides. If that's not inferior, I don't know what is.
I meant to say that it has problems which have no upsides. By which I mean that it has certain weaknesses that contribute nothing to its good features and that could have been designed correctly without negatively impacting anything. They are just plain mistakes.
Fun fact:
Will display nothing, if you want to properly initialize an array with a defined length, you have to do: I make web games in Typescript, and I get all sorts of problems like this everytime I have to work with 2D arrays, problems that I don't get when I do games in C# with Unity. Unity's modified Javascript actually implements better arrays and recommends not using Javascript's native arrays: http://docs.unity3d.com/ScriptReference/Array.html[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...
for(let v of list) { console.log("foo"); }
If you're saying that "initialize an array with a defined length" should be "initialize an empty array of 5 values of undefined" then yeah, but you can also use:
let list = Array.from(Array(5));
as new Array(5) creates an array of length 5, but each is a "hole"
I know the syntax is similar to C# or other languages, but because it's slightly different doesn't mean it doesn't bring anything to the table. JS or TS != C# in a browser the syntax is similar...
So I think there are very good social reasons why JS "won out." Perhaps it was the weakness of the language itself that made it possible. It didn't seem like a threat in 2008.
https://blogs.s-osg.org/servo-the-embeddable-browser-engine/
https://github.com/servo/servo/labels/A-embedding
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. :)
You get 2 window bars, and 2 toolbars, nested in each other.
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.
Even Swing and JavaFX manage to make better looking, faster running, easier to code UI apps, which can be distributed smaller (the Java Runtime, thanks to Jigsaw, is smaller than the node+Chrome runtime of electron)
By asking for a "Linux native application", you would need to create forks for GTK/Qt theming at the minimum and change the appearance altogether. It's just an absurd request really. One thing Electron does not do well is per-system graphical elements. It renders the same on every system so you either have a unique application design or you're conforming more to Window, Mac, or GNU/Linux. Or doom yourself to an old stale design, which is bland enough to fit in every category, but isn't the aim of the project.
Most GTK apps work nicely under Qt (although this is very suboptimal), but especially Qt apps look native everywhere. From windows to mac to KDE-environments to Gtk-environments.
Most other toolkits, as you mentioned, don’t look native in many places, but Qt natively supports the CDE style, the Motif style, all different Windows and Mac styles, etc.
A Qt app looks native on Mac OSX, on Solaris, under Gnome, under KDE, under Windows XP, under Windows 10.
That’s why I avoid apps that aren’t either native or Qt anywhere, no matter if I am running Gnome or Windows, KDE or Mac.
Maybe detect the platform and use native icon packs when available?
Anyways it's amazing how good Linux have become that we could complain of such minor things ;)
[1] https://github.com/nylas/N1/issues?utf8=%E2%9C%93&q=is%3Aiss...
Incidentally, nice looking desktop! Which distribution is that, if I may ask?
The wallpaper is from http://imgur.com/gallery/dbELn
Can i use it as a basic Mail.app/Thunderbird alternative, without leaking my personal data to your cloud?
This allows the client to be thin, since it's only using the APIs and is shielded from the intricacies of dealing with mail protocols like IMAP and SMTP. It also allows Nylas to offer a single API that works across all your email.
https://support.nylas.com/hc/en-us/articles/217518207-Why-do...
Slow, with a 100MB node runtime eating up an entire CPU, piling hacks on hacks on React on top of the DOM, being dependant on Google's will to develop V8, written in JavaScript? That sounds like a pretty damn bleak future to me.
* Office being a behemoth doesn't give a right to other apps to be whales.
* 100MB is just the runtime. Then you've got your application running on top of that, using whatever memory you want. The C/C++ runtime is not 100MB.
* Those 7GB probably include examples, layouts, whatever. Actual content. As opposed to Electron apps which are rarely more than just pretty interfaces making requests to a server. (With some high profile exceptions, like Atom, VSCode, ... Although they do send data to outside servers anyways :^))
* The Office suite is infinitely more complicated than anything done with Electron. That means features, technical debt, everything.
* Office isn't running in fucking Javascript
* Excel alone uses 86.1MB of private memory, and 142MB on a Blank Workbook.
* Where did you get this 100MB metric? VS Code uses 24MB Private, 86MB shared and I've got a ton of extensions added.
* No, most electron apps are offline apps.
* I doubt it. Creating performant HTML layouts and WebGL rendering all verified by independent 3rd party test suites is hard, dude. If someone came to you and said "Build a HTML engine or build Word" which would you choose?
* O'rly? Office 2016 add ins are built in JS, and there are built-in "addins"
That is excel. With all its features. 100MB is Electron's base footprint. Running absolutely nothing. Write something as complex as excel with the same feature set, you're going to be way over 142MB with a blank workbook ;)
The 100MB metric comes from experimentation with both electron and electron based apps (VS Code, Atom, N1, Slack, ...). The main process hovers at around 80MB, but you also have countless node processes running. When node will be a default on machines (please, never), I'll stop adding those processes to the total, but meanwhile, they do count.
>I doubt it. Creating performant HTML layouts and WebGL rendering all verified by independent 3rd party test suites is hard, dude. If someone came to you and said "Build a HTML engine or build Word" which would you choose?
A) The electron developers do not develop a rendering engine. They do not develop a JS VM either. They develop a toolkit for desktop apps, which uses nodejs (which is highly dependent on Google not pulling the plug on V8) as well as Blink (which is highly dependent on Google). While I am not discounting their work, they are absolutely not the ones with their hands in the engine internals.
B) I would honestly build a rendering engine. Word has 25 years of backwards compatibility to keep, features and integrations with lots of other office software, etc. Rendering engines have a clear and defined spec. Microsoft hasn't clearly defined the DOCX spec (well, they did, but keep adding undocumented surprises. Just like XLS :^).
C) I'd ask for a team, because no single human being can replicate the feature set of either in his lifetime.
Add-ins in JS? Sure, run them in an another thread and keep them out of performant code and we'll be friends.
Yet. ;)
It's not ideal for some apps, but it's completely serviceable for most apps.
Thanks for the work you are doing here, I feel that Email is one area that could use a lot of work.
And you can read our blog post about announcing the pricing: https://nylas.com/blog/nylas-pro/
We haven't yet shipped the version which allows you to upgrade, but it's coming shortly.
Might be worth having a Pricing link/button next to download, and from the Free column, to the download screen.
Also, since the data is all in your cloud, would be nice to have a "web" version, so that I could use the app without needing to install. That would be ideal for me, a web-mail app that I can manage all my accounts from anywhere, even when I'm not on my home computer.
Just a few thoughts.
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.)
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...
1: https://catlight.io/
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/
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.
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.
It is not usual to gather telemetry on the desktop, with perhaps the exception of some AppStore apps. Of course now that Microsoft got greedy and web developers are starting to develop desktop apps, we might see a different trend.
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.
I think lpsz said it best, "It's cool for developers. It's not cool for the users". I'd qualify that with "It's cool for web developers".
Works pretty perfectly with rust as well. I have both a vim and an atom rust setup and they have near total feature parity.
Neither is a text editor that can't show letters as fast as a person types.
Not the only one: http://stackoverflow.com/questions/19617670/why-vs-2013-is-v... http://stackoverflow.com/questions/20545435/why-is-the-new-v...
www.meetup.com/Bay-Area-Electron-User-Group/
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.
Which part of Electron makes it wrong?
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 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.
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.
An Electron app is not equal to a native app when it comes to UX and UI. Right off the bat: they require more resources to run, thus making your computer slower, a laptops battery last less on a single charge, and don't look and work like native apps thus requires the user to learn a new paradigm.
So instead of you, the developer, using a couple of months to learn a new paradigm, you put that burden on your users, and end up with something that is a whole lot worse than standard native apps on Mac, Linux and Windows.
If you only have 1 user, that is no hassle, but if you have 5 million users, that is a whole lot of time that a whole lot of users needs to spend collectively because you are lazy and want to ship something fast instead of shipping something great.
And no, I have never tried a great Electron app. I don't think they exist.
Exactly. That's the externality a lot of software companies nowadays generate.
The barrier to entry for Electron apps is 0, the same as for native apps.
But yet you used a either a browser or the HN mobile app (cordova) to post here... guess that means function > fitness.
You get the picture.
At first glance, Electron apps should be more maintainable, not less, because it's one toolset for multiple platforms, which should translate to faster development time and less total cost of maintenance at the tradeoff of app performance and size.
Also, whether an app is difficult to maintain ought owe more whether (1) you have multiple diverse codebases and toolchains to maintain, and (2) that you have a disciplined engineering strategy.
Again, whether or not Electron is the right tool for the job is a business decision based on business constraints.
Unfortunately, usability and ergonomics are rarely reflected in business "fitness functions" (hell, even making an actually useful tool rarely is these days, thanks in part to marketing having better ROI than delivering value). Business people take care of business goals, and I think it's our responsibility as developers to make applications that don't suck, whether or not it is reflected in the organizational "fitness function".
Electron tries to break the same barrier WebForms did but in the opposite direction. Hopefully it turns out better and doesn't result in a bunch of shitty desktop apps like WebForms resulted in a bunch of shitty web sites.
What about applications like Photoshop, Premiere, Cubase, Logic? Basically anything that does more than show a couple of editor panes. I'd love to see these kinds of things built in Electron but as far as I can tell this has not happened yet. In these areas languages like C++ and frameworks like Qt are still really really popular. Not to mention embedded development, of course.
That's the difference between toys and tools. Most of the popular applications are toys, and this saddens me a lot personally, because humanity is wasting the potential it has with all that cheap computing available.
> I'd love to see these kinds of things built in Electron but as far as I can tell this has not happened yet.
I don't see it happening any time soon. Web is not meant for serious tools. Compare Microsoft Office and Google's butt office suite. One is a tool, other is a toy that looks nice for simple documents, but is utterly unusable when your document/spreadsheet grows beyond more than a couple of pages.
I always wonder if pretentious people realize their pretentious and simply don't care, or they're actually oblivious. Perhaps you could enlighten me?
The difference between a "toy" and a "tool" is whether or not something is mainly for fun or mainly for being productive. It has nothing to do with the process used to build it.
They're just tired and try to highlight some problems that others don't care about.
> The difference between a "toy" and a "tool" is whether or not something is mainly for fun or mainly for being productive. It has nothing to do with the process used to build it.
The difference is the goal - is it supposed to help people be productive at their task, or is it just supposed to make such impression while in fact being there to extract money from naive customers? (Or is it a worse-is-better half-assed 20% solution?). Whether you like it or not, performance is a big part of usefulness of application. I brought up MS Office and Google's cloud-based solutions for a reason - only one of them can handle the load a professional user needs to handle.
Quite often it's literally like a difference between a metal hammer[0] and a plastic one[1]. Both can, in theory, be used to drive nails, but there is kind of a difference in performance.
[0] - https://upload.wikimedia.org/wikipedia/commons/8/84/Claw-ham...
[1] - http://thumbs.dreamstime.com/z/plastic-hammer-2181534.jpg
Then again, from what I know, Premiere, Photoshop, and DAWs like Cubase and Logic are straight-up C++ applications, and don't even go into Java / Qt territory.
I would say that something like Google Apps vs Microsoft Office is a lot closer than it used to be. Native-app Excel sheets for instance still have the edge in speed overall, especially for large datasets (say, >10,000 rows) better, and Excel has a pretty significant edge in my opinion for analysis (pivot tables, charts, etc.). Google Sheets however are very capable for a large percentage of documents, with the added benefit of being so much easier to share and collaborate. Neither use case is a "toy" scenario in my opinion.
Also, lag issues are not really limited to high-end graphics / video editing. Sure, lag/low performance makes those tasks basically not doable in the browser. But even "ordinary" webapps - like word processors or issue trackers - are annoyingly slow. Take Jira for example - I'm probably wasting a few (billable) hours every month just because it's not a desktop app. So are all of my co-workers. It's most likely also the reason people tend to batch time reporting and do it once a week or so (it's much less distracting then), which as a result precludes management from having access to up-to-date information about time spent on tasks.
Trivial inconveniences can have non-obvious impact.
I think you'll find that Desktop apps often have to communicate with with centralized servers as well.
From what I've heard (no in depth knowledge so I welcome corrections), the DOM / CSS model itself really wasn't designed for fast, responsive applications and thus tends to under-perform in that department. So even a fully internal network app with comparable communication speed may seem slower on the browser from the get go.
Many web apps often also tend to be a little bit laggy just based on their cloud based nature. Load a random spreadsheet on Google docs, and you are probably talking 100-200 requests and (depending on your network) perhaps a 5-7 second delay. Change a tab, and you probably have another 2-4 second delay. Compared to the 1 second load time of a spreadsheet and nearly instantaneous tab switching time on a native spreadsheet app, it feels slower... especially for the power users, I'm sure...
Well, isn't that an ambiguous claim with a weak anecdotal evidence. What is a "serious tool"? We have our email, crm, analytics, (only) shop, document versioning, etc. online. Actually, the native applications I use are just Visual Studio (can be replaced by code), Sql Management Studio (many web-based alternatives) and the browser itself - that being the only type of application I use with no web-based alternative, which could be seen as an operating system.
Try working on a 20-page document or 5-page-long spreadsheet and see how long it takes before you get pissed off at the performance. Unless you're oblivious to it - I'm starting to believe more and more people don't even expect anymore that computers can work without constant lags and pauses.
> the native applications I use are just Visual Studio (can be replaced by code)
Now can it, really?
> Sql Management Studio (many web-based alternatives)
With even remotely similar feature sets?
I replaced Visual Studio already with Code for my personal projects. I expect it is just a matter of time before companies start to consider doing that too. Is it feature-complete? No, but not because it is an Electron-app, but because it's just young.
SQL Server doesn't work on platforms other than Windows so the motivation for coming-up a feature-complete alternative is little. I could even then find a couple promising projects with a web search. For other databases such as Postgres and Mongo, there are many alternatives which provide more than their native GUIs. Rethink's main GUI is web-based, for example. A database management interface isn't challenging to implement as a web-app because web-apps are limited toys, but it is hard to do right in general.
Crashes / weird bugs and MS Office... that's something new to me. I always considered MS Office to be a set of some of the most stable applications I've ever seen. Do you do something atypical, so that the bugs/crashes could be related to a platform or some rarely used features? I'm asking out of curiosity.
Google Docs et al. don't just lack advanced functionality, they lack a lot of quite basic functionality too. But my point wrt. webapps is also one of ergonomics. I do a lot of work in Google Docs and Spreadsheets due to external reasons, and I absolutely hate the experience. No matter how fast a computer I use, the lag on the Google's office suite is very annoying and distracting. Like with some IDEs which are slow enough to make one unable to ever enter the state of flow, Google's spreadsheets routinely double the time I am spending on a task due to simple lag on almost every operation.
Not that I can tell. I mean I run it inside a Windows 7 VM, but other than that, nothing atypical.
One example of a bug that I can think of (because it happens consistently) is that Outlook 2013 taskbar icon shows the orange envelope to indicate that I have unread mail... when I don't have any. It drives me absolutely bonkers. I've also ran into more serious issues, for example yesterday when I pasted something from a web page into MS Word and it froze and crashed.
Your needs are different, and that is cool - but it does not relegate web apps to "toy" status.
There's a significant difference between "theoretically X can be done with it" and "it is useful for doing X". You can drive nails with a plastic hammer after all (and most people don't even need the "additional" feature of pulling them out).
[0] - which is partly because I reduce expectations of what I can do. Think of it as generalized Blub paradox - you think in terms of the tools you use. Get a better tool, and suddenly you can do more, do it better and do it faster.
Can you give examples of ERPs or CRMs that are "way, way more complex than Photoshop" though? It would be nice to be able to compare.
I've seen many complaints about Spotify on e.g. Reddit - specifically about the fact that it's no longer native. Seen also many complaints about bloat and slowness in Atom & VScode.
I understand why this toolkit is chosen, but companies can only push so much before the customers also push back against the decrease in qulity.
The real reason you're seeing apps based on Electron these days is that it's easy to hire HTML/CSS developers. That doesn't mean these are good platforms though. I remember when the bulk of apps were being written in Visual Basic because it was easy to hire VB devs (lots of people learned VBA via MS Office).
You're right. They need to catch up to using 5.8 GB for Visual Studio and 480MB for IntellJ to start. :)
Everybody can yell that Qt/Gtk or even the MS stuff is the better tool for desktop apps, it won't change anything.
There's 0 objectivity in the choice. The young boys just think in HTML/JS, so we'd better adapt :-)
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.
I ask because I quite like JavaFX. The developer/documentation website is fusty and old-fashioned looking, but the tech itself is just really solid. You can tell it's been made by people who have spent their whole careers doing UI toolkits.
Try to stay at least a little bit realistic...
One thing is that React is the newest iteration of production-quality declarative UI management. Angular, Backbone, a lot of stuff came bdfore. And all that contributes to a mature understanding
That being said, I forgot about QT quick. That is also pretty powerful stuff. Though the web influence seems there ( correct me if the causality is wrong).
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?
You used to be able to use Delphi or VB6 to make working desktop apps in very short times. I'm sure other will reminisce about other older desktop techs that were a breeze to use.
MS severely dropped the ball with WPF by making it have a very high learning curve just when javascript was really exploding. So not only was it easier to distribute web apps, they were cross platform and it was easier to make them too (although the massive pain of SPAs has changed that).
There was also Adobe Flash Builder that very briefly looked like it would be a competitor when Balsamiq was a big new thing, but it never really took off (only other thing I've seen use it is salesforce's SOQL tool). At that point everyone hated Adobe though, so it didn't have much chance.
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.
(Case in point - Windows Vista :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.
Maybe it's more of a memory leak thing that TypeScript doesn't have.
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).
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/
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.
EDIT - Ok, sorry, it seems quite a few people do have pretty horrendous bandwidth issues.
Those data points aren't really as different as you seem to think :)
http://www.statista.com/statistics/381388/asia-average-inter...
What does the order of magnitude really gain the end user? A slower, less powerful GUI system?
I think the following is a great narrative on why it can matter though: http://blog.chriszacharias.com/page-weight-matters
I agree on page weight, but somehow I'm more sympathetic to downloading apps, perhaps because it's just downloading in the background, rather than me waiting to read the content.
As for downloads, I remember using dialup and only getting one 1MB file per hour. It would take a lot of patience to even download a 10MB app on that. I don't tend to leave my computer on downloading overnight these days though, and I 'only' get 1MB/s (dslreports.com says I'm "faster download than 60% on DSL in australia").
Also, Electron's size means more power draw. When I want enough battery life to do some work and still watch a long video afterwards, I habitually close Slack because it makes a worthwhile energy difference. The app's size reduces my engagement with the app after install. I'm aware my behavior is unusual, but developers do need to keep this in mind, especially as Windows and OSX make app energy use more transparent.
How do you make the link between app size and power draw (as opposed to some other aspect of Electron causing draw)? And, what are you comparing Electron's power draw to?
A larger application presumably uses more RAM to itself (especially if its instances of node/chrome/libraries are distinct and so do not share pages by reference or in a copy-on-write manner with other similar applications) so there is less room for cache and buffers so the machine as a while is likely to be hitting disk more often and so consuming more power that way.
Loading the app will obviously involve more IO too, though hopefully that is not a regular occurrence for a full desktop app (it may be for a smaller utility program though) so the running costs should dwarf any start-up costs over time.
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
a node module should be just runtime required code and LICENSE
Also, before packaging your Electron app use something like gulp to exclude problematic files like .md and anything else unnecessary.
There are other common tools like browserify that can still be leveraged.
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.
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...
* 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.
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.
There's a really high chance that you had another browser process open that was dedicated to writing your comment. Mobile included as the HA app is a Cordova-based solution.
But you feel compelled to say that thing that you used to accomplish your reading and commenting task was somehow slower and hogged your battery.
It got the job done didn't it?
Further, what's the #1 tech that some really smart people are focused on optimizing because of its usage. Yeah, again, the browser.
Show me another standards-based general UI stack that has had as much man hours dedicated to optimization... AWT/Swing/JavaFX? laugh. WPF, also really slow. WinForms? Not a lot of dev going on there at the moment.
List one that is MIT licensed...
GTK+ is LGPL 2.1 (not a problem unless you need to statically link).
Now we're talking about writing applications with web technologies for high specialized skill and high effort tasks, e.g., code editors, photoshop clones, etc... Which is what a lot of us are skeptical of. These "professional" applications are designed to reward a huge investment in muscle memory, if you are putting so much effort into learning an application, you don't want the return on that investment to be stunted by limitations in the technology the tool is built with.
How much emphasis is being placed on JavaFX/Swing/AWT these days. Not so much. WPF? Microsoft has said that "...we are not investing in any major changes to WPF"
There is so much effort being placed in HTML/JS optimizations by WK, Blink, Edge folks that it's hard to find another framework with as much emphasis placed on it.
* Lack of data ownership, how do you export/backup?
* Poor keyboard shortcut support, e.g., constant conflicts between the browser itself and the app being run in the browser
With Electron based apps:
* Performance obviously, this might get better in the future, but that's a big bet of your time investment in learning and building on the tool. The fact that Atom is slow on a top-of-the-line machine is concerning. Sure that'll improve in time, but what if I also want to run it on more constrained device, tablets, etc...
* Electron apps still have a long ways to go to support basic platform expectations, e.g., on OS X Atom doesn't Services, AppleScript, or piping to the command line utility.
So I get what you're saying, but the worst case is that your browser will do the same thing for each tab.
Software like Excel which will spawn a different instance of Excel for each workbook, even though it could theoretically be a single process... so it's not like native apps are a panacea in your argument.
Electron apps don't appear to play nice with the underlying API.
Take Spotify and Slack, for example. It makes sense that it should expose its API via AppleScript (on Mac), COM (on Windows), and DBUS (on Linux). These let you do neat things like, for example, use a PowerShell (or bash or AppleScript) script to update your Slack status to the name of the track that's playing.
Whether you'd WANT that specific functionality or not is beside the point, the fact that the functionality exists means that people will do cool things with it. More importantly, it means that people will do things the developer never thought of.
Looking at Atom's API docs, for example, tells me that there's a very rich API that doesn't appear to be exposed in any way that's native to the underlying platform.
[0]: http://code.visualstudio.com/Updates
I think, because I spend a lot of time staring at text editor/terminal I really want it to look satisfying and pleasant to my eye. It is not main thing that decides, but definitely is up there.
I tried both Atom (ditched it after 30 seconds) and VS Code (tried to use it for a few days) but they cannot compete with a well-written native app.
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?
In the peculiar Windows case, you can share much of your JS code with a "proper" UWP app as JS is a supported platform choice. With a bit of shim work you could even support almost all of the Electron API directly on top of the UWP.
I imagine that supporting AppleScript, etc, is a lot more common amongst developers that focus on MacOS vs developers that develop an application for three platforms.
As with any application platform, in some cases developers benefit from community effort and (ahem) platform effects: if, for example, a Mac OS developer really cares about AppleScript and builds a very good, simple way to provide it from an Electron application other developers might just do it because it is easy low hanging fruit to make Mac users happy. Theoretically it's even the case that if such a thing were used enough it might get baked into the Electron platform itself making it even easier to support.
Certainly if you can find a way to make it apply to multiple platforms (ie, "oh and this AppleScript tooling is similar for what we might want for IFTT support and these IoT platforms too"), then it has more value to a developer to support and makes it more likely that a developer will support it. (One example in Electron today is that most platforms have a concept of indicating progress status in their launchers/docks/taskbars, so Electron makes it easy to support all of the variations of that.) The complaint can be that in trying to build multi-platform supporting code is sometimes you get a "lowest common denominator" approach, but that leads us back to the original question that I answered which is that Electron certainly gives you the opportunity for developers to do the more specific things when they want to and isn't necessarily locked into "lowest common denominator".
From a general power user perspective: a cross-platform toolkit makes it more likely I see the application at all on my chosen platform; whatever the developers add to make it feel more comfortable to work with on my platform is a bonus.
Looks like it: https://github.com/electron/electron/pull/5352
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
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.
Is there an equivalent to this but with Python or C# ?
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.