Live data from Hacker News

Electron is flash for the desktop (2016)

josephg.com

691–700 of 1001 posts

Re: Electron is flash for the desktop (2016)

#691

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…

>Nobody in the last 5-10 years cared about writing Desktop apps before Electron came along

Maybe nobody in the Web bubble.

Re: Electron is flash for the desktop (2016)

#692

Earlier quoted context omitted.

Actually, I've been shipping desktop apps in Objective-C for roughly a quarter of a century. Gets me the high-level, Smalltalk-ish productivity when I want it (most of the time) and the low-level C efficiency when I need it (sometimes). Having my cake and eating it, that's me :-)

But can you make a website with the same knowledge ? Can you make it portable to other OS ? Can you reuse 20 years of knowledge, resources and libs ? Can you hire tomorrow 10 experts to help you on it ? Quality of the tech is NOT the drive for success here. You are missing the point.

> But can you make a website with the same knowledge ?

One of my first commercial projects was a web-content management system written in Objective-C. Customers included Siemens and the German Bundestag.

Another couple of projects were written in WebObjects. If I wanted to, I could use Cappuccino, but I am not a big fan of web//client apps, so I don't.

> Can you make it portable to other OS ?

This product ran on: Solaris, AIX, NeXTStep, Linux, OS X. I think we also had a Windows port.

> Can you reuse 20 years of knowledge, resources and libs ?

In the sense you meant it: yes. Except it's more like 30 years. However, programming skills are (or should be) transportable. With virtually no previous experience, I became lead/architect on a Java project, which succeeded beyond anyone's imagination.

> Can you hire tomorrow 10 experts to help you on it ?

Is this a serious question?

Re: Electron is flash for the desktop (2016)

#693

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…

Bologna: nothing truly performant uses Javascript because Javascript can't get at hardware accelerators in their full glory. Apple's macOS and iOS are themselves desktop apps, in the latter case for a pocketable desktop, and they resolutely don't rely on the very constrained subset of 50 years of engineering called Javascript.

Have you seen how many messages you can pump through and transform on a node process? Yes, there is an abstraction and that's a cost, but v8 perfomance is "good enough" for almost everything.

Maybe not a coin miner or a graphics engine; but cpu is never really the constraint for applications such as those inside electron containers. Where you see them chewing 100% of a core, those are bugs.

Also, while th e language has flaws modern; JS vms are pretty bleeding edge....

Re: Electron is flash for the desktop (2016)

#694

Earlier quoted context omitted.

Software dev is about tradeoffs, and the argument against Electron is that the tradeoff in resource usage is bananas for nebulous claims about "it looks better" and "I wrote my app faster". Every time this comes up on HN, someone says, "wow, Electron is Dracula to batteries, and all I'm doing is sending text to people/playing an MP3/blinking a cursor". Managing tradeoffs is a fundamental part of development strategy.…

This is the problem here. Your post illustrate it perfectly. You just ignore what the market is saying because "you are right". You are completely missing the point.

Maybe you are ignoring the market?

I work on Wunderlist. One of our key differentiators, the thing customers love, love, love, is native apps on the major platforms (iOS, macOS, Android, Windows), in addition to an outstanding Web app.

We quickly got several million customers, were acquired by Microsoft for "an undisclosed amount".

http://www.theverge.com/2015/6/2/8707883/microsoft-wunderlis...

Re: Electron is flash for the desktop (2016)

#695

Earlier quoted context omitted.

While true, Google Docs' collaboration capabilities are fantastic enough that it's worth using, though. We use it all the time to work, anything from tiny scratchpads to big documents. To do the same in Microsoft Office, you need to dick around with OneDrive and/or SharePoint. The last decade or so, I've only touched Office when someone sends me some .xls or .ppt file and I'm being lazy and just want to view it.

You can use an old school network drive to share documents in an enterprise, irrelevant of their nature. Easy and simple.

I am referring to Google's realtime collaboration features. Given a URL, you can enter the document and see it being modified in real time, as well as edit, annotate and comment in real time.

It's 2017, this is how we work now. My colleagues (literally) across the world are not going to connect to some shared NFS drive or whatever via VPN to store documents.

Re: Electron is flash for the desktop (2016)

#696
post #649
post #477

Earlier quoted context omitted.

Java also has JavaFX, which comes with an embedded Webkit browser. I can create my UI with React, or any other HTML/CSS/JS library, and make it interact with code written in Java, Scala, Groovy, Clojure, Kotlin, Ceylon, Frege, etc. very easily. I think this provides all the benefits of Electron, but is even more flexible and powerful.

> code written in Java, Scala, Groovy, Clojure, Kotlin, Ceylon, Frege, etc Your list of 7 JVM languages (both here and in your earlier comment on this submission) seems to be from most widely used to least. Yet in your HN comment from 2 days ago at https://news.ycombinator.com/item?id=14068664 you ordered that list differently, i.e. "Java, Scala, Clojure, Groovy, Kotlin, Ceylon, Frege, etc". Have you changed your min…

Not really. Actually, however, there is a recent survey that shows that Groovy is the second most popular language on the JVM, behind Java. Myself, I use Scala, and would like to learn Frege.

Re: Electron is flash for the desktop (2016)

#697

Earlier quoted context omitted.

We use Java because Python proved to be too slow.

And because the IDE support (refactoring etc etc), compile time error checking and ease of use more than compensates for Java being a little bit verbose.

And because packaging everything in a jar is easier than pulling 1e3 dependencies for every deployment. Not to mention drpendencies that also require a C/C++ compiler boost or other native libraries.

Re: Electron is flash for the desktop (2016)

#698

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…

Sure, but that's not what the argument is. The argument is that electron apps are way more resource hungry than native ones.

So what? We have those resources.

Does the weight of these just irritate you because of how wasteful it is (it irritates me for this reason alone) or does it actually have an impact on you?

People said the same things about gtk or qt when we had motif right? Apps are going to keep getting bigger, our machines get bigger too. I'm not sure what he problem is.

Edit: fat fingers

Re: Electron is flash for the desktop (2016)

#700
post #598

Earlier quoted context omitted.

"it's the worst decision you can make for your user" - Is it? Because there are a lot of Slack users who don't care at all about your tradeoffs. Most of them don't even notice. We're just the unfortunate ones who do notice.

Whether they notice or not is orthogonal to whether it's a bad decision for them or not though.

"bad decision" !== "worst decision"
Post reply on HN