Live data from Hacker News

Electron is flash for the desktop (2016)

josephg.com

561–570 of 1001 posts

Re: Electron is flash for the desktop (2016)

#561

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…

The real trick is whether or not users care about: A) This works on all of the platforms that we use vs B) Performance could be better on my computer It's been a LOOOOOONG time since I worked on a laptop where I experienced noticeable performance problems...which is almost entirely because SSD's make them so much less noticeable if you start dipping into swap unless you're really working out your machine. For most us…

>It's especially true with a chat system where the most important feature is that everybody on the team can get access.

That's a complete other story... All that big open source movement for decades and in 2017 we are still depending on proprietary systems to provide a chat(!) for a company.

Re: Electron is flash for the desktop (2016)

#562

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…

The real trick is whether or not users care about: A) This works on all of the platforms that we use vs B) Performance could be better on my computer It's been a LOOOOOONG time since I worked on a laptop where I experienced noticeable performance problems...which is almost entirely because SSD's make them so much less noticeable if you start dipping into swap unless you're really working out your machine. For most us…

> It's been a LOOOOOONG time since I worked on a laptop where I experienced noticeable performance problems...

Really???

Because personally, I keep having performance problems on all laptops I have. Don't try running on battery saving mode, seriously.

I stop counting the 5+ years old laptops that have to be upgraded, they can't watch a youtube full HD video in good conditions.

----

Fun Anecdote: I had to trial an entreprisey SaaS solution not long ago. A coworker gave me the name and I opened the site on my laptop (on the move outside of work, just taking a quick look).

Their site froze my firefox for 30 seconds because these idiots put a high quality full screen video of a surfer in the background of the main page. Looks cool, doesn't it? https://www.wavefront.com/

Couldn't see the site. Had to be at work to read it, on my top end workstation, the video played smoothly there. Needless to say, didn't take the product seriously.

Re: Electron is flash for the desktop (2016)

#563

Earlier quoted context omitted.

> If your answer is "A native Cocoa/WPF app", you are on another planet If developers weren't so scared of Swift and C#, this wouldn't be a problem. > (writing Desktop apps) is massively expensive, both in terms of actual dev time per feature (easily 10x the cost), and also in finding specialist developers who know these dated technologies. I find the opposite to be almost universally true. Writing a lightweight nati…

No one is scared of C# and Swift, XAML and so on, but these technologies aren't even close to what you have available on the web. React and Redux make apps possible that you wouldn't get with older technologies, not even with 10 times the effort and code. The animation possibilities, transitions, the flexibility overall, the eco system, debugging capabilities, hot module reload - if you have worked with it, you will…

> these technologies aren't even close to what you have available on the web

Yeah, they're that much better, that we grumpy old non-JS programmers keep wondering what the big deal is when somebody comes along and rewrites something that existed 20 years ago.

Re: Electron is flash for the desktop (2016)

#564
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 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…

Of your examples, I know Slack fully supports all of them except indexing and accessibility. For those two, I don't know because neither are of concern to me.

Re: Electron is flash for the desktop (2016)

#565

Earlier quoted context omitted.

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.

Yeah, and they used C because the compilator could optimized stuff the JVM couldn't but now it can. And now Python get type hints so you can have the IDE tools you have with Java like with PyCharm. It's the circle of life.

Not quite correct about type hint. They are only in python 3.

Everyone who adopted python 2 on sizeable codebase is likely stuck there forever, with zero annotations and none of the new tools available, and they'll never be ported back.

Re: Electron is flash for the desktop (2016)

#566
post #176
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 downloaded this and signed up just to give it a try, since I've never used a Qt app on the Mac that didn't fall in the uncanny valley of UI -- trying to be native, but failing. This doesn't break the trend. Some problems: - Text boxes are non-native and do not support any standard keystrokes for navigation (this is huge!) - The division between the titlebar and the main app body is weird looking - Highlighting arou…

Mac citizen. Perhaps you should think of your computer as a thing computing things and showing them on the screen. There were many people in history obsessed with uniformity and it usually didn't end well. Yes, uniformity in UI has benefits, but you should appreciate every single deviation from that. In this case, it's the price for "write once, run everywhere", something that isn't appreciated by Apple and Microsoft.

Re: Electron is flash for the desktop (2016)

#567

Earlier quoted context omitted.

That's nonsense . Desktop apps have been frequently released since forever. The underlying issue here is that Electron reduces the barrier to entry for cross-platform development . That is, it's cheaper to build a single cross-platform application in Electron than it is to build two or three native applications, and you can re-use your existing web experience. I can completely understand why companies might choose th…

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

Mac is a third class ports for these software. They never got optimized like on windows. Not a fair comparison.

With electron, every OS is a third class port.

Re: Electron is flash for the desktop (2016)

#568

Earlier quoted context omitted.

That's nonsense . Desktop apps have been frequently released since forever. The underlying issue here is that Electron reduces the barrier to entry for cross-platform development . That is, it's cheaper to build a single cross-platform application in Electron than it is to build two or three native applications, and you can re-use your existing web experience. I can completely understand why companies might choose th…

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

> * Spotify - 58MB

Maybe for one of the processes, but on Windows Spotify needs at least three processes usually to run (five if you count the Web Helper and Crash Service which are probably native code). On my machine the three main Spotify.exe processes take up at least 170MB of RAM, often more. Although I wasn't aware they were using Electron as their app has a standard, native Windows menu bar.

Re: Electron is flash for the desktop (2016)

#569

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…

YOU ARE SO RIGHT AND IT IS VERY SAD THAT PEOPLE DONT REALIZE IT

Re: Electron is flash for the desktop (2016)

#570
post #115

Earlier quoted context omitted.

I agree and the author fails to mention the tradeoff between ram/diskspace and development time. >>all you web devs: Go learn C or Rust or something. Your program runs on a computer. I don't think that is a realistic request. When the cost of Slack's ram/diskspace usage starts affecting their profit then they can/will take steps to re-write the application in 'native' code. Until then its premature optimization?

C is not that hard! If you're a programmer, and you don't know C, you're not good at your craft. I realize that sounds incredibly harsh but it's true: your job is to make a computer do a task efficiently. If you can't even read the language that makes that possible, you don't know what you're doing.

I could re-write your argument by replacing "C" with "x86 assembler" - but I won't. However, the argument could still stand, but I'd hesitate at saying it's a wholly valid argument.

My own prejudice aside - I honestly do think that if you don't have an understanding of how a CPU works at this very low level - maybe even lower - you don't know what you're doing; that, and I have done hand-assembled x86, 6502, and 6809 code in the past...

It's a different time; knowledge of lower level languages isn't needed today to be a successful software developer who knows their craft. And I recognize my prejudices as such, thus while I tell them, I understand that they really can't apply. Would I like it if these new guys all knew this kind of stuff? Well - yeah; but the same could be said of me by guys long gone and dead as to why I don't know how to wire up an analogue computer to solve a calculus problem, or why I can't wire up a plugboard to compute something on a IBM 401 or such. That doesn't make them a better developer, nor me or anyone else a worse one. We're just using different technologies.

That said, I do think developers should branch out, and at least have an understanding of other languages; maybe C/C++ - but even Java, Python, GoLang, Rust, etc - all could be just as useful to know.

Today - career-wise - I am a javascript/node.js developer - before that, I mainly used PHP. At home, I play with Perl, C/C++, and Python (these latter two more recently being involved in machine learning, TensorFlow, and Keras). Occasionally, I'll get a bit nostalgic and break out BASIC (my favorite today is QB64). Can't say I've done any recent assembler coding - but it doesn't scare me, either. Just another way of communicating with the machine.

Post reply on HN