Live data from Hacker News

Electron is flash for the desktop (2016)

josephg.com

181–190 of 1001 posts

Re: Electron is flash for the desktop (2016)

#181

I fully agree with the author, only I'd call Electron the PHP for the desktop (it does help people get started quickly, at a cost). There are working solutions for cross-platform native UI development and high-performance, slim code: http://wiki.lazarus.freepascal.org/Multiplatform_Programming... The problem is: most people don't bother learning new languages unless it's very easy (well, Pascal is!). I hope Go will h…

What does PHP have to do with this?

And Go already has bindings for QT which is a cross-platform UI framework.

This has nothing to do with people not wanting to learn new languages, it's just the time it takes to build an app. For you to build a QT hello world app takes probably 20 minutes worth of downloading, setup, and coding. To do the same you download electron, create an index.html with hello world and drag and file into electron, bam a hello world app.

The problem is desktop development is overly complex. React and modern Javascript make creating desktop apps using HTML/CSS with some combination of Javascript easy.

What we need to do is find a way to create a very slim browser that contains just an HTML/CSS to 2d context and a Javascript engine. Call it Electron slim and release that.

Re: Electron is flash for the desktop (2016)

#182
People complaining about electron are the same type than the ones that used to say :

- why are people writing this stuff in C. It's so slow and you don't have as much control on memory. Write it in Assembly.

- why are people writing this stuff in Java. It's so slow and you don't have as much control on memory. Write it in C.

- why are people writing this stuff in Python. It's so slow and you don't have as much control on memory. Write it in Java.

Eventually people want to solve a problem with the best ratio cost/quality for them, not "doing it the proper way".

So unless you provide a better solution for them to do that, or pay big money to create such solution, they will find the ugly-hackish-half-baked-working-for-them solution that let them do this.

We had PHP. Now we have JS.

I hate it. You hate it. We all hate it.

But I created portable GUI apps with an installer before in my favorite language and others and it was a pain. All of it. The UI, the event model, the API, the portability edge cases, the new stuff to learn, the packaging, the dependencies...

It sucked.

So get over it or provide a solution, but stop complaining.

And before you start providing an EXISTING solution, remember people tried it and they didn't like it as much as electron. And since electron is so bad, that should tell you something.

So the market is saying you are wrong. You can ignore it from your better tech tower... Try to boycott electron apps all you want. But we know how it has played for betamax, lisp and the ogg format.

P.S: oh, and if electron is flash, remember that flash won the web for 15 years while it sucked. And you know why ? Because it allowed people to do stuff they wanted easily, like videos and animations. And it's not because we couldn't do it any other way, we could. Yet we had to wait almost 2 decades to see it dies, at the price of battery, stability, security and everything else. Feature trumps everything. People. Don't. Care. We only manage to kill it because we finally replaced it with systems that could compete on easiness and features. So you know what to do.

Re: Electron is flash for the desktop (2016)

#183
post #113

Earlier quoted context omitted.

> They fail to integrate with the host platform Just as a counter-point, because native app fans often make this point as though it is universally recognized to be a good thing. I don't want apps to integrate with the host platform. The host platform is not the thing I care about. I use several host platforms in different contexts (I have work and home computers and a smartphone, they all run different OSes) and I wo…

I accept that not everybody will feel the same way – I do care about my local platform. I want to hit 'space' when I have an item selected and see quick preview. I want my documents indexed in Spotlight, I want to drag-and-drop files between applications, and I want all the rest of the UI niceties I am used to.

And on Windows, I want pressing Alt to highlight the first menu, and the arrow keys to move between and around menus.

Re: Electron is flash for the desktop (2016)

#184
post #61

Telegram Desktop is very good example of modern desktop client done in the most efficient way. C++ and qt, nothing else. Works like a charm an all major operating systems. Easy to install, use and update. Great stuff.

I'll give them credit where it's due, it's a great app. That being said, if you've read the source, it's not exactly the most approachable thing in the world.

Also, if you're not making your code LGPL/GPL, be prepared to pay $300/person/mo for Qt Creator (seriously - https://www.qt.io/buy-product/)

Re: Electron is flash for the desktop (2016)

#186

Here's the thing. You know what the alternative to all of these Electron apps coming out is? If your answer is "A native Cocoa/WPF app", you are on another planet, the answer is, "It wouldn't exist at all". Nobody in the last 5-10 years cared about writing Desktop apps before Electron came along, there's basically zero money in it, and it's massively expensive, both in terms of actual dev time per feature (easily 10x…

How many electron apps can run on the same machine? For many of them it can be beneficial to just be a website.

Wouldn't it make sense to run a caching proxy on desktop and use a browser that is already there? That way you could still use some functionality not available to plain websites, like access to computer. But use system browser for rendering. Your proxy would also cache your website so it would run faster than normal website.

I understand, that this way you have to support more browsers, but you probably already have a web version of your app.

The problem could be with users seeing localhost address. How to overcome this issue? Virtual interface on which DNS server could run?

Maybe running from a file:// could be a solution for some apps?

Re: Electron is flash for the desktop (2016)

#187

Here's the thing. You know what the alternative to all of these Electron apps coming out is? If your answer is "A native Cocoa/WPF app", you are on another planet, the answer is, "It wouldn't exist at all". Nobody in the last 5-10 years cared about writing Desktop apps before Electron came along, there's basically zero money in it, and it's massively expensive, both in terms of actual dev time per feature (easily 10x…

The other thing I find ionic about this whole article is that it's perfectly easy to only use Slack within Chrome as a normal web app. And the UI is almost exactly the same because it's nearly all the same code. So if the Electron bloat is such as issue for you, just hit Slack in the web directly.

I do this. Go to Slack and click 'add to desktop' and Open as Window and you're good to go. Same for Whatsapp Web etc...

Re: Electron is flash for the desktop (2016)

#189

Here's the thing. You know what the alternative to all of these Electron apps coming out is? If your answer is "A native Cocoa/WPF app", you are on another planet, the answer is, "It wouldn't exist at all". Nobody in the last 5-10 years cared about writing Desktop apps before Electron came along, there's basically zero money in it, and it's massively expensive, both in terms of actual dev time per feature (easily 10x…

Wow, that's bullsh*t. Sorry but what you said was factually incorrect. What Electron did is it enabled all those web devs (even front end guys) to write "desktop" apps. And trade offs are certainly visible. I am boycotting Electron. I have zero Electron apps installed, and recommend strongly against it. I hate that web dev mindset that has been pushed into desktop userland. It just doesn't work that way. Write native…

Can you expand on your last sentence? How is React + browser rendering any different then QT rendering? How is HTML/CSS any different from QT layout xml? How is QT sockets/threading any different from NodeJS sockets/threading?

They are very very close to each-other. Obviously they are not exactly the same, and I used QT in this example. But they are not wrong, or completely different.

Re: Electron is flash for the desktop (2016)

#190

Earlier quoted context omitted.

The cost argument is indeed a moot point - look at all of the major software companies, and you'll see that actual development is nowhere near their primary expense. They can afford to implement their own programming languages and OSes (and some do), but apparently it's too expensive or too difficult to make native apps for the respective platforms? This goes for mobile too.

It's moot if you're an established company with deep pockets moving slowly. If you're starting from scratch with limited funds, it is definitely not a moot point. Would Slack have been as wildly successful if they had to implement native apps on all 3 platforms + iOS + Android + etc? I'd have a hard time believing so.

[deleted]
Post reply on HN