Live data from Hacker News

Electron 7.0

electronjs.org

271–280 of 289 posts

Re: Electron 7.0

#271

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.

Unfortunately swift doesn't have a meaningful windows story, and giving up on 100s of millions of users is less than ideal for most "crossplatform" contexts. :/

Swift is open-source at least, and I expect/hope SwiftUI will be too once the "secret" Swift features it relies on, have matured.

So even if Apple doesn't want to port SwiftUI, maybe other people could.

Re: Electron 7.0

#272
post #185
post #159

Earlier quoted context omitted.

Personally I'm fine with application specific UI schemes. It's a bit silly every application would follow the same guidelines as applications are intended to do different things. Platform UX/UI conventions place too strict limitations on innovation. The original point - that people would get confused from non-platform UI schemes - has been proven kind of moot since most games have their own domain specific UI schemes…

> has been proven kind of moot since most games have their own domain specific UI schemes and people love them anyway. I emphatically disagree. There are still jokes (from legitimate annoyance) that the main consoles have different conventions for buttons and button names. It's awkward to navigate menu system with a simple up, down, left, right, accept, cancel when accept/cancel move around system to system. At least…

I hear you. I forget the control schemes as well, whether they are keyboard or controller.

But the thing about those is that they are 'hidden' and require memoization. There is no on-game HUD that would show legend of all the available actions all the time. If you could have that, then people would be much more comfortable about even the hidden schemes.

There are game UI:s that are mostly mouse operated, and expose the user interaction grammar using the game specific, visual UI narrative. My kids seem fine navigating between those. A great example is Roblox, which has lot of "controller heavy" games where there are custom UI:s for building and configuring lots of things.

There are no guidelines that the authors defer to, but, they organically try to make the UI:s as understandable as possible. Most of the time they copy established conventions anyway, and when they don't either the UI is still understandable or no-one will play the game.

Re: Electron 7.0

#273
post #233

Earlier quoted context omitted.

There are a couple that are cross platform and still native, such as Microsoft Office and the Affinity suite.

Microsoft Office has gotten way better over the years. They used to design the UX around the idea of "Office Users", not "Mac Users"

This is very frustrating when supporting a mixed team of Mac and PC users on office. I would prefer it to be the same everywhere.

Re: Electron 7.0

#274
post #93

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 know people like to rag on Electron, but without it, I wouldn’t be using something else, my apps just wouldn’t exist . It allows more people to try building more thing and that is a net positive. The speed problems and bloat issues of Electron is just shoddy programming on t…

For me, and probably others, the main issue with Electron isn't the speed or even resource usage. It's that it ignores common UX/UI conventions you expect from a native app which still makes me prefer native macOS apps.

I'm intrigued by this. How do you cope with the www?

I use web apps so often that Electron looks natural

Re: Electron 7.0

#275

Earlier quoted context omitted.

> "Separate instances of chrome for every app is dumb and consumes too much memory" That one is true though. Different Electron apps could at least share the runtime.

Except they cannot, Chromium (or is it Blink?) changes too frequently to reliably code for one version and expect backward compatibility of future releases. Electron versions could be shared libraries... except again BC breaking releases proliferate.

Except they chose not to, preferring to allow for frequent breaking changes. This makes it easier for devs to make these rapid changes with all the cost/overhead payed by you.

Re: Electron 7.0

#276

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

If you are willing to code your own GUI widgets, it's also pretty easy to do cross-platform. You can opt for OpenGL or similar and a little glue for the various platforms. If you slowly grow a collection of just your favorite widtes, that's totally doable. Will grow to maybe 10-15K lines of C code. That's a lot of explicit code, but on the upside the code will be more maintainable compared to all the boilerplate the would be required to bend a super-general library to fit your requirements.

I've done a few OpenGL toy apps in the last months, and one commercial project that includes text widgets, editing, table views, buttons, scrollbars and so on. It also scales freely. It's not that hard, and the next time will be even easier.

Re: Electron 7.0

#277
post #93

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 know people like to rag on Electron, but without it, I wouldn’t be using something else, my apps just wouldn’t exist . It allows more people to try building more thing and that is a net positive. The speed problems and bloat issues of Electron is just shoddy programming on t…

For me, and probably others, the main issue with Electron isn't the speed or even resource usage. It's that it ignores common UX/UI conventions you expect from a native app which still makes me prefer native macOS apps.

Really, that's not an issue with Electron, I think. You can perfectly well make use of a common platform toolkit and still make a completely counter-intuitive UI - and people did that, a lot. In the end, the important things are things like that the cancel button is on the left and the button to confirm is on the right (depending on your platform), not whether it's grey or blue.

And I'd even argue that, with the freedom Electron gives you, app developers have started to actually pay attention to their design, rather than just using the standard toolkit and considering it done - so Electron apps often have better UI. I'd take VSCode's UI over Geany's any time, for example.

Re: Electron 7.0

#278

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

> will gravitate towards a fairly common set of widgets that will

Is there anything like that? There is for mobile (Framework7 I like the most) but is there anything for desktop that allows me to create applications with electron in a more desktop like way? I am one of those people that doesn't really html/css. In WPF/QT/Winforms/Gtks/Xamarin/Avalonia/iOS/Android/Lazarus/Livecode I can create complex applications very fast (and a few of these are cross platform too); they don't look great (albeit consistent and not horrible), but something is working and working well in a very short time (hours). I have not found anything for Electron that works as fast as that, including bindings and logic etc.

I do a lot of HTML/css, but for web; simple things like getting a few decent looking panes with buttons and text etc that scales automatically still feels like a from scratch exercise and when using standard stuff like Bootstrap, everything looks and feels like web, not desktop. I have friends who created native looking Electron apps and it took forever to make it work well and look good (lot of quirks they had to deal with, but this is a while ago); with Qt or Avalonia (I use mostly C#) it would maybe (?) not look 'as good' (which is taste) but it would be done much faster.

There are things like [0] but then all look like Mac OS X. Are there any good ones cross platform or at least a little more 'neutral' than photon?

[0] http://photonkit.com/

Re: Electron 7.0

#279
post #261

Earlier quoted context omitted.

Microsoft has made it pretty clear since about Windows 10 that they don't actually care about the Desktop anymore. It certainly isn't anywhere near their biggest money-maker.

Indeed, that is why Microsoft has created teams to support React Native for macOS and Windows, on Windows case it makes use of UWP, which new roadmap (WinUI 3.0) was announced at BUILD 2019, with more details to come up on Ignite. Yeah, Microsoft bashing never grows old.

Yeah ok, fair point. Someone at Microsoft cares a bit about Windows, just not anybody working on the UX bits.

Re: Electron 7.0

#280

Earlier quoted context omitted.

Electron is so heavy you could include a copy of Windows 95 with every application and use its GUI. This is how ludicrous the state of modern computing is. Java accomplished the same thing with fewer limitations and vastly more efficiency. Best case scenario of the continuing "evolution" of electron is the elimination of the OS entirely. Why do you need it? Just put drivers in Chrome and be done with it. It's already…

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

> Does it matter?

Not really I guess, I mean who cares about the user's computing resources? Certainly not developers.

Post reply on HN