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

621–630 of 1001 posts

Re: Electron is flash for the desktop (2016)

#621

Post by frik »

smitherfield wrote: post #448
frik wrote: post #386

Earlier quoted context omitted.

Steam always used a HTML renderer, even in its 2006 first incarnation. Nowadays it uses the same CEF (chrome library) as electron uses. So Steam was one of the first "Electron" apps. A very first one was Windows Explorer as of Shell update that came with Internet Explorer for Windows 95 (included by default in Win98). All the sidebars of Explorer were HTML based.

>A very first one was Windows Explorer as of Shell update that came with Internet Explorer for Windows 95 (included by default in Win98). All the sidebars of Explorer were HTML based. That's a stretch; X/SG/HTML user interface APIs are not the same as a whole browser with Javascript VM, full networking and security stack, full-featured/standards-compliant (X)HTML/CSS rendering engine plus support for legacy features,…

Win95 with shell update up to Windows Me and 2000 had the full trident engine (same as IE 3-5.5) in the Shell (Active Desktop, Explorer bars, etc.). Windows ME/2000 can play audio and video previews in the side bar (all HTML based).

Also WinXP used a forked Trident engine with some removed features for "Software" dialog and various other features (Windows Help, etc).

Re: Electron is flash for the desktop (2016)

#622

Post by krisdol »

LeoNatan25 wrote: post #432
seanmcdirmid wrote: post #418

Earlier quoted context omitted.

VS Code has way fewer features than Visual Studio, especially for C#/.NET development. VS Code is a minimalistic IDE, very useful, especially for javascript development where tooling is quite minimal anyways. But let's not think that VS Code outclasses visual studio.

VS Code is not an IDE in the classic sense of what IDE is - integrated development environment. It's a text editor with some debugging extensions. I don't think it is even comparable to Visual Studio at all.

That line is getting really blurry with both Atom and VSCode. Haven't used VSCode, but the only feature I recall missing in Atom right now is refactoring; and to be fair, last time I used a real IDE (XCode), I couldn't refactor there either.

Re: Electron is flash for the desktop (2016)

#623

Post by cookiecaper »

bitwize wrote: post #608
cookiecaper wrote: post #193

Earlier quoted context omitted.

You don't have to rebuild your app for all platforms. Desktop widget toolkits (Qt, GTK+, wxWidgets, ...) have bindings out to most languages. If you can run Python, you can run a desktop app on all platforms from a single codebase. Also, all major platforms have C and C++ runtimes; if you write portable C or C++, your codebase should run on any of the big three. It's ridiculous to pretend that you have to write 3 dis…

If you target the native OS widget set, you must have a separate code base for each platform's native widgets. Things like Swing and Qt don't cut it. Macintosh users in particular are sensitive to things like the placement of and spacing between UI elements; if anything is "off" from the gold standard set forth by Apple, they will scream and bitch at you because perfect UI consistency is paramount with this crowd. We…

Overall, that sounds like an argument to exclude Mac support, if anything. But I would suggest that if it's so difficult to get the widgets exact, it's better to use a toolkit that can provide widget portability as well as precise implementations that pass through to native OS windowing.

>If you target the native OS widget set, you must have a separate code base for each platform's native widgets.

I want to clarify the subtle distinction here. If your code's concerns are separated, having to directly provide native widgets on some platforms means a different "codebase" for windowing and widgets only, not for everything. You'd still compile your normal code, and use an #ifdef or equivalent to include the appropriate windowing/widget library.

Re: Electron is flash for the desktop (2016)

#624

Post by frik »

gant wrote: post #443
frik wrote: post #386

Earlier quoted context omitted.

Steam always used a HTML renderer, even in its 2006 first incarnation. Nowadays it uses the same CEF (chrome library) as electron uses. So Steam was one of the first "Electron" apps. A very first one was Windows Explorer as of Shell update that came with Internet Explorer for Windows 95 (included by default in Win98). All the sidebars of Explorer were HTML based.

No, VGUI is not HTML. Here's a fun one. Start Steam with `-dev` and hit F7. Widget factory VGUI edition! Oh also, https://developer.valvesoftware.com/wiki/VGUI_Documentation

Have I talked about VGUI? No.

Valve used a very ubscure/niche HTML render engine initially for Steam (2006). The company/website behind that isn't online anymore. An older version of the Wiki had some brief info, but all these info vanished.

Re: Electron is flash for the desktop (2016)

#625

Post by pdabbadabba »

pharrington wrote: post #497
pdabbadabba wrote: post #172

Earlier quoted context omitted.

Well, to the extent that these costs degrade the user experience, I'm not sure they really are externalizing them. Presumably they pay this cost in the form of decreased user satisfaction. It's just that this is a cost they are willing to pay. There may be an interesting economic lesson here: it really is not that easy to externalize costs. It surely can be done (air pollution), but it requires some special circumsta…

I don't understand. The cost is mostly externalized into, quite literally, massively distributed increased electricity consumption. That an individual's power bill may be subsidized only emphasizes that problem.

It sounds like we agree. To the extent we're just talking about electricity costs, then it's true that easily written, but inefficient code may indeed externalize these costs to the extent that users are unaware of the added power consumption, or that the user herself does not pay the full cost of that electricity.

But these electricity costs struck me as only a small part of the broader point I was responding to, which is what I framed the point the way I did.

Re: Electron is flash for the desktop (2016)

#626

Post by atombender »

Touche wrote: post #600
lobster_johnson wrote: post #469

Earlier quoted context omitted.

You don't select or navigate in text? Shift+arrows — select characters Option+arrows — jump between words or paragraphs Cmd+arrows — jump to beginning/end of line or text Shift+Option+arrows — select words or paragraphs Option+Backspace — delete one word back Cmd+A — select all I actually used all of these except the last one while writing and formatting this comment! Plus clipboard shortcuts. If you use vim in a ter…

I use Cmd+A, that's it. It has a close corollary on every OS. > If you use vim in a terminal 100% of the time, none of those will matter to you because vim invents its own keyboard universe. I do, and this is one of the reasons I've never bothered with all of the details and shortcuts that you like. Vim attempts to make the best possible text editor. It doesn't let "OS conventions" dictate what makes good text editin…

Sorry if this sounds negative, but I'm perplexed why you would even involve yourself in the discussion when you don't have an opinion. It's like asking a bicyclist about how highways should work. They might go "I don't want any highways at all", but that's hardly useful to highway users (environmental concerns notwithstanding).

Re: Electron is flash for the desktop (2016)

#627

Post by m_fayer »

douche wrote: post #484
bluejekyll wrote: post #355

Earlier quoted context omitted.

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.

In 2014 I laughed.

No longer laughing.

https://www.destroyallsoftware.com/talks/the-birth-and-death...

Re: Electron is flash for the desktop (2016)

#628

Post by RedCrowbar »

newhere420 wrote: post #509
RedCrowbar wrote: post #395

Earlier quoted context omitted.

Each Chrome (and Electron) app instance is a group of processes. You are probably just looking at the main process, while the bulk of RAM/CPU use comes from the renderer processes. Here are stats on my (Linux) box: * atom - ~500MiB (one window) * slack - ~816MiB * chrome - ~935MiB (two tabs + hangouts) * google music electron app - ~500MiB

Nope, those figures were after adding up all the processes. What I have noticed in switching between platforms is that applications tend to report a far lower memory usage in Windows than on Linux or OS X. Might just be an accounting difference. Forked process applications in particular are very difficult to account, because even their private/RSS may be COW from another process.

My figures exclude shared memory and are calculated as VmRss - Shared from /proc//statm.

If you are using Windows 10, your missing Atom processes will be under Background Processes in Task Manager. For the sake of the argument, I just did a fresh install of Atom and this is what I see on the first run: https://i.imgur.com/0ZRSumF.png. ~220MiB (no files open, zero extensions).

Re: Electron is flash for the desktop (2016)

#629

Post by nilliams »

laythea wrote: post #488
matthewmacleod wrote: post #283

Earlier quoted context omitted.

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.

Not sure if ironic, seems a sure bet most users won't notice and gladly prefer the "bloated" product.

Yet to hear a single non-dev coworker complain about Spotify being "bloated".

Re: Electron is flash for the desktop (2016)

#630

Post by [deleted] »

RedCrowbar wrote: post #395
newhere420 wrote: post #368

Earlier quoted context omitted.

> Electron applications are shite in comparison with proper native applications. They fail to integrate with the host platform, they are slow, they hog memory and drink power. Are they though? The two applications that use the most energy on my Mac - by far - are Steam and Skype. Steam still has trouble with HiDPI and freezes when performing various UI interactions. The number of problems with Skype are uncountable.…

Each Chrome (and Electron) app instance is a group of processes. You are probably just looking at the main process, while the bulk of RAM/CPU use comes from the renderer processes. Here are stats on my (Linux) box: * atom - ~500MiB (one window) * slack - ~816MiB * chrome - ~935MiB (two tabs + hangouts) * google music electron app - ~500MiB

[deleted]
Post reply on HN