Live data from Hacker News

Electron is flash for the desktop (2016)

josephg.com

401–410 of 1001 posts

Re: Electron is flash for the desktop (2016)

#401

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…

With my company, our users have always begged for an Mac OSX and iOS app. We never provided it, because we have zero-internal expertise with any of the technologies involved. We could contract, or hire for that specific purpose, but the moment that team member was gone the project would be dead and out of sync with the rest of the codebase. The codebase isn't lightweight to begin with, and duplicating it for a native…

> With my company, our users have always begged for an Mac OSX and iOS app. We never provided it, because we have zero-internal expertise with any of the technologies involved. We could contract, or hire for that specific purpose, but the moment that team member was gone the project would be dead and out of sync with the rest of the codebase.

I don't see how that is any different. If your Windows team members all left, that project would be dead or out-of-sync too. Wouldn't you replace valued team members who leave, in both cases? Or is this a concern that you won't be able to find developers willing to work with OSX and/or iOS tech?

> With my company, our users have always begged for an Mac OSX and iOS app.

Repeating this again because this should be telling. If your getting feedback begging for an OSX and iOS app, there's probably a number of really good reasons for that.

> What'd be a good example for the kind of lightweight project that can reasonable be duplicated for Native Mobile, Native Tablet, Native Desktop, & Web Browsers?

Spotify, Slack, Twitter, Facebook, any streaming video service (Hulu, Netflix, Amazon Prime Video, HBO GO), etc.

Note that I'm not using "lightweight" to mean "small weekend project", but to mean "less complex than the codebase needed to reproduce these features in a browser or Electron browser".

--

If you are truly a small company / startup, and you truly have to support all platforms with a small team, then sure Electron makes sense despite all the drawbacks. I totally understand that.

But I usually hear this excuse from big companies, that still want to perceive themselves as small, but aren't. Slack is a billion dollar company, they are not a small business / small startup. If a company is large enough to have more than two people working in HR full time, then they are probably big enough to do this stuff right. "We're a small team" simply isn't true for them.

Re: Electron is flash for the desktop (2016)

#402
post #344

Earlier quoted context omitted.

Vim and Emacs are probably much slimmer, but a comparable GUI editor- Sublime Text, is using 311 megabytes for just one window of a folder that has 200 files in it.

> 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?

Re: Electron is flash for the desktop (2016)

#403
There's two kinds of developers. Dorks who care about programming, and programmers who care about creating deliverable value.

What do consumers think about electron apps? That's all that matters. Consumers don't know what the heck electron is, only that their apps work seamlessly across platforms. The only people who complain about electron apps are dorks who have an axe to grind with web developers.

I'd rather have my apps use more resources than crashing unexpectedly and opening up security holes because the developers thought it'd be hipster to write it in C.

Re: Electron is flash for the desktop (2016)

#404
At Nylas we made a huge bet on Electron-- our desktop app Nylas Mail actually started as a fork of Atom Shell before the project was rebranded to "Electron."

To be honest, we would have never built this app without Electron. It allowed us to have a small team (2 devs) ship the first version of the app without learning an entire new dev toolchain on multiple platforms. There certainly can be performance issues with building on Chromium/Node but those can be pretty easily addressed.

We even had an early engineer with tons of Cocoa/ObjC programming experience and they still preferred shipping with Electron.

The HN crowd complaining about Electron kind of feels like the early criticism of Dropbox or the iPod. "This is technologically inferior and has fewer features so it is clearly worthless."

For some reason there's a deep-rooted philosophical opposition to Electron-like technologies from lots of hackers. But I predict it will be like Java-- everyone "hates" the JVM for years and calls it slow and then one day it's running nearly every mobile device and being used across Google.

It's not crazy to think Electron will evolve like this-- it certainly has the momentum. And the ideas of a web-based desktop app platform have been pushed by Google, Apple, and Microsoft in the past. Seems like we're finally getting there...

(For the curious: https://github.com/nylas/nylas-mail )

Re: Electron is flash for the desktop (2016)

#405

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…

> React native will probably be the best way forward. ... RN runs natively, doesn't need a browser, while being able to tap into the JS eco system.

Similar arguments were made when Java first came on the scene. "Write once, run anywhere." [1] Years later, here we are again with "native" Javascript libraries. I'm sure in another 20 years or so we'll be rehashing this again, just with some other language.

[1] https://en.wikipedia.org/wiki/Write_once,_run_anywhere

Re: Electron is flash for the desktop (2016)

#406

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.

I can't help but think there's a different flavor to this than with higher-level languages. This is adding a platform on top of another platform. The same objections existed years ago with Java when Swing was released. Java is a cross-platform high-level language but Swing is basically an entirely new platform. It's this platform on top of a platform that is objectionable from a performance, memory, storage, and inte…

We see the same thing with containers. Docker, flatpak, snap... It's just the right time for it.

Languages have evolve to change the way we handle constraints like memory, speed, readability, expressivity etc.

We are arriving at the pick of what languages can bring on the table. Sure we can improve things here and there, but the huge challenges now are integration, packaging, distribution, updates, communications, multi-tiers architectures and all that.

So we now tweak platforms to help us with that.

But because we didn't see that coming, it's not done in any structured way. It's done exactly the way we did everything since the beginning of computing, by stitching together stuff then hitting hard on it with a hammer until the job is done.

This is not new. IT is a joke of an engineering field. We hack everything, don't think about the future, and then end up using the status quote. It's always has been like that.

Re: Electron is flash for the desktop (2016)

#407

Earlier quoted context omitted.

clearly you aren't talking about emacs :)

I remember a long time ago people discussing that Emacs would never be popular on PCs because nobody had 10MB sitting around just to use a text editor...

Emacs is not just a text editor. It's an operating system.

Re: Electron is flash for the desktop (2016)

#408

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

The flip side perspective of this is that end users are forever plagued with poorly-performing/behaving software, because developers favor their convience over user experience by continually moving on to new technologies before they're mature enough to be satisfactory replacements of the old stuff.

Re: Electron is flash for the desktop (2016)

#409
post #279

Earlier quoted context omitted.

> I wanted to pick on Spotify and Atom more in my blog post, but both Spotify and Atom have cleaned up their act Can you please share how you came to the conclusion that Spotify is made with Electron? (hint: it's not)

It uses WebViews heavily.

I'm not saying it doesn't, it's built on Chromium Embedded Framework.

The author is claiming it's built on Electron, which is false.

Re: Electron is flash for the desktop (2016)

#410
post #243

Earlier quoted context omitted.

Blog author here. Thats a fair criticism. I wanted to pick on Spotify and Atom more in my blog post, but both Spotify and Atom have cleaned up their act. I couldn't get either one to reproducibly use lots of CPU. Props to everyone involved in fixing that. But I'd also argue that Flash could always be written to be efficient too. The problem with flash was never the little games people made. The problem was that one t…

> ... I couldn't get either one [Spotify or Atom] to reproducibly use lots of CPU. Props to everyone involved in fixing that. It seems deceiving to conceal that information when your call to action is to ditch Electron for the sake of performance.

The original blog post is from Oct 2016... can't reproduce the bug now. That's ok; not deceiving.
Post reply on HN