Live data from Hacker News

Electron considered harmful

drewdevault.com

171–180 of 256 posts

Re: Electron considered harmful

#171

Earlier quoted context omitted.

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.

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.

Re: Electron considered harmful

#172
post #47
post #8

As some of who's had to support Qt, wxWidgets and other crazy x-platform UIs I find electron refreshing. Heck, I've got Rust talking to node.js in it. Elm for the front-end and Rust for the processing, it's a surprisingly pleasant development experience.

Hey, is this open source? Sounds very cool. If not, can you point me towards any open source apps that are using a similar approach?

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.

Re: Electron considered harmful

#173
post #88

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 b…

This is both true, but also makes me weep for the state of software development. (Specifically, performance and security)

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.

Re: Electron considered harmful

#174

Earlier quoted context omitted.

Yep, all the native toolkits failed, that's worthy of ranting about, but that is not what OP was doing.

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?)).

Re: Electron considered harmful

#175
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.

Re: Electron considered harmful

#177
post #176

Earlier quoted context omitted.

Electron is a cross-platform desktop framework based on a web stack. http://electron.atom.io/

How does it compare to https://github.com/electrode-io

Electrode seems to be for "normal" web sites/web apps, Electron is for packaging HTML+JS as desktop apps.

Re: Electron considered harmful

#178
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

Re: Electron considered harmful

#179

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 d…

And those who really can't post snarky comments on HN.

Re: Electron considered harmful

#180
post #149

Earlier quoted context omitted.

Cute. Smalltalk and LISP are terrible too huh?

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 c…

What Lisp are you developing with? Mature "industrial strength" Lisp compilers do perform type checks prior to run time.

Dynamic typing isn't optimization; dynamic typing without any static analysis is the utter lack of optimization.

Post reply on HN