Live data from Hacker News

Electron 3.0.0

electronjs.org

111–120 of 141 posts

Re: Electron 3.0.0

#111

Earlier quoted context omitted.

yes, it's pretty nice to get new stuff :D

Would you also like a lollipop? You can get one at the kids JS "dev" table.

Posting uncivilly will get you banned here, so please don't do this again.

https://news.ycombinator.com/newsguidelines.html

Re: Electron 3.0.0

#112
Out of curiosity, assuming that Node 10.8 (or the latest version we're on) doesn't break anything from 10.2, and also assuming that the Node abstraction layer protects developers from underlying V8 ABI changes; why would Electron release a new version with dated versions of Node and V8?

Is it because of a release cycle?

Re: Electron 3.0.0

#113

Earlier quoted context omitted.

> from a giant pool of cheap, generic, interchangeable, fully replaceable developers A giant pool? Sorry, not really. JS skills are highly sought after, and finding good, experienced front end developers is very hard. Inexperienced developers are easy to find in any language, including your favorite one, whatever that is. The "cheap, generic, interchangeable, fully replaceable" part just sounds bitter and vindictive,…

When compared to the hiring pools for iOS and Android devs, the size of the web front end pool is certainly larger, because that’s what’s currently hot and has the lowest barrier to entry. You’re right that quality is just as hard to find, but given the performance issues that continually plague most modern web apps (with apps like VS Code serving as evidence that it need not be that way), I’m not convinced that qual…

If you compare the demand for websites vs mobile apps, we have about a total of 5 million downloadable apps and about 644 million active websites according to netcraft, which can be interpreted as 131 web devs for every 1 app dev. The pool for webdevs should therefore be much larger.

As for quality, correctly accessing a devs level of competence can be very tricky, regardless of the required skill-set. With web devs, its even more tricky because an "over-qualified" desktop/app devs can do just as much damage in terms of technical debt as a poor quality web dev. A webdev is also a specialized developer, but due to the low entry barrier, many don't realize this.

Re: Electron 3.0.0

#114

Earlier quoted context omitted.

If it makes for easier programming, yes. Writing Slack as a native app would be a massive pain. Especially due to all the web-like features it has, the fact that it's one codebase (mainly) for desktop and web. They also have to support Windows, Linux, Mac and mobile. Not an easy task

The Mac cocoa version of Telegram achieves most of the same features as slack without resorting to webviews and shares 99% of its code with the iOS app (meaning the Mac build adds practically no overhead). Windows and Linux are another beast, and Telegram’s solution is to use Qt for those platforms. Again, slack like capabilities with no webviews. The difficulty of native dev is not as high as it’s often represented.

I have little experience with native iOS development, so you might well be right. That said, Telegram strikes me as quite a bit simpler than Slack. Not just in number of features, but also considering how many of the features are 'strange' UI.

As an aside, apparently the next version of Telegram will be a complete rewrite done in Swift, and snappier as a result.

Re: Electron 3.0.0

#115

Earlier quoted context omitted.

It's not writing the native code that's the problem, it's designing the same GUI experience across platforms that's nearly impossible to do. If it was so easy as you said, a lot of macOS apps would've been portable to Windows years ago given the market share. I work for a cross-platform company, Windows is a much more difficult to develop for compared to macOS. You can write a Cocoa UI but what do you do on Windows w…

In Slack’s case, why an app at all? It already works with browser notifications. The Slack app is a worse experience than the website. It’s a memory and more importantly a battery hog.

I really enjoy a separate app as opposed to a browser tab. For one thing I can push it out of the way up in my task bar. I don't live in Slack and only use it occasionally, so it's nice to have it close by but not in my face. Also, the ability to quickly alt-tab to/from it makes it much more accessible for me.

I tried to use the browser version and it works well enough, but it broke my workflow and was distracting. The app has its own set of problems but at least it lets me work the way I want.

Re: Electron 3.0.0

#116

I really hope whatever the NativeWindow changes are allow Slack to finally stop rendering when the app goes to the background. My battery has been killed a couple times by the Slack renderer using ~30% cpu playing gifs while the app isn't visible, and their support says its because they don't have a notification hook for minimizing

FWIW I disabled animations in the slack settings and the difference is night and day.

Re: Electron 3.0.0

#117

Earlier quoted context omitted.

It's not writing the native code that's the problem, it's designing the same GUI experience across platforms that's nearly impossible to do. If it was so easy as you said, a lot of macOS apps would've been portable to Windows years ago given the market share. I work for a cross-platform company, Windows is a much more difficult to develop for compared to macOS. You can write a Cocoa UI but what do you do on Windows w…

In Slack’s case, why an app at all? It already works with browser notifications. The Slack app is a worse experience than the website. It’s a memory and more importantly a battery hog.

Biggest problem in web apps, at least to me, is window management. When you switch to Chrome (on Mac), all browser windows come to foreground. I want to keep Slack as its own app so that it stays in the background until needed. I also want to keep it separated in Dock and Cmd-Tab switching etc.

Re: Electron 3.0.0

#118
post #58

Earlier quoted context omitted.

Yes. At least N times the work for N platforms. Fewer developers, harder to recruit. Cross-platform options like Qt are not modern/pretty enough and sometimes aren't that much thinner than Electron (depending on how well written the app is). Java/Swing/SWT is also quite bloated and looks terrible. Development is much slower in languages like C++. Other languages are not cross-platform or have immature/buggy cross pla…

> Go back and use the VB.NET GUI builder from 2004 and be in awe at the incredible productivity you could achieve. That almost nothing like this exists today is evidence that personal computing is dying, IMO. Companies don't want to empower users, they want them to be good little content consumers who do what the ads tell them. Developers (OSS developers included) don't respect them and assume they're too stupid to b…

> Developers (OSS developers included) don't respect them and assume they're too stupid to be permitted to use anything but the safety scissors. After all, if they were worthy of creating things they'd be C greybeards.

Thanks for mentioning that too. I loathe that mentality.

What people don't understand is that it hobbles the developers/geeks too. It causes us to build systems that waste our time futzing around with minutia. Bad UX and bad tooling is objectively bad in that it imposes needless cognitive load.

I learned this when I (almost cliche) switched from Linux desktop to Mac. I was amazed at how much more I got done when I didn't have to futz with drivers, config options, broken packages, etc. I now probably spend an hour a month messing with my computer compared to an hour a day.

Re: Electron 3.0.0

#119
post #85
post #58

Earlier quoted context omitted.

Yes. At least N times the work for N platforms. Fewer developers, harder to recruit. Cross-platform options like Qt are not modern/pretty enough and sometimes aren't that much thinner than Electron (depending on how well written the app is). Java/Swing/SWT is also quite bloated and looks terrible. Development is much slower in languages like C++. Other languages are not cross-platform or have immature/buggy cross pla…

> At least N times the work for N platforms. Only if 100% of the code is the GUI.

It's still N times the work. You trade rewriting the core for figuring out how to meld your vision to two different APIs, two different UI libraries, etc., and of course fixing all the quirks.

Re: Electron 3.0.0

#120
post #58

Earlier quoted context omitted.

Is writing native apps honestly still so hard these days? I can appreciate the concerns about maintaining multiple codebases and dealing with different delivery mechanisms and their rules, but modern iOS/macOS and Windows APIs (at least; I cannot speak for Android and Linux) seem just as easy, let you work in arguably better languages, evolve at a faster rate, and provide a better experience for users and their machi…

Yes. At least N times the work for N platforms. Fewer developers, harder to recruit. Cross-platform options like Qt are not modern/pretty enough and sometimes aren't that much thinner than Electron (depending on how well written the app is). Java/Swing/SWT is also quite bloated and looks terrible. Development is much slower in languages like C++. Other languages are not cross-platform or have immature/buggy cross pla…

What did the old VB.NET GUI builder do better than the Windows Forms Designer in a newer Visual Studio? (I haven't used either, but know Delphi from far back when and its open "clone" Lazerus)
Post reply on HN