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

Electron 7.0

electronjs.org

Post reply on HN
Print view View original

251–260 of 289 posts

Re: Electron 7.0

#251

Post by Razengan »

jcelerier wrote: post #183
Razengan wrote: post #43

Earlier quoted context omitted.

> (even with QT you still need to adjust for conventions, spacing etc...) That is what I'm talking about: SwiftUI automatically uses the recommended conventions for spacing, padding, etc. which are different for macOS vs. iOS etc., and it also takes user environment settings into account, like font sizes and other accessibility options.

Qt does that, too, but that is not nearly enough if you really want to make pixel- and interaction- perfect things. A "native" macos app is fundamentally different from a "native" windows app. Dock vs systray, different usage of menus, mouse and keyboard. Different widgets - Windows does not use baloon widgets and sheets. etc etc...

> A "native" macos app is fundamentally different from a "native" windows app.

The visual and interactive differences between a macOS app and a Windows app are actually less stark than the differences between a macOS app and a watchOS app (crown) or a tvOS app (remote), but so far, despite its early bugs and limitations, SwiftUI does a great job of outputting the native controls on all [of Apple's] platforms.

Things like NavigationViews and TabViews produce different beasts on macOS, iOS, iPadOS, and tvOS, from the same code.

See WWDC 2019: SwiftUI On All Devices: https://developer.apple.com/videos/play/wwdc2019/240/

Re: Electron 7.0

#252

Post by frutiger »

grumpy8 wrote: post #61
Razengan wrote: post #3

Since this is inevitably going to generate some discussion over native apps vs. Electron (ah there's already a fellow comment about it), I'd like to point out an example that is important to me of why Electron is an inferior experience for users: In the GitHub Desktop client, which is an Electron app, I can't spell check my commit messages, something that every text field in every native macOS app gets for free.

I don't know why that is, but in the end, aren't web browsers using the native os widgets for input text, etc.?

No. They are typically all custom rendered using e.g. Cairo. In a native Win32 app every entry would be its own HWND. In a web page every input element is not an HWND; then entire web page is a single HWND.

Re: Electron 7.0

#253

Post by pjmlp »

scrollaway wrote: post #5

I'm bullish on Electron. I think it's just a couple of technical advancements away from being the ultimate desktop toolkit. For context, I love and have worked a ton with Qt, and I much prefer Qt UIs as a user. But Electron has brought true cross-platform development to all platforms (Including Linux!). If it weren't for Electron, I wouldn't even have a bunch of the apps I use today. Hell, I wouldn't have a good IDE,…

Laziness always wins apparently.

Re: Electron 7.0

#254

Post by equasar »

choeger wrote: post #250
The_rationalist wrote: post #68

Earlier quoted context omitted.

Many of your critics are fallible but I will not spend time arguing, sadly. Yet,what do you think of TypeScript? It's a state of the art language feature wise (for it's rich type system)

Typescript goes in the right direction, but the last time I checked, its type system was mediocre at best.

> mediocre at best.

care to elaborate?

Re: Electron 7.0

#255

Post by pjmlp »

tybit wrote: post #193
rolleiflex wrote: post #140

Earlier quoted context omitted.

That is true and as a user of Sublime myself, I agree. However, VSCode is still a JS app that has to do its computation on a single thread, on a largely interpreted language. If you do it the way I do and use Electron as a skin / thin client to a compiled binary within the package, you remove that bottleneck. That way, you get both cross-OS capabilities, a familiar UI toolkit (JavaScript, I use Vue) and native binary…

I really hope this is the sort of thing products like VSCode will start turning to WASM for. Performance is their Achilles heel for the time being even though they’ve done a relatively good job considering.

The Microsoft's React Native for Windows/macOS team keeps comparing how Electron sucks to React Native, so I am hoping that they eventually manage to pull Viscose into their direction.

Re: Electron 7.0

#256

Post by pjmlp »

cweagans wrote: post #201
inferiorhuman wrote: post #196

Earlier quoted context omitted.

You seem to care an awful lot about an issue that doesn't seem to affect you. Why? Because it does effect me. Electron is promoting a monoculture of apps that don't behave well (resource usage, accessibility, abysmal native integration) and they're not portable to boot. What that means in real terms is that more and more that quality native apps become less common and hacky Electron apps become more common. Unless yo…

> Because it does effect me. [..] VS Code? Definitely not my first choice, but its rust support is still better than IntelliJ So choose an Electron supported OS or add OpenBSD support to Electron somehow. If VS Code is important enough to you, then that's a trade-off you have to make. I don't think I'd agree that Electron is "hacky". I'd certainly say it has shortcomings, but what technology doesn't? Rust certainly d…

Qt themselves offer Python support.

Re: Electron 7.0

#257

Post by pjmlp »

shrimp_emoji wrote: post #187
AnIdiotOnTheNet wrote: post #145

Earlier quoted context omitted.

You can quite easily bundle the Java runtime with your application. Many Java applications do this. As a bonus, it will still be smaller than the equivalent Electron application.

Except Java applets are a thing of the past while seamless browser/browser-based software is a convenient thing of the present (and probably future[0]) and prioritizing size more than availability and usability is fighting the last war harder than a stranded Imperial Japanese soldier. 0: http://wasm.continuation-labs.com/d3demo/

Java applets are not a thing of the past thanks WebAssembly.

Plus we are talking about regular Java here.

Re: Electron 7.0

#258

Post by cocochanel »

big_chungus wrote: post #216
yodsanklai wrote: post #206

Earlier quoted context omitted.

> Electron is so heavy Does it matter? I think heaviness should be defined relatively to the computer resources. Currently VSCode memory usage is 75MB on my computer. It could be 10 times less, it wouldn't make any difference.

Which OS are you using for that kind of memory usage? I've tried it, and seen double that out-of-the-box.

50.6MB for me on a 2018 MacBook Pro running macOS Mojave.

Re: Electron 7.0

#259

Post by alkonaut »

big_chungus wrote: post #217
alkonaut wrote: post #84

Earlier quoted context omitted.

If only each OS would ship an abstraction layer that guaranteed "at least modern browser X" that one could ship into. I want to ship an electron app but I want it to be 100kb and start in 0.1s and take almost no memory because the libs are shared. I don't want each little chat app or music player to gobble up half a gig of ram and take 3 seconds to start.

You just re-invented the PWA, basically. Only modern browsers support them (though you can't guarantee eveyrone has one), so you just package and ship a web site. Of course, browser tabs themselves can take a lot of memory; a fair number take 50 megs apiece, and some take 100, so don't bet on your site necessarily only taking a few kb.

Well I also need good native apis (files, hardware, OS integration, window management), and deployment scenarios like native apps.

But yes, like PWA but I want the app to run under the OS, not sandboxed in a browser.

Re: Electron 7.0

#260

Post by pjmlp »

wwright wrote: post #213
jcelerier wrote: post #180

Earlier quoted context omitted.

> I release two apps, across 3 OSes, in somewhat of a bimonthly cadence with a low defect rate. That’s 6 different binaries. I’m a solo founder. I release a Qt app for mac / windows / linux whenever I want by tagging a git commit and letting it be built by CI services. There is a single code base with almost zero platform-specific code. I really don't think that the technology choice is what matters in this.

As someone who has worked a lot with both Qt and React at my current job, I feel that React is significantly easier for almost everyone. Qt’s complexity negates a lot of its benefits in most hands.

Maybe it is my age showing off, but React easier than Qt??!
Post reply on HN