Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Electron is flash for the desktop (2016)

josephg.com

Post reply on HN
Print view View original

481–490 of 1001 posts

Re: Electron is flash for the desktop (2016)

#481

Post by lobster_johnson »

nulagrithom wrote: post #475
atombender wrote: post #298

Earlier quoted context omitted.

I doubt you don't care. These are examples "integration with the host platform": * Text selection * Caret behaviour (e.g. Option-arrows on macOS) * Clipboard * Spell check * Open/save dialogs * File system access * Drag/drop * Window management * Accessibility (screen reader support etc.) * Standard right click menus * Indexing (e.g. Spotlight on macOS) * etc. You may be thinking to native UI idioms, which even Apple…

I'm a little confused by your list... In what way are text selection, caret behavior, clipboard, spell check, open/save dialogs, drag/drop, accessibility, and right click menus not available in the browser?

They are.

Re: Electron is flash for the desktop (2016)

#482

Post by Merad »

alexeiz wrote: post #402
Merad wrote: post #344

Earlier quoted context omitted.

> much slimmer Yeah... I opened a 500KB log file in vim and Notepad++ and they are using 5 MB and 7 MB of RAM, respectively. They both also manage to use no measurable amount of CPU (even to blink the cursor!) unless you interact with the window.

> no measurable amount of CPU (even to blink the cursor!) Is it really possible? What kind of alien technology is it?

I should say "measurable in task manager" - which reports in increments of 0.1%.

Realistically I would imagine that a native Win32 app (Notepad++) that's totally idle except for message loop and cursor blink requires less than a microsecond of CPU time per wall clock second.

Re: Electron is flash for the desktop (2016)

#483

Post by kungtotte »

pluma wrote: post #468
Veen wrote: post #116

Earlier quoted context omitted.

What you call "trade-offs" appears to me to be developers externalizing their costs onto users. There are costs to developing desktop applications and developers don't want to pay them, so they make users pay for them in wasted hardware dollars, bandwidth, RAM, battery life, and poor integration.

I've switched from Sublime Text 3 (native) to VSCode (Electron) and I couldn't be happier. If I didn't know it's electron based I wouldn't have been able to tell as a user. YMMV so don't generalise.

When did you switch? Atom was damned near unusable around 1.0, and VSCode was only a little better.

The difference to now is night and day.

Re: Electron is flash for the desktop (2016)

#484

Post by douche »

bluejekyll wrote: post #355
Tenhundfeld wrote: post #228

Earlier quoted context omitted.

I don't disagree, but I'm hopeful that Electron will get better. When you choose an open source platform with a diverse group of major companies using it, part of what you are betting on is that the platform will a) survive for a reasonable amount of time and b) gradually improve. GitHub, Slack, Spotify, Microsoft, etc., are all using Electron. As their developers gain experience with the platform and as they experie…

On top of that, webassembly could see some improvements across the board.

The future, where we write in native languages, that are compiled to Javascript, run in a webbrowser VM, and power desktop applications. Jesus wept.

Re: Electron is flash for the desktop (2016)

#485

Post by Touche »

coldtea wrote: post #445
sametmax wrote: post #159

Earlier quoted context omitted.

Computing for ever. We use C to avoid writing assembly. Use Java to avoid writing C. Use Python to avoid writing Java. The world is asking for more and more software, and the resources to provide it are not following so people are taking shortcuts. Want something better ? Someone has to pay for it.

> Computing for ever. We use C to avoid writing assembly. Use Java to avoid writing C. Use Python to avoid writing Java. Yeah, but until Electron and they like, we seldom shipped desktop apps in anything than C, C++, Delphi etc even after all those decades. Which are all as close to the metal as can be. And in fact C/C++ can be as fast, or even faster than hand-rolled assembly most of the time (with few exception), s…

C# has been the default way to write Windows apps since the early 2000s. It is no more "closer to the metal" than JavaScript.

Re: Electron is flash for the desktop (2016)

#486

Post by kakarot »

anaisbetts wrote: post #74

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…

What? Qt is very popular and I use several Qt apps. Same for GTK. And there is MUCH more desktop software out there than functional web apps. I don't know what kind of Windows 10 fantasy land you live in but there has long been an answer to desktop apps.

What Electron has done is allow people with a particular skillset to apply it to a domain where it is both unnecessary and wasteful. These "developers" would be better off generalizing their understanding of software and UI design to the point where the tools used are irrelevant

Re: Electron is flash for the desktop (2016)

#487

Post by devmunchies »

BuuQu9hu wrote: post #174
anaisbetts wrote: post #74

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…

Here's the thing. You know what the alternative to all of the JS that's been written? If your answer is "Keep writing more JS," then you are on another planet. The answer is, "We have fucked ourselves as an ecosystem by permitting a monoculture to flourish, especially one which prides itself on worship of bad languages, bloated runtimes, convoluted abstractions, and general fuckery." Nobody in the last ~20 years has…

> Nobody in the last ~20 years has cared about writing Web apps before JS came along. There's basically zero money in it

Zero money in web apps? You mean like Google, Facebook, Amazon, Twitch, Netflix, and YouTube?

There's way more money is web apps than desktop apps. hands down. I'm not talking about mobile because this is a convo about electron.

Re: Electron is flash for the desktop (2016)

#488

Post by laythea »

matthewmacleod wrote: post #283
_jal wrote: post #263

Earlier quoted context omitted.

I think people are talking past each other. Yes. Electron enables some new stuff. New stuff that wouldn't exist otherwise. Yes. Electron is a bucket of bloat that saddles what should be small, simple apps with enormous amounts of crap that has nothing to do with the app's functionality. Both of these can be (and are) true.

I think that's the real take-away here. There are upsides and downsides; I am pleased that it is easier to release desktop applications, but sad that the performance of them is so much worse . I wonder if one of the issues is that so many developers have now worked almost exclusively in the 'web' sphere, and aren't aware that native development maybe isn't as difficult as they think.

On the plus side, this is an ideal situation to take advantage of - by creating native and fast applications, it becomes easier (compared to before when everyone was doing it "the hard way") to distinguish your product in a bloated market.

Re: Electron is flash for the desktop (2016)

#489

Post by cr0sh »

Philipp__ wrote: post #260
dubcanada wrote: post #189

Earlier quoted context omitted.

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.

Haven't wrote a lot of QT, but Cocoa/DELFI felt totally different than writing Electron app GUI. Writing Electron app felt like sketching, at least to me. You place one line of code with tags and boom there's a button. Now QT takes place somewhere in between, and it still provides nice native multiplatform environment that could be appealing to web developers.

> Writing Electron app felt like sketching, at least to me. You place one line of code with tags and boom there's a button.

Runtime issues aside (bloat, cpu, etc), why is this a bad thing?

I like that I can write a single line of code and "bam!" get a button (or any number of things) to appear. Why would or should I want things to be more difficult for me to develop a piece of software?

Sure, I could do things in some other language - I mean, I know a ton of others. But implementing the same functionality can be a much larger pain in those other languages (and honestly, for app gui development, I haven't found anything that beats the drag-n-drop editor of VB3/4/5/6 - there was something close to it in Visual Studio for C++, but it still required some manual "hook up" with the code for callbacks and event handling and such).

I mean - if I really wanted to do things "right" - why don't I just whip out my text editor and write assembly for whatever CPU I'm targeting? I can full control over everything, then! Best performance! Those guys and their compilers, I tell ya, they don't know what they're missing!

(heh - sometimes they don't - there's a whole generation or more out there who've never coded for a CPU by looking at a datasheet and finding the byte values needed to represent op-codes to hand-assemble a piece of code - sometimes I do miss hacking on the Apple IIe and monitor - CALL -151 ftw)

Anyhow - as someone who's been coding for longer than I really care to say (of course, I kinda gave my age away above!) - I don't want to return to those days; I kinda like living in the future of computing I could only dream about as a kid.

Re: Electron is flash for the desktop (2016)

#490

Post by douche »

coldtea wrote: post #445
sametmax wrote: post #159

Earlier quoted context omitted.

Computing for ever. We use C to avoid writing assembly. Use Java to avoid writing C. Use Python to avoid writing Java. The world is asking for more and more software, and the resources to provide it are not following so people are taking shortcuts. Want something better ? Someone has to pay for it.

> Computing for ever. We use C to avoid writing assembly. Use Java to avoid writing C. Use Python to avoid writing Java. Yeah, but until Electron and they like, we seldom shipped desktop apps in anything than C, C++, Delphi etc even after all those decades. Which are all as close to the metal as can be. And in fact C/C++ can be as fast, or even faster than hand-rolled assembly most of the time (with few exception), s…

There's probably, line for line, more VB6 desktop apps in existence than any other language. And that's not just because of how verbose VB is...
Post reply on HN