This had me for the first half, where the author walks you through the 'case study' applications that offer minimal functionality despite shipping with an entire browser inside.
But then the essay turns into a rant. It's 2016, people, the ship has sailed on pretending JS isn't a real programming language. Phrasing the argument the way he does just betrays his smug elitism.
The fact is, for many types of applications, Electron is a really good fit: for example, shipping a single-page webapp as a desktop app, a need that surfaces often in today's world, despite his derision of this concept.
An Electron-wrapped SPA is safer than going to the same website in a multi-tabbed browser and co-mingling your disparate cookies in the same jar, not to mention more convenient for the users, because they can treat it like any other desktop application -- with hardware access, and subject to the OS' native task management.
For other apps, Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages. This is a huge boon for re-using knowledge, and perhaps does lead to some amateurish projects. Similar criticisms were leveled towards Visual Basic, where drag-and-drop composing and a good IDE enabled people to quickly crank out a GUI app from an idea.
>Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages
Just wanted to name the most obvious alternative: embedded browser component like QtWebKit, which allows to code most of the application logic on the language of your choice. Embedded browsers are the way people have been doing it since circa 2000 (by then, Windows was dominating platform and you could use embedded IE for rendering - the typical app size was much smaller than 200 Mb btw). I remember earning some money on a side project around that time - the CD catalog of bathroom equipment, which I implemented by borrowing huge part of my customer's website and embedding it in CBuilder app with few improvements for richer UX.
I'm fairly certain electron could easily be modified to be installed once and used as the launcher for its applications. I'm also fairly certain we'll see this in the future.
Therefore all claims that electron bloats 200Mb are just temporary. Its still a relatively young technology with huge potential (which also means huge potential for misuse!)
I spent 5+ years writing native GUI apps in half a dozen frameworks, I hope to never do so again unless the project's requirements ask for it, which I don't see happening for most use-cases out there.
Besides, almost nobody writes true native applications anymore - its all C# now which is ironic as its also extremely bloated with huge pools of average developers at best.
>I'm fairly certain electron could easily be modified to be installed once and used as the launcher for its applications.
That's fine, we can return to this topic when it will become a mature launcher app. The thing is that today it's not in that state yet.
>Besides, almost nobody writes true native applications anymore
True native applications are not just the applications written using some native API and platform-specific low level language. Native app is the app that comfortably exists within the operating system environment, follows the UI guidelines and integrates with native UX and performance enhancing functions of the OS. For example, some universal Windows app written on C# is native on Windows.
Dropbox itself takes 200Mb and its a simple python app. Google drive takes 300Mb. VSCode takes about 100Mb of ram with a project opened right now. Even my Emacs takes 250Mb and I literally live inside it.
All of them have at least 2Gb of virtual memory being mapped to them. Yet I still have 9Gb of free ram.
If you want to go against bloat, you might just as well uninstall every single software from your computer, including its OS.
Meanwhile my webserver that serves 8 websites (some static sites, some sophisticated web apps) sites at 80 MB used RAM. For everything. You can't make this up.
That's true, but I don't see anything in that list that needs to use multiple hundreds of MB of RAM. To witness, we had GUI apps in 1995. They look a bit nicer these days, but not multiple-100-MB nicer. :)
I currently have VS Code running with 7 files open, and it's using 83Mb. Like a browser, I imagine the RAM goes up with each tab, so it all depends on how many files you have open.
I was merely comparing an Electron app (VSCode, not at all an "online messenger") to average apps running on the desktop because your original comment implied "200Mb for the smallest apps" which isn't true.
Didn't Chrome already used to have that feature where you could install an application and it would put an icon on your desktop and open it in a browser window without tab/url bar?
But then you can't share the same code between your web application and desktop application. As a company you would have to pay two separate teams to develop each - developer time is expensive. Yes - electron apps are slower and eat more ram - but someone else is paying for that.
>Yes - electron apps are slower and eat more ram - but someone else is paying for that.
Not that there aren't a lot of posts here defending Electron that basically say the same thing but don't you feel embarrassed in the slightest for saying that?
Yes, there's a lot of things we, as coders, can do to make our lives more convenient by treating bandwidth, RAM, and CPU wastage as an externality that can be shoved off onto the end-user to pay for. That doesn't mean we should.
Doing something quick and dirty in electron takes N hours. Doing a 'proper' cross platform native app the right way takes N+P hours. If people are willing to pay for those extra P hours then I'd be more than happy to do things the 'right' way. However almost nobody is.
I've spent a lot of time on team web-apps-suck, and in many ways I'm still a casual fan. But the truth is I can go from zero to good enough much faster with web apps than anything else, and unfortunately most people only want to pay for good enough.
> Doing something quick and dirty in electron takes N hours. Doing a 'proper' cross platform native app the right way takes N+P hours.
Source?
Really, I'm not at all convinced that whipping up an Electron app is inherently quicker than whipping up a native app. Especially when we have robust, mature RAD tools for native toolkits, and things like Qt Quick, WPF, and Java FX let you go the whole "write your GUI in some markup language" route, if that's your bag.
Should you be sharing that code? Should there be any business logic in the UI, or should it be pushed back into services that can be shared across both?
Maybe not all the code, but you can share lot of the UI behaviour, which is usually quite complicated. This kind of sharing allows you to to have a very similar experience in both places too.
Valid argument, but only in case if that web app exists. But if it exists and you want to share the code, there's no point in using Electron or building a desktop app at all: you can just create a shortcut on the desktop or even turn it into offline web app in Chrome.
not really, there can be lots of reuse of code between the two apps without them being exactly the same. Reuse of major parts of your codebase have been a business case for many years, without requiring that you reuse all that codebase.
this is not valid. no need to limit our use case to devs, either. at worst, users don't care. at best, users prefer it. see Spotify, Discord, Skype, Sublime, Chrome, Steam... should i keep going?
whenever i open an app that uses entirely native controls i just expect the author didn't want to invest any time into making their app look good.
Native with minimal custom styled accents can be good looking, polished, and professional, and it doesn't throw platform conventions and features out the window to boot. Native looks bad only when the developer doesn't care.
I really don't think its such a great idea to reinvent the UI wheel, throwing the decades of research and refinement represented by native UI toolkits under the bus for the sake of branding and aesthetics, unless you have a good reason — a really good reason, like having to create brand new UI for a task that prior hadn't been performed on computers before.
I also see electron apps as stopgap measure, not a solution, and this feeling is reinforced every time I open up Activity Monitor and see Slack or Spotify sucking up upwards of half a gig of memory while sitting there doing nothing.
> I really don't think its such a great idea to reinvent the UI wheel, throwing the decades of research and refinement represented by native UI toolkits under the bus for the sake of branding and aesthetics, unless you have a good reason
It's a romantic thought, but that boat sailed a long time ago. Users got used to the web that had a very inconsistent UI between websites and on the website over time; before bootstrap, you would be hardpressed to find 2 websites with the same button styling. The last time the web used unstyled OS-controls was the 90s (with that default grey background - blech).
> whenever i open an app that uses entirely native controls i just expect the author didn't want to invest any time into making their app look good.
So much of this! This is my exact sentiment, too! If you want your application to look different from the OS-provided GUI—which I think is a good thing—without investing much effort into implementing your own rendering/painting engine, the web is an excellent platform, not to mention there's much more you gain with it, too.
What bothers me is that the author focuses on a few bad points of electron, whilst there are also many benefits to using it.
I agree. I never thought about it before, but I have to say that the vast majority of the apps I like the usability in do not look or feel native.
I don't know if there are any studies into what "users" want, but I'm with you. I prefer a UX that fits the app best, not the OS. Especially because in my experience I'm using the same app across multiple OSs and I'd like the same layout in each (within reason)
Well, if you'll accept a single data point, I dislike using them. If there's a native alternative I will always go for that. If there is not, then sometimes this tips the decision to not install.
Yeah I agree with you. This is very true in the Windows world, if an app uses entirely native widgets it looks very meh.
However, on Linux and Mac it's a little different. On Mac you'll see many apps compromise their branded style to look more Mac-like in style. Meanwhile on Linux most people use apps entirely fitted for their desktop environment, and then it's branded apps that look out of place. Windows attempted to make it's desktop more this way and failed with Windows 8.
> This is very true in the Windows world, if an app uses entirely native widgets it looks very meh.
Yes an no. Windows is very versatile when it comes to design. However, if you just drag-n-drop elements in Visual Studio[1] or Qt, you get that "ugly" windows app. You'll notice plenty of Microsoft's own designs (as part of the OS, or as external apps) that look very well and fit in with the rest of the OS. There are also a few gems from 3rd parties.
> On Mac you'll see many apps compromise their branded style to look more Mac-like in style.
I agree with this, but I also believe it's an "optical illusion" in the sense that the GUI isn't very Mac itself, but it just borrows some design conventions used by the OS to make it easier for the user to understand the application.
> Meanwhile on Linux most people use apps entirely fitted for their desktop environment, and then it's branded apps that look out of place.
As a full-time (or at least 99%) Linux user, I tend to disagree with this. I know what you mean and you're sometimes right, but it's not really that black and white. a GTK app on Qt/Plasma won't look that nice unless you go out of your way to make it look nice (which is usually a lot of work), and open another GTK app and realise it looks broken, so you need to add more tweaks, and then you open the third app and give up. Same goes for KDE/Qt apps on Gnome.
Please explain why looking good necessarily means looking different from the native controls. Isn't consistency among apps on a given platform important?
> It's 2016, people, the ship has sailed on pretending JS isn't a real programming language. Phrasing the argument the way he does just betrays his smug elitism.
Using the date as an argument is also poor form. JS is a terrible programming language (I'm not denying that it is a programming language though) regardless of how popular it is (although I think I might be going against the grain here on HN, many people here seem to enjoy node.js).
> The fact is, for many types of applications, Electron is a really good fit: for example, shipping a single-page webapp as a desktop app, a need that surfaces often in today's world, despite his derision of this concept.
I feel it's unreasonable to turn a single web page into a desktop app by bundling an entire web browser with it.
> ...because they can treat it like any other desktop application -- with hardware access, and subject to the OS' native task management.
If you need direct hardware access it probably isn't well-suited to being a web app in the first place? Why use web technologies for it then?
> For other apps, Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages. This is a huge boon for re-using knowledge, and perhaps does lead to some amateurish projects. Similar criticisms were leveled towards Visual Basic, where drag-and-drop composing and a good IDE enabled people to quickly crank out a GUI app from an idea.
HTML/CSS can be nice to have in such a situation, although a refusal to learn other GUI frameworks probably makes for a poor (native) developer.
The resource bloat and (usually) extreme disparity with the native user interface rarely makes it worthwhile for me to use an electron app. It feels like forcing a square peg into a round hole because the developer is seemingly unwilling to consider more appropriate technologies outside of their comfort zone. Yes, there are well-made electron apps (like VS Code mentioned in the article), but I, personally, would hate for it to become the norm.
> the developer is seemingly unwilling to consider more appropriate technologies outside of their comfort zone
The very same can be said about people looking down on Electron. Most of them can't write decent native apps to begin with.
I used all of win32, Qt, GTK, wx and Cocoa to name but a few. They all suck in one way or another. Suggesting people are poor native developers for refusing to learn these frameworks completely disregards the fact that most people using these frameworks are bad developers to begin with.
For the average application going native will easily triple your development time and costs for absolutely no noticeable performance difference.
> If you need direct hardware access it probably isn't well-suited to being a web app in the first place? Why use web technologies for it then?
What if the only difference between the web and desktop apps are that the desktop app can open local files while the web app downloads them? Are you going to write two apps in that case? This would be a mediocre economical choice at best as you're more than doubling the production costs for a difference nobody is going to care about.
And they're all mediocre when compared to Vim/Emacs (and these are both inferior to Spacemacs which actually combines these two.)
Why isn't everyone using Spacemacs then?
Visual Studio is much, much slower than all of them yet its still an incredibly popular IDE for some reason. It has endless flaws, one of them being its still 32-bit and often crashes on larger projects. (The last game I ported to the PSVita would hang VS for minutes sometimes, often ending with out-of-memory errors, we'd reboot VS between every profiling session.)
For a good chunk of users, features and ease of use are more important than performance (especially when most of the time it really, really doesn't matter for an editor.)
I can never see the point of comments like these. Not one person who reads that will have his mind changed.
HTML/CSS can be nice to have in such a situation, although a refusal to learn other GUI frameworks probably makes for a poor (native) developer.
No it doesn't. Either the developer benefits or doesn't benefit from "refusing". There's only so much time in the day. I'll refuse to to learn Qt or gtk+, unless there is some overwhelming benefit for me to learn it.
> I can never see the point of comments like these. Not one person who reads that will have his mind changed.
I wasn't expecting to change anyone's mind with that. There are more robust programming languages that don't have the same inconsistencies and idiosyncrasies and encourages better practices in general (even though it is true than you can write terrible code in any language).
> No it doesn't. Either the developer benefits or doesn't benefit from "refusing". There's only so much time in the day. I'll refuse to to learn Qt or gtk+, unless there is some overwhelming benefit for me to learn it.
That is true, but consider that the end product is not necessarily meant to be most convenient for the developer. Keeping the user in mind when making these decisions may make you consider more native and less resource-intensive alternatives. I have read in the past that Electron also posed some difficulties for screen readers, for example (although I'm not sure if that is still the case), which might not be something that impacts you as the developer, but which can make it harder for someone to make use of your software.
This means absolutely nothing. Otherwise everyone would be using Haskell, Coq or Agda. I'm willing to bet your favorite language has an insane amount of flaws as well (hint - they ALL do, otherwise we'd have converged to the "one true language" as an industry long, long ago.)
You can make an argument to say C++ is terrible, Java is, Ruby is, Python is, and it means absolutely nothing other than showing of your own insecurities. You can build great and mediocre things in any language and any platform. People do every day.
Also, if the developer is not one of the users of the software, you've already thrown a good chunk of quality out the window right there. You're simply not going to have the vision required to build the optimal user experience.
> Keeping the user in mind when making these decisions may make you consider more native and less resource-intensive alternatives
Usually the choice for the user is between "have an electron app in a month" and "have native app in a year", most users prefer to not wait, and when native app comes in a year, electron app will have much more polish, and run acceptably on new hardware.
The issue is not about 'protecting poor users'.
Most electron apps are quick experiments, to test out an idea without spending too much resources on it.
If idea is great, and performance is an issue, and there are enough users to get a team of highly skilled developers to work on it, they'll create native app, replace electron version (and then embed js vm to support plugins:).
> but consider that the end product is not
> necessarily meant to be most convenient
> for the developer.
Sorry, but life isn't fair. Everything including software involves trade-offs, and perhaps ones that you would not have made yourself.
For that reason, your post along with the blog post comes off as a tantrum. And if users really cared about these things, then surely you'd be able to swoop in and capitalize on it. But we both know that's not happening.
> I can never see the point of comments like these.
At minimum, I think the hope is that js-only programmers become aware that there are alternatives. And hear that the people who use those alternatives often find them better.
The arrogance in it, though, is that because people who like JS are "obviously" wrong, the reason must be that they don't know (enough) other programming languages or don't know them well enough.
I have used a number of different programming languages before JS, a couple of them more extensively and for a longer time than JS. I like JS. I understand its flaws. I also understand that all programming languages are terrible in their own unique ways -- I have accepted JavaScript's terribleness and a lot of it is addressed by ES2015 and beyond. I prefer JS's terribleness over that of other languages.
I like to make fun of PHP programmers the same way, but I understand that there are PHP programmers who are able to see beauty in PHP or have found their own perspective of PHP which makes it less terrible than the alternatives. I'm not one of them but I can relate to them. It's called empathy. OP lacks it.
First, X-only programmers are obviously wrong, whatever is the value of X.
That said, yes, somebody ought to love JS in a not blind way. Big numbers work that way. If that's you, I don't think those comments are for you. All languages have different flaws, every flaw relevance varies by context, and contexts are incredibly subjective. Yet, some contexts are much more common than others, and many people preach in support languages that are harming them because they don't know any better.
I did C, C++, Java, PHP, VBA and JS and can't tell why so many people have constant beef with JS. I mean especially after all major platforms have adopted ES2015.
IO in what? The browser? Node? If you mean node, what IO specifically? `http.createServer`? `fs.readFileSync`? `fs.createReadStream`? `fs.open`? `fs.readFile` with node callbacks? Promises? Streams? Observables?
Without context it sounds like you saw a bunch of nested callbacks in a Node.js example and judge the entire language based on that.
You'd be surprised how many people I've met that enjoy JavaScript. Nearly everyone I've met that hates JavaScript either didn't bother to learn it ("It's just a scripting language") or is just upset that they can't use their favourite programming language all the time (this is how we ended up with CoffeeScript, Sass and Haml and why everything in the Java world is eventually wrapped in XML).
I've seen enough different use cases and teams and programming languages to understand there's no point in being arrogant about language choice: if a team already knows a given language, it is most likely the right tool for the task, unless the benefits of replacing it are worth the overhead of properly switching to and gaining competence in another language.
Sorry, JavaScript may have gotten lucky being the lingua franca of the web, and it might not be perfect or even great, but it's "good enough" for most purposes these days.
If it were "terrible" you would expect at least one compile-to-JS [1] to have gained a non-trivial amount of traction by now. The supersets of JavaScript like Babel, TypeScript, and Flow are more popular than "not terrible" languages like ClojureScript, Elm, etc.
Lisp is marginally better, because it tries less hard to work around type mismatches (so something like (+ 1 "") is an error). But it suffers from the same fundamental problem: no type checks until runtime.
It's fine to have some kind of option for data whose type isn't known until runtime. This stuff happens, and languages that insist there's no such thing make dealing with it more difficult. But this is the rarer case! Why optimise for it rather than for the more common one?
> It feels like forcing a square peg into a round hole because the
> developer is seemingly unwilling to consider more appropriate
> technologies outside of their comfort zone
Until I find out I'm immortal, the "right tool" is typically the one that lets me launch the fastest.
It just makes you feel good to dismiss other people as lazy or unwilling to venture outside their comfort zone, but that's more of a revelation about how you view others.
"Electron is a really good fit: for example, shipping a
single-page webapp as a desktop app, a need that
surfaces often in today's world, despite his derision
of this concept."
From a systems perspective that is emminently rant worthy, it indicates the system has completely failed the developer who cannot easily express what they can in a single page web app as a real application in the system.
Not at all. It simply indicates the system has a radically different interface than the web. And that web APIs have evolved incredibly more than system ones when it comes to building quality UX.
Its no wonder all the best native applications ALL use proprietary toolkits. Adobe being a prime example. Such a toolkit is orders of magnitude easier to reproduce in HTML/CSS than it is in any of Qt/GTK/wx and others.
Thinking a web app can easily be expressed as a systems application grossly overlooks the complexity web apps have scaled to.
The only native toolkit I've ever tried that I thought could compete with web is wpf. It was slow and cludgy but way ahead of its time, and the web is only now starting to approach its power.
I think WPF is nice but has actually fallen behind a bit on binding vs. some of the web toolkits like React/Redux, Angular 2, Ember.
It's been a while since I messed with it, but MVVM didn't work so well for some kinds of things, which seemed to be why for example selected items property is often not a dependency property of MS supplied widgets (so can't be participate in binding). For example see http://stackoverflow.com/questions/22868445/wpf-binding-sele... (from what I remember this accepted solution also has a subtle bug of double notification (or was it lack of notification on one side?)).
Perhaps WPF was the Electron of its time, in terms of being a resource hog. I remember how one particular WPF-based application hastened the obsolescence of my brother's laptop some years ago. [1]
The point you're actually making is that the decision to build a desktop app with Electron is almost always a business decision and not a technical one. If you already have all this SPA code that you built, it's going to be cheaper to re-use it and provide the same UI to the end user that they already know from your SPA.
Forget for a second that the performance will be terrible because it's not native code. Forget for a second that a desktop application typically benefits from a more dense UI than a web application, and may benefit from such desktop-only UI features such as separate tooltip windows or OpenGL rendering (yes you can do that in a browser but come on it's not the same). The fact of the matter is that the beancounters typically care less about delivering the best possible UX and more about how their bottom line is going to be affected as they continue the corporate strategy of expending 20% of the effort to get 80% of the potential business benefit.
Electron was built for the beancounters. Not for the HN purists. Simple as that.
Is that necessarily a bad thing? I'll throw a great counter-example to you, Mattermost. It's a great open source project that uses Electron to build a client app for just about every single platform.
Have you maintained a cross-platform app for Windows, OSX, and all the various flavor of linux? I have, it's hell. You have compiler differences, ui semantic differences and a litany of per-platform quirks.
Does Electron solve every single use case? No. However in the cases where it makes sense it's a great tool.
I disagree, the first case study app revealed flawed logic. lossless-cut is a _visual_ tool for trimming videos. Author derides it by comparing it to the underlying ffmpeg command but that misses the point entirely: I can't magically divine where the start and end is. I need to see the video to determine the times. This tool provides an easy way to see the video and step until I find the right start and end points. There are plenty of frontends to ffmpeg that do similar tasks, and I really wish the author explored some of them to see how they compare to the electron solution.
Essays like these, along with Thanksgiving conversations with older extended family, are what really make me question the wisdom of eternal life. What if all the people stuck in the past like this were with us forever?
I can understand the author's frustration with popular tools being very simple and somewhat overkill underneath, but I almost take it as a sense of frustration with himself.
Electron was built to ship products as soon as possible. Most of the time, no one gives a flying fuck if the tech stack is the "right" choice and as efficient as it can be. I'd be willing to bet my net worth your users don't care at all how you built it, just that it does what they want it to do.
In the end, for most companies, it's more about shipping product that sells than spending 5x more time writing it in C# because "you're an engineer so you should act like an engineer." That's not how the world works. And until you figure that out, you'll constantly be left behind by others who made compromises to capitalize on the market.
I concur in that performance and security are very important in building software. I would, however, opt for a less performant version of a product if that means releasing it a couple months earlier than the alternative.
I think it's possible to build very well performing applications on a tool like Electron, and once the market has proven that your product is in heavy demand, then you can re-approach it and decide to go native or revamp it using some lower level tools.
First off, JS is a perfectly usable language. In some respects, it's even great: of the "big three" scripting languages (Python/Ruby/JS), it's the only one that got Lambdas right, and also got closures right (unlike, say, Python). It has sometimes-quirky syntax, and some odd semantics, but they don't bite as often as you'd think.
Second off, I would say that this article is right about the bulk of Electron: It's a pretty massive thing to lug around with your app, and not ideal in any sense. However, if you want to build a UI very fast, there is nothing better than HTML/CSS for it. Except maybe TK.
Speaking of TK, I would actually advocate TK over Electron: it's easy to use, has bindings to pretty much every language out there, and with TTK, it doesn't look like crap.
Finally, "considered harmful" essays rarely do any good, and frequently do harm.
So yes, while I usually like Drew's writing (at least a little: he's good, but far from the best), I wish he had spent the time he spent writing this doing more work on SCAS.
Seriously. If SCAS was actually done, and documented, and usable, that would be great. There is a freaking vacuum of good assemblers for the platform: another one would be nice.
Hello again, qwerty'. Thanks for stepping up on the JS issue :-)
There are many good languages out there, "when used as directed". Alas, out here in the flyover country of Sacramento, there is really only demand for 3 kinds of jobs: Java, C#.NET (falling off), and some Javascript, ignoring the long tail of one-of-a-kind shops. Given those choices, I'll take the Javascript. Java 8 lambdas are clumsy to use to assemble much in the way of higher order functions.
I mean, cuz, who doesn't want to put this as a parameter into a function/method header:
E.g. - for the sake of argument, say I needed a callback to merge two associative arrays. Oh, you needed a third input argument? Write your own interface type, so you can use it to declare the callback parameter.
No, I'll take the JS, thank you very much.
(as we discussed a month or two ago, Java is a [somewhat] new Business Oriented Language, and it's pretty Common)
First off, it gets a lot of (undeserved) hate from the Java-type people who think they know what OO is, but don't (because Java isn't OO, or so says Kay, and even if it is, there's a whole lot of rubbish mixed in. For that matter, I don't think JS qualifies either, by Kay's definition, but it's closer). These are the people who say things like, "How can it be OO if it doesn't have classes?" and, "where are my Refactoring tools?" or "Design Patterns!" and implement a bunch of java-esque "classes," and proceed to write IteratorStrategyFactoryManagerService (speaking of which, if you have any actual "classes" in JS with the word "Strategy" in the name, indicating they implement the GoF Strategy pattern, you should stop now. And feel bad about yourself. But that's another story).
With ES6, we have "classes," so these people can stop complaining, but it's still bad, because they're actually syntactic surgar over prototypes, so you still need to understand prototypes (to say nothing of how "this" works, a genunine mess in JS, but a necessary one), but it's no longer obvious that that's what's happening, so you might think that you don't.
The more significant complaints are about Javascript's famous weak typing (quick, what's []+""? What about ""+[]? And {}+[]?), ASI (which is why if you're returning an object/array, you can't put the openbrace or openbracket on the next line, and why semicolons only sometimes matter), and general quirkiness (the aforementioned this, and so on).
These are actually legitimate reasons to dislike JS, but in my experience, they're not as severe issues as they're made out to be. If you really can't take it, though, TS or Flow can help you.
One of the main benefits of OOP is of course "polymorphism" (abstract base classes, interfaces), so naming any concrete class a "strategy" does seem a bit redundant.
From what I have read by/about Kay, it sounds like his vision of OOP was very much about the actor (message queue) model, rather than (just?) a Simula 67 interface/protocol method table structure.
As for the goofy "nonsense evaluation" in JS, it is a bit unfortunate, but I guess I must just write less nonsense than some others, as this doesn't seem to be a real problem for me :-)
In fairness, the JS I write is client side, and it usually doesn't take very long to get to a state to test new code, as opposed to a long batch process.
>One of the main benefits of OOP is of course "polymorphism" (abstract base classes, interfaces), so naming any concrete class a "strategy" does seem a bit redundant.
There are no abstract classes in JS: there doesn't need to be.
Anyways, that's not what I mean: I was talking about the Strategy design pattern, which is actually a way of implementing higher order functions in languages that don't have them: thus, implementing classes for it in JS would be very silly indeed.
As for Kay's vision of OO, it involves not only everything being an object, but extreme late binding. Java has neither.
OK, gotcha. Somehow, I thought "strategy" was more general than just a single method/function to plug in. (confession: I have the GoF book, but don't remember every section)
I think one of the best points PG (of YC) ever made was about programmers thinking in a particular language. "If Blub doesn't do it, you don't need it" (paraphrasing). Convincing the C++/Java/C# fans they need other features sometimes is quite hard.
The answer doesn't really end up being static vs dynamic, but rather how dynamic languages often lack the other facilities that make programming in the large easier, and Eric Lippert uses js as an example.
Companies with a lot of money at stake have spent a lot of money and effort on things that transpile to js. The people making these decisions are almost always quite smart and very practical. They don't care if first class functions are sexy. They just want to write high quality code quickly. If they've spent so much time wrapping it up, you know it's because they had serious issues being productive at scale with js. They, and people on their team, probably got extremely frustrated along the way. Hence the hate.
Part of the problem is education. Back in the day (70s, early 80s), many people were tackling hard computer problems (formerly known as "AI") with languages like Lisp (Scheme, et al), rather than Simula 67 (C++, Delphi, Java, et al). Not me, I was a student, but I did see that stuff.
Enter the microcomputer in the mid 80s, with its 16 bit memory model and single wimpy core. (ignoring 8 bit toys). Running a garbage collector on such meager machines wasn't practical, so malloc/new and free/destroy it is, then! (yes, the irony is precious when Java appears a decade later)
After the early 90s, the Simula programming model has been pretty much the only thing taught to developers - a few self-taught people perhaps aside - so it's the only way they think.
Trying to convince these people that large chunks of their logic should be immutable data, processed in a "one way path" (directed acyclic graph) through functions, some of which are built of or build other functions, and that input and output types (which can be traced backwards and often inferred rather easily) can be assembled "on the fly" makes no sense to them.
It's almost like standing on a box on the street corner and trying to preach at people in Greek. They don't understand a word you are saying. "Get these freaky cultists out of here!" :-)
By the way, there is nothing like Scheme + Emacs for interactive development. You can write functions, execute a buffer, and perform your data manipulations in real time, patching your functions as you go.
Sooo... people don't like JS because 1) it's dynamically typed, and 2) they don't like JS?
>They don't care if first class functions are sexy.
It's not about being sexy (and believe me: first class functions aren't): it's about getting a very useful feature right, something many languages seem to have trouble with, despite the fact that Lisp (and ALGOL, IIRC) got it right in the 50s.
Sorry but this reply is just kind of vacuous given the link I posted. Eric Lippert gives a pretty detailed, neutral, blow by blow summary of the issues working with js at scale. And he quite specifically says that dynamic typing is not intrinsically the problem, just that dynamic typing tends to be correlated with other things that are a problem. He specifically mentions things like error handling. Did you even read the link?
I think your attitude is more that nothing is really bad with js relative to other languages, more so than actually trying to understand why it draws a lot of criticism, which is what you claimed and what I tried to link to.
I read it. It assumes mutable OOP. Yes, "those people" need a safe place to play so they don't hurt themselves :-)
(I'm ignoring the error handling thing, as I have not done enough server side JS to have a good feel for how the Node API handles things like I/O failures)
IDEs are starting to have better support for Javascript (or similar dynamic/functional languages). In the near future, the IDEs should effectively have type inference. Once you relegate (mutable) OOP to a tool of last resort, and embrace immutable value objects plus (higher order) functions as your primary methodology, you get the automated error checking and much less drivel to read through during maintenance.
OTOH, I suppose this means the dynamic/FP languages will remain a productivity lever for motivated "experts" only, sadly. At least until there is enough butt-kicking in the market that Java (and its ilk) will be displaced as was COBOL before it. COBOL was "safe" and fast, but we finally reached a tipping point were it was too painfully obvious that it simply wasted too much time writing and reading it.
Algol (1960s) had no garbage collection (that I know of), so any "closure-like" data captured by a function/procedure reference had to still be on the call stack.
Otherwise, you certainly had first class functions, just not always with any external state captured.
Now I'm curious. What would you say is wrong with python closures? Asking because they feel natural to me, and I haven't run into anything irritating about them. (As opposed to lambdas, which are really annoying and restricted in Python.)
It's not as bad as I thought, but Python doesn't actually have lexical scope, not really. But the LEGB rules mean that it should still work as you expect.
I recently had to decide on a GUI technology for a file manager I'm developing [1]. Electron is sexy, but unfortunately takes way too long to start for my purposes. I ended up with PyQt:
Pros:
+ Fast startup speed
+ I can use Python (and its vast ecosystem)
+ Qt has good ready-made components for eg. displaying a list of files (which is exactly what I need)
Cons:
- Compiling Qt (which I have to do for various reasons) takes time and is a pain
- Bundling and deploying a Qt-based app (times 3 - OS X, Windows, Linux) is a pain
- I have to deal with auto-updating myself (which I believe Electron supports out of the box) - times 3.
- I would prefer to lay out the UI in well-understood HTML/CSS. Qt's components and its CSS-equivalent behave in very weird ways sometimes.
I still sometimes wish I could use Electron but as OP says, we're supposed to pick the right tools.
I explain my reasoning for picking PyQt over Electron (and other alternatives) in a blog post [2].
A file manager would not be a good use-case for Electron. Especially if you don't intend to run it in the browser (which really would make no sense.)
For the very reason you outlined - startup times. The average use-cases of file managers are being opened and closed very often. Electron is rather aimed at long-running applications you don't usually restart, like Atom and VSCode.
Microsoft could've ported VS to other platforms, yet they chose Electron. I'm sure they spend quite a while analyzing the requirements and looking at alternatives as well before settling down.
The end result is very lightweight compared to VS and does almost everything users require. VS still starts a lot slower than VSCode for one.
I just start recently a file manager in Electron just for fun. I decided to use electron for a couple of reason.
My everyday work is in Java, JavaScript everyday, I wouldn't use Java in my free time for sure. But I do like JavaScript now with Babel/TypeScript. I did in the past worked with wxWidget and pyGTK but I found that building UI with React is more convenient and flexible.
UI performance are on par for this type of application, plus fetching file information from node is also pretty fast. But if I ever encounter performance issue, it's quite easy to redo the bottleneck in c/c++ with node. And pretty soon in the browser with webassembly.
Memory consumption is less than my Finder process (with all the opened helpers). But if I compare application like VS, VSCode and Intellij. Electron memory usage should be in between a C++ and Java apps.
The challenge would be to make it start/open really fast (now for the prototype it's like 1 second). But I guess it's possible to do the same thing as Nautilus/Windows File Manager/MacOS Finder and have a background process running.
Before the line between language and framework were more sharp. But I think with the evolution of the language and framework like electron, the line is getting a bit more blurry. Great apps could be written in electron as they can be written in a native framework. End users will be the real judges.
Maybe I'm an outlier, but I open/close my editors just as often as my file manager.
The main benefit of Electron is the community. Everybody knows HTML/CSS/JavaScript, so can write extensions / customisations. If I were Microsoft, that's how I would have justified Electron.
Visual Studio Code isn't exactly a port either -- it is kind of interesting that Microsoft now has three entirely separate projects out there with the 'Visual Studio' branding.
> For the love of God, learn something else. Learn how to use GTK or Qt. Maybe Xwt is more up your alley. How about GNOME’s Vala thing? Learn another programming language. Learn Python or C/C++ or C#.
All of this takes time. If you want to launch an app on multiple platforms, Electron is a very time efficient way to do this. Obviously native apps for every platform would be ideal but not everyone has the resources for that.
> Let me be clear about this: JavaScript sucks. It’s not the worst, but it’s also not by any means good. ES6 is a really great step forward and I’m thrilled about how much easier it’s going to be to write JavaScript, but it’s still JavaScript underneath the syntactic sugar.
Use something like Typescript or Flow then. The above is like saying C++ sucks because assembly is a bad language to code in.
This article, like many similar to it, makes the (imo flawed) assumption that a dev tool ought to be evaluated on only a few variables--e.g., code quality, performance, package size.
If writing software is about making users' lives easier, happier, or better, though, I think we ought to optimize for that and that alone.
I say let the market and communities of users decide which software they want to use. I use Nylas b/c I like the UX better than Ubuntu's Evolution, despite its flaws. I use Caret (electron markdown editor) because I wanted a cross-platform tool and I have > 4 gigs of ram. Hell, millions still use the Facebook Android app, despite the fact that it sucks down battery juice like your crazy uncle sucks down Miller Genuine Drafts before lecturing you on how terrible millennials are (happy Thanksgiving, btw).
Of course, it's important we know the trade-offs of the decisions we make, so we need critical pieces like this. But to be as prescriptive as this article is to miss the forest for the trees. Love it or not, JS is a point of entry for a hell of a lot more ppl than C++ is, so expanding its reach into new arenas is not only net-good, but I'd argue also inevitable.
That said, the article does skirt an issue I've thought about a little, and I'm interested to hear others' takes. If software collectively moves more towards higher-end systems, e.g., with SPAs and electron apps and all their cpu-intensive renders, are we further limiting a great web UX to those with the money to afford the latest laptops? We spend a lot of time thinking about accessibility standards for our products (A11Y, etc.), but when should we begin to think about accessibility from a socioeconomic perspective? Or are performant computers now so accessible that we needn't worry?
> If writing software is about making users' lives easier, happier, or better, though, I think we ought to optimize for that and that alone.
That's (imo) your flawed assumption. And no, just choosing electron won't make your users happier.
> Love it or not, JS is a point of entry for a hell of a lot more ppl than C++ is
C++ is not the only alternative. And considering the staggering amount of frameworks and tools one must learn to get started with JS other alternatives are actually easier. Unfortunately, not as cool.
> That said, the article does skirt an issue I've thought about a little, and I'm interested to hear others' takes.
Is this a joke? I had to google what skirt means: "attempt to ignore; avoid dealing with." That's the exact opposite of what the article does. Let me quote it for you:
About electron: "One of the slowest, least memory efficient [...]"
About terminal: "They’ve taken one of the most lightweight and essential tools on your computer and bloated it by orders of magnitude. "
About lossless-cut: "For the price of 200 extra MiB of disk space and an entire Chromium process in RAM and on your CPU [..]"
The conclusion that "people will require more money to buy more hardware to run bloated software" is not something only you thought about, it's only one step away from what the article says. And it's actually hilarious (read: infuriating) that you don't see the problem with that way of thinking. NASA put people on the moon with computers less powerful than a mobile phone.
The article criticizes people who write bloated software, but you argue it's fine, because users are happy. Then you go on wondering if it's a problem that users won't afford the latest laptops to run bloated software. WAT?
> just choosing electron won't make your users happier.
Ah thanks, I lost some clarity in a post-write edit. My point wasn't that choosing electron would do that, it was that we should look more at end-user satisfaction and less at often pedantic technical analyses of solutions.
Re: C++: You may be right, but we can't deny that popularity and cool factor has a significant effect on hard metrics--eg, more frameworks, more libs, more components == faster dev speed & iterations, which I think is a good thing. ex: Mac hasn't been "better for graphics" in over a decade, but the 'cool factor' has made it the de facto choice for designers, which has resulted in a bulk of the latest designer tools being Mac only (a problem which, coincidentally, electron & its ilk aim to solve).
Last: no, it wasn't a joke. I know what the article said. My point was that the point of socioeconomic accessibility was mentioned, as you note, in the last line, but for the most part, the supporting data were more asserted as intrinsically bad. If it was a key argument of the author's, I think the data would've been tied coherently to the conclusion instead of requiring a diligent reader such as yourself to farm & cobble them together into a patchwork argument.
So, if you'll forgive me for borrowing a little of your snark: next time you google a word, for instance, 'skirt', you should probably prefer the first definition ("go around, past the edge of") instead of the fourth definition, as you've done here.
To be clear, my thesis is, in tl;dr form: "Anything that makes reaching users in the environments they prefer easier is probably good, but the extent to which this trades off with accessibility is unclear to me."
> you should probably prefer the first definition ("go around, past the edge of") instead of the fourth definition, as you've done here.
That was the third definition. The first definition was "a woman's outer garment fastened around the waist and hanging down around the legs." /snark
> we should look more at end-user satisfaction and less at often pedantic technical analyses of solutions.
They aren't orthogonal. User satisfaction comes from a smooth experience. Regardless of how shiny something is, if it slows down the rest of the system (or is itself laggy) users will notice. I choose to run foobar instead of other music players because it's small and fast.
> are we further limiting a great web UX to those with the money to afford the latest laptops?
This is what infuriates me. People have been talking about how the "free lunch" is over [1] since 2009. About how CPUs have stopped getting faster, and how we should make the best out of the current hardware by learning to paralelize. Yet javascript is the most popular language and it's fundamentally single threaded. High quality software is not about having "a great web UX". VLC doesn't have it (great web UX). Blender doesn't have it. Intellij IDEA doesn't have it. And they're not only extremely complex and efficient softwares, they also have great UIs. Our computers are extremly powerful. The fact that someone would wonder if they're not enough to run pretty clipboard managers and fancy text editors is making me cringe.
Not yet but it will be once it's a little further along.
Rust -> Node -> Rust is pretty simple, just expose a c api and wrap it with node-ffi. Then I have the main thread piping messages over to the relevant windows straight into Elm ports.
Nice bit is you can pass callbacks into Rust that calls js via c function pointers. Saves a ton of time marshaling data and is more efficient.
This guy is doing his best to make sure we can't have nice things.
> We use [JS] because we have no choice (people who know more than just JavaScript know this). The object model is whack and the loose typing is whack and the DOM is super whack.
Moot point. I use React + TypeScript. Good types and barely ever work with the DOM. If you don't like TypeScript, your favorite programming language probably compiles to JS anyways.
> The reason people choose Electron is because they are too lazy to learn the right tools for the job. This is the worst quality a developer can have.
I agree that bundling a copy of chromium for a todo list app or clipboard manager seems wasteful. But that's an edge case, most people build actual applications. If I'm building a non trivial cross platform app, I'll be orders of magnitude faster on the web stack. I'm not lazy, I just don't want to waste months of my time learning arcane APIs because anything else wouldn't line up with the author's point of view about what the "right" tool is.
> For the price of 200 extra MiB of disk space and an entire Chromium process in RAM and on your CPU, you get a less capable GUI that saves you from having to type the -ss and -t flags yourself.
Cool. I remember when Handbrake first came out, and 'make video go on iPod' went from some long winder research into ffmpeg flags to clicking a button that says 'output for iPod' [1]. This sounds similarly timesaving.
I think the points raised are solid, but at this point it seems like Electron is the best worst solution for cross platform UI. Having worked with Qt I never wanna do that again. There's also a much more significant portion of developers who can work on Electron based apps. Part of picking the best tool for the job involves considering maintainability and ease of development after all.
It goes out of its way to not rely on the STL, so that std::string and QString are separate, non-convertible classes. QList and std::list<> are the same, same for QMap and so on and so forth. So data communication is already a pain.
We then have further issues with function invocation. Slots and sockets are simple with python, because functions are first-class in python. In C++, they are very much not, so slot-socket binding looks like:
connect(sender, SIGNAL (valueChanged(QString,QString)),
receiver, SLOT (updateValue(QString)) );
This article makes a good point, but what's the alternative? There is no good cross-platform GUI solution. Qt, GTK, JavaFx, wxWidgets, none of them are very good. Electron at least has the advantage of being fully cross-platform and not having to learn a whole new universe if you're already familiar with the web.
For cross-platform apps, Qt is the best I've used. But it does have its warts, and it is big, it will probably bloat your app by about as much as Electron does.
But yeah, there's no one clear winner, which means that Electron is not a uniquely bad choice. Sure, it might be a little heavyweight for a really small simple app, and if you're not aiming for something cross platform your native widget toolkit might be a better idea.
I look at Electron apps the same way I used to look at Adobe Air apps. Any League of Legends player knows how bad the launcher is - 80% the fault of Adobe Air.
Sure it was easier to build, but your users suffer for it. Electron apps are pretty terrible performance wise, and you can immediately tell it's an Electron app.
Electron apps have exactly the same performance as web apps, which is what its aimed at. Badly performing code can be written in any language; you'd be surprised at how much mediocre C++ code is running on your desktop. You're also running insane amounts of mediocre C# applications.
Comparing Electron to AIR makes no sense, they're radically different runtimes with radically different ecosystems. AIR stands alone while Electron reuses the web stack already used by millions of developers.
I find it rather elitist to dismiss Electron apps as "easier" to build or having users suffer. Thats completely false and grossly overlooks the context in which these apps were built. This is the kind of comment you'd expect from a beginner without much experience wanting everything to be in his favourite language.
VSCode certainly proves that Electron is capable of going the distance to making an app that feels like native. And it's a great example to read the source and learn how to do that for your own app. It's just a simple matter of programming. ;)
While I agree with you that the old League launcher was just trash, I am mildly impressed how long it has lasted and worked for Riot. As much fun as it is to make fun of Riot's spaghetti code, they did a decent job with the Air Client, far more than I would have expected before I knew it was Air.
I've been fighting with this for a while now. I think the only good reason to use something like Electron is if you need to get a cross-platform POC up and running quickly.
I am currently trying to make a GUI to compose and render Terraform assets in a similar manner to AWS CloudFormation's visual designer, and I've spent an eternity trying to devise the best way to do this (this is mainly driven out of boredom more than anything else...Terraform works just fine as is). As much as I don't want to use Javascript and the cancer that is it's dependency management, the web stack is proving to be the path of least resistance thus far. Although I still don't understand why you need to download half of the known internet to install gulp and babel locally.
I'm a GUI novice. Is there any cross-platform software that generates a true native UI on target platforms?
Well, that was a waste of time, the article is more a rant than anything else. I can understand that some piece of technology will not like everybody, but not spending any time giving proper alternatives. Not to mention that the header seems click bait since it's an opinion article, not an actual security risk.
The problem is there is no really alternative. Or what alternatives exist to write good looking, cross platform desktop applications with reasonable effort? I don't think there really is one. Another think is the huge amount of dependencies typical electron apps have (or in general node applications). 500-1000 packages is not unusual. Thats ridiculous for a simple desktop application
The argument that the only advantage of Electron is cross platform portability is not true. Electron tries to duplicate what is already a main stream approach for deploying backend services. The only reliable and sane way do have a stable backend is to explicitly control and isolate all dependencies of the backend services by using virtual environments, Docker or virtual machines. Most people no longer think that it is a good idea to run multiple services on the same server, globally 'pip|npm|bundle install' packages that one of these services needs and hope for the best.
Electron tries to do just that on the desktop. It packages all the dependencies that the application needs together with the application and installs them in an isolated app folder (not affecting any other app). It enables easy automatic updates of the whole environment without worrying that the update will break other apps or will not work because some user happens not to have some system library.
Sure, this is much earlier stage than with backend services. Ideally Electron could ensure that identical dependencies that are shared between different apps are not installed multiple times, the way Docker does it. Even without such sharing I think that benefits of the Electron approach justify additional MBs on disk.
We've been doing self-contained app distributions, with all third-party dependencies bundled, for well over a decade, especially on Windows. But Electron does make it quite easy to package an app that way.
If electron apps had a smarter way to manage chrome core as a dependency, the file size would be peanuts. Every apps is download on the same bundled core. Once this happens you won't have 100mb sizes. An intelligent installer could check core, if not installed download and install otherwise use what's on the system.
What if there was a centralized way of accessing HTML + CSS + JS applications? Instead of installing apps, you could just... "download" the necessary files to execute them? Perhaps even on demand from centralized.. "servers"?
I really don't want APIs to freely access the filesystem, other processes etc in my browser. And my applications to work offline.
I haven't seen many examples of people using Electron to make applications that really should be web apps instead, but more for packaging web apps with native enhancements. Often I'd prefer a "proper" native app, pushing even more features in the browser IHMO is not the answer.
> What if there was a centralized way of accessing HTML + CSS + JS applications
There is. The major OSs provide APIs to access the platform browser. The downside is you need a platform specific shim to set this up using native code. So, developers need to step outside of their JS worldview for a few days to avoid that 200mb app size penalty.
If you are building a platform agnostic app then I understand the value of Electron to avoid that work across each platform. But, it seems several of those Electron apps aren't even platform agnostic, so why not build the platform specific shim and be a better citizen on my hardware.
For YEARS I remember having to chase down the VBRUN{100|200|300}.dll runtimes for the Visual Basic runtimes.
Now that internet is everywhere, couldn't Electron:
1) Setup a common bootstrap mechanism so it's version agnostic
2) Check for the declared version of the app
3) If online (and allowed by system policy) check if there are security issues, or updates for the needed version
4) Advise user where to download the update, or (again, if allowed by policy) allow the user the proceed with the installation?
With some magic to allow a 'side-by-side' distribution of the Electron runtime, on good-ol' durable media, wouldn't this go far to minimize the size of the distributions of these Electron apps? You could have a system with one (or more if nessecary) versions of the runtime, and multiple apps using that runtime (with isolated profiles, of course ...)
>If electron apps had a smarter way to manage chrome core as a dependency, the file size would be peanuts. Every apps is download on the same bundled core. Once this happens you won't have 100mb sizes. An intelligent installer could check core, if not installed download and install otherwise use what's on the system.
Oooh, we could give this core a snazzy name like "Flash" or "Silverlight" or something too.
Stupid essay is stupid, but I'm glad it pointed me to lossless-cut because that tool is great! The author completely misses the point of Chromium in berating lossless-cut for being "a graphical UI for two ffmpeg flags". Yes, exactly, it's a GUI that lets you cut video to the precise frame you want to. That exactly solves a problem I've had for a long time; I've been using a horrible ffmpeg command line alias (along with preview in VLC) for a year now. He's a little right about "It doesn’t even use ffmpeg to decode the video preview in the app"; that would be useful for supporting weird formats that Chromium doesn't. But for common formats lossless-cut is great. It's at https://github.com/mifi/lossless-cut
Getting started with Qt is pretty easy I'd say, at least when you use Python and not C++:
import sys
from PyQt4 import QtGui
def window():
app = QtGui.QApplication(sys.argv)
w = QtGui.QWidget()
b = QtGui.QLabel(w)
b.setText("Hello World!")
w.setGeometry(100,100,200,50)
b.move(50,20)
w.setWindowTitle(“PyQt”)
w.show()
sys.exit(app.exec_())
if __name__ == '__main__':
window()
In general I think Qt is one of the best-documented UI toolkits out there, and while it surely is complex it offers a lot of modern features and is able to produce pretty great UIs.
JavaFX is fairly decent, and I agree that it's more pleasant than Swing or AWT. It's a fairly good choice for places where you can mandate or ensure that Java will be present on the client (e.g. internal line-of-business apps), but also in places where you don't need to have some ancient version to support some ancient application instead -- which cuts down on the pool a bit.
Unfortunately, most users know Java from years ago and never understood the difference between an applet or desktop application, and in the minds of some users it's still falsely stereotyped as slow or insecure.
In most shops I know, Java is being extensively used on the back-end, but almost no custom Java apps with GUIs. Most shops (and people) who could do Java on the frontend have gone to learn Mono or WinForms or WPF instead, which gives you results that feel nicer to most users.
Purely out of interest, because I might have used one without even realising it, but could you link some desktop applications written in Java that haven't been sluggish as hell or a bit broken feeling?
TTK. It's got bindings in pretty much every language (because it's TK), but unlike plain-old TK, it doesn't look like absolute garbage, and instead takes on a vaguely native appearance on each platform.
I ran into this when teaching myself Swift last year. Learning a new language is easy. Learning the ecosystem, architecture, and some initial best practices is a sisyphean task.
I have been wondering...does Slack freeze for like a couple of minutes a couple of days a day for someone else?
I am on win10, on pretty hefty machines. No idea if it's because Electron or something else, but it's really annoying. I could not find any trace of issues in the event viewer etc.
Electron, and to a great extent the cross platform fetish, is a perversion of DRY. They don't want to write the same code for two platforms. But its usually not the same code. Its the same logic implemented on two different platforms. Developers are so into code sharing, write once run everywhere, that they don't stop and ask if they should. In every case you are paying a price for abstraction, like running Electron or using a WebGL canvas instead of a native graphics API. The article highlights cases where they price was paid, but the app was still platform specific.
Well, it's the same logic - so almost by definition it should be platform-independent. People are too lazy to introduce proper abstraction between what the application does and what it shows on screen, and suddenly porting is hell.
Either way, Electron sucks because it ships a whole goddamn browser to give you just portability; you have to still pile on a ton of JS and CSS hacks to get a decent-looking SPA UI out of it, which you'd get for free with any proper GUI runtime. All that waste because people want to write JavaScript (which I understand - I have my favourite language I'd love to write more too) and this was the most brute-force way to allow it.
Embed a system webview if you must, don't ship the goddamn browser!
Cross platform is a perfectly fine goal. Why should a developer care need to write `open()` on one system and `OpenFile()` on another, when all they really mean is "open this file" with the exact same semantics? That said, I think electron is overkill from a technical standpoint, and ultimately is probably too harsh on hardware, but I've given up caring about that in the short term, because there are bigger problems with how our stupid computers are implemented.
This makes no sense and completely disregards context.
There are perfectly valid use cases for Electron, and they have absolutely nothing to do with what you said. There are also insane amounts of cross-platform native code written on platform abstractions layers.
> Developers are so into code sharing, write once run everywhere, that they don't stop and ask if they should.
Isn't that the very purpose of Qt or GTK which the article is promoting instead of Electron?
The fact that electron is easy enough to write trivial apps while at the same time powerful enough to give us VS Code is in my book SPLENDID.
If the trival app is too big for a trival app - who cares. The fact is there is now a serious contender in the cross-platform space that so far has been mainly occupied by Java. Java cross-platform is neither easy nor lightweight. And from what I have seen so far getting started with Electron looks a lot easier.
I can't help but feel as if the author can't make the distinction between a platform and the software written for it. People have been misusing platforms ever since they existed. Its not because someone used Electron to build a console that Electron is bad in and of itself, it just means someone used the wrong tool for that specific job - or maybe that fitted all their requirements in which cause the author is just dismissing the work with no clue about its context.
I also can't help but feel as if the author is a beginner developer lacking a huge amount of context and experience. Saying "Electron enables lazy developers to write garbage" displays a huge misconception about software development in the very first place - garbage will be written no matter the language or platform.
Alls the article did was remind me that those who can, do, and those who can't, blog.
I've seen native app with more ugly UIs and being laggy, etc... For many apps Electron is fine and will perform as well, or even better than native apps (just because, developers you know).
Honestly I think this is a symptom of the lack of really good GUI toolkits that let you define the UI in an easy-to-use and powerful language. There's Qt & QML, but that's about it, and to be honest QML is still pretty immature (try doing a custom control with text, or any kind of text editor in QML).
I really hope Rust or Go get great native GUI toolkits soon with nice declarative layout languages, but until that happens it is hard to get too angry at people using the wrong tool for the job because the right tools just aren't that great.
I have a windows store js/html app which I plan to re-release on electron. It features a rich text editor and a few other features. I want to release on Linux and mac os. Should I go away and learn qt/gtk/wx? Restart the whole project in Java?
The idea that I might choose electron for ease/speed of development rather than use a leaner platform is being shit all over as a "business" decision. Not a "I don't have enough free time to learn two new languages and ui systems code three new apps" decision.
I dislike JS just as much as the next guy but the only real contender on the list is Qt. Which you need to license for commercial development. Furthermore, even though I like to think that I'm ok in C++, I would really think twice before using it on my next project these days.
The JS performance issues should go away for the most part when wasm is standard. Also a lot of people write some compile to JS language, not JS, so I think that most of the points of this blog will be rendered moot in the near future.
If you're doing commercial development, why is a license (and the attendant support) a big deal? Its cost in relation to that of your developers is neglegable.
Or is the cost of the license really that prohibitive for a well supported and performant piece of software?
[EDIT]: I found the pricing after a bit of creative googling: Startups is about $1,000 a year, non-startups are about $3,500 a year. Even without the discount, that's roughly equivalent to a month of one developer's time. IMO, not a terrible deal, for something you can freely license and use for cross platform development.
Qt is LGPL, you don't need to share your application code; you only need to share Qt's code (which only matters if you modify Qt).
(not legal advice; I'm not completely sure about this)
> The LGPL allows you to keep the source code of your application private as long as it is “work that uses” the library. Dynamic linking is usually recommended here.
We need to stop reading such posts. "Everything sucks because I say so". Technology is really fair. At the end we WILL use what matters the most and has the overall best tradeoffs.
I don't like it when people use the expression "best tool for the job". Like you used every other available tool out there and you found the best one...no you haven't.
For me the title evokes "Considered harmful essays considered harmful", which suggests that perhaps "benefits and disadvantages of Electron" would have been a better essay.
I'm a bit late to the party, but there are active React Native ports for both OSX and Windows.
Using them could be a good solution for targeting OSX and Windows and reusing logic from your web React app without having to deal with the overhead of Electron.
Web browsers should have integrated functionality to run some websites as standalone apps (anyone remember Prism?). That way we wouldn't need to install yet another copy of browser with each app.
While I agree with his general idea that Electron is usually not the best tool for the job, I think he's overestimating JS as the reason that people choose Electron. It's not because of JS, it's because of HTML and CSS, which aren't that bad comparing to other tools we have (especially since Flexbox). I think most people would love to write desktop apps using HTML and CSS, while using anything other than JS to do the logic. We're just... not there yet.
SirCmpwn, you'll understand more about trade-offs when you finally have commercial success with one of your projects.
It's too easy to lambast Electron and "lazy developers" when you've never had business concerns trump technical ones because none of your work ever tried to run that gauntlet.
I had to chuckle to myself when I saw that your GitHub bio is:
> I make unoriginal projects with better code than
> the thing they rip off. I'm available for hire.
Downvoted. It's generally considered rude to expend more effort being snarky than answering a simple question.
To the parent: Electron is a framework for building cross-platform desktop apps with HTML CSS and JavaScript in an embedded chrome browsers/node.js environment.
If all I can add to a discussion is "Just google it", I just won't respond. For better or for worse, people aren't going to respond by saying 'By golly, you're right! I'm so lazy, but from now on, I will google stuff first instead of asking questions." They're just going to say basically "What an asshole, fuck this guy.
Maybe he wants an answer that is curated and summarized by a human, not a litany of links where you don't know what to focus on. For example, when I asked what dependency injection is, some kind stranger responded "It's a million dollar term for a 5 cent concept. Pass objects as arguments to functions instead of instantiating them inside." Of course, this is a limited definition, but it was put into layman's terms and it answered my question. From that answer, I was able to really learn what it was instead of being stuck on phase 1 of understanding.
When you're online, it's much easier to come off as a dick than it is in person so what I try to do is imagine someone coming up to me earnestly and genuinely asking the same question and respond thusly. Accordingly, when I know I'm asking a simple question, I add self-deprecation to the beginning. Example: "I have the technical and programming acumen of a bag of rocks, so excuse my elementary question, but..."
But then the essay turns into a rant. It's 2016, people, the ship has sailed on pretending JS isn't a real programming language. Phrasing the argument the way he does just betrays his smug elitism.
The fact is, for many types of applications, Electron is a really good fit: for example, shipping a single-page webapp as a desktop app, a need that surfaces often in today's world, despite his derision of this concept.
An Electron-wrapped SPA is safer than going to the same website in a multi-tabbed browser and co-mingling your disparate cookies in the same jar, not to mention more convenient for the users, because they can treat it like any other desktop application -- with hardware access, and subject to the OS' native task management.
For other apps, Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages. This is a huge boon for re-using knowledge, and perhaps does lead to some amateurish projects. Similar criticisms were leveled towards Visual Basic, where drag-and-drop composing and a good IDE enabled people to quickly crank out a GUI app from an idea.