
Electron 9.0 - timothy-quinn
https://github.com/electron/electron/releases/tag/v9.0.0
======
fermienrico
I can instantly tell, not by the looks or aesthetics, but by the way an
Electron app behaves that it's not a native app. It has got that
"browser"-like feel to it. VSCode/Slack/etc have a different "feel" to the UI
vs. say Mail/Messages/Photos app. Not sure how to describe it. It is just the
way it reacts and responds. Does anyone else experience the same?

If there was a A/B test, I am pretty sure I can nail almost 100% of the
Electron-based apps. Same thing with MacOS vs Windows apps - Windows is a lot
"snappy" and MacOS is very "rounded and smooth" when it comes to the UI feel
(not looks).

For those curious about why we describe non-visual things in terms of visual
metaphors (sharp, smooth, etc) is because of adjacency of brain structures and
cross-wiring between them . It is called the Bouba/Kiki effect, "Bouba" is
round shape, and "Kiki" is a sharp shape, in almost every culture and it's
universal:
[https://en.wikipedia.org/wiki/Bouba/kiki_effect](https://en.wikipedia.org/wiki/Bouba/kiki_effect)

Edit: It feels like it is impossible to talk about opinions without getting
shafted by the "Electron lovers/haters" crowd. Wtf. I am not saying one is
better than the other. Even if I did, why can't we talk about it if it is
substantiated? A lot of this stuff is subjective and experiential.

Edit2: Stop upvoting you people! There is nothing to see here and I don't know
anything about the original topic, i.e. 9.0 release. Dump this thread please.

~~~
spankalee
> why can't we talk about it if it is substantiated?

Because we don't need every bit of news about Electron to turn into a thread
of people saying, yet again, "I don't like them compared to native apps".

We know already, and it's not relevant to the article. If the article was
opinion or research on the differences between Electron and native apps, or
suitability of Electron for certain use cases, etc., then your complaint would
be relevant.

But your comment is not relevant - it has almost nothing to do with the
contents of the article.

~~~
bootlooped
The biggest magnet for this phenomenon on Hacker News is Amazon. Every Amazon
article will undoubtedly have at least one comment complaining about
counterfeits.

~~~
saagarjha
It'll show up everywhere. Apple articles will get something about MacBook
keyboards (perhaps a bit less now that they've "fixed" it), Microsoft doing
anything with open source will get "EEE", Google will be "Google needs better
support", Facebook is "why would you ever use this privacy-violating
democracy-destroying nightmare". I haven't even gotten into non-company topics
yet.

------
untog
You don't like Electron apps? OK, we know. We know because every single time
anything about Electron is posted we have the same conversation why native is
better, and it gets the same replies articulating the reasons why people still
choose to develop with Electron anyway. As best I can tell absolutely nothing
has changed in this respect.

Perhaps this thread could discuss the v9.0.0 release of Electron instead?

~~~
fermienrico
Native apps have UI elements that have tremendous research behind it by
operating system vendors with deep pockets:
[https://developer.apple.com/design/human-interface-
guideline...](https://developer.apple.com/design/human-interface-
guidelines/macos/overview/themes/)

Whereas, a UI framework such as Bulma is spun up by a bunch of people who are
not as well funded: [https://bulma.io/](https://bulma.io/)

~~~
hombre_fatal
How is this relevant to the thread?

And despite all that, Apple's own apps (like Music.app) have very unintuitive
UX easily beat by 3rd party developers. Native apps also are privacy
nightmares and don't have uBlock nor a network tab. Let's not rehash this
every damn time.

~~~
saagarjha
Your complaints aren't relevant either, though: Music.app is terrible because
it doesn't follow the guidelines, and Electron apps are no better than native
apps from a privacy angle.

------
locusm
Am I a fan of Electron? Like most people here - I've never built on it. But I
am thankful that it has ushered in a ton of useful apps that do indeed work
across 3 different operating systems.

~~~
gruez
That argument really only makes sense for small companies who can't otherwise
afford to develop for multiple platforms. For huge companies like slack or
spotify, using electron is a cost-saving measure for them that creates an
externality for end users, in the form of greater resource usage.

~~~
woutr_be
And yet Slack and Spotify are some of the most used apps. I wonder if most end
users just don’t care about resource usage, as long as they can comfortably
run all their apps, why should they?

~~~
saagarjha
Slack and Spotify tend to have a fair amount of lock-in.

~~~
woutr_be
Perhaps, but making the assumption end users care about resource consumption
seems a bit silly. Most of these apps run perfectly fine, sure they use a bit
more resources than their native counterpart. But even for a technical person
like myself, I barely notice it.

So I’m not sure this arguments outweighs the cost of having to maintain
different native apps.

~~~
mercer
My experience is that as a technical person with a beefy computer, I am mostly
frustrated by the _knowledge_ of how much of a waste these apps are, and how
much faster they could start/run on my devices.

But a lot of my non-technical friends, many of them with much cheaper
computers, definitely grumble about Slack and the like. The difference is much
more noticeable on their hardware, and anyone I know who can get away with it
prefers to use WhatsApp or, in some cases, Telegram.

Lock-in definitely plays a big role. If you already need to keep Slack open
for your employer, you might as well use it for other things, for example.

~~~
woutr_be
> My experience is that as a technical person with a beefy computer, I am
> mostly frustrated by the knowledge of how much of a waste these apps are,
> and how much faster they could start/run on my devices.

I understand this point, and I definitely agree. But I'm also of the opinion
that some of these companies wouldn't be as popular if they tried to build
native apps from the start. They wouldn't be able to move so quickly, and
would be restrained by money and resources. Of course, once you grow (Slack &
Spotify) you should invest in making the experience as painless as possible.

~~~
mercer
Maybe. I used to assume as much, and as a solo developer I think there's a
good chance I would pick a non-native solution when necessary.

However, not only am I starting to doubt this, I think it's even less of an
issue for a startup that can afford at least a handful of developers.

First off, the few projects I've done with 'web tech' that had to be native-
ish (cordova, so web apps as 'proper' apps on your phone) have made me more
skeptical. Sure, at first it was nice to be able to build things using a stack
I was mostly familiar with.

But not properly knowing the development and build tools for Android/iOS made
me extremely uncomfortable. And if I'd bother mastering those, I might as well
go for native.

Having to jump through various hoops to get something that felt as native as
possible was difficult too.

And finally so many things were not part of my 'web developer toolset' anyways
that I might as well have learned the native approach (notifications, any
other integrations with the OS that web doesn't offer or doesn't offer on the
major platforms).

I mostly came away from that experience wondering if the main reason why we do
these things is a (somewhat) unreasonable fear of learning a new tech stack.

I can totally see the use case for Electron and Cordova and RubyMotion and so
on. But for a sufficiently experienced developer it might already be
preferable to just learn iOS and/or Android development, and for a company
that can afford a handful of developers getting one of each, at first, should
be doable.

But again, I could be wrong and it's just a growing feeling. Maybe I'm
underestimating the amount of work needed to do native development. I haven't
had the time to properly do so yet...

~~~
woutr_be
I've done both React Native / Cordova apps, and native iOS apps. To be honest,
in terms of development, they both felt the same to me (ignoring language), as
in, I was able to build both apps roughly at the same speed. However with one,
I also had an Android app with minimal efforts, with the other, I had to start
from scratch again.

I agree with you on the tool set tho, I also felt quite uncomfortable not
knowing how exactly React Native was doing all the things to make it work for
Android / iOS, and sometimes it was extremely difficult to access native
functionality.

At the end of the day, I don't know what the correct use case is, I see
advantages to both.

------
DenseComet
Are there any projects concerning providing an OS bundled electron that apps
can use instead of each app having to run its own? It would be nice in
reducing the overhead but I don't know if something like that could even be
implemented, or that devs would even use it.

~~~
szhu
I would love to have framework de-duplication work this way:

\- Each app ships with its own copy of the framework at a particular version.
This ensures that apps can be installed offline, just as before.

\- When running the app for the first time, the OS moves the framework to a
centrally-managed location. The new paths are assigned in a way that both
preserves both the version names and prevents collisions of frameworks with
the same name but that actually have different contents. For example, a
version of Electron could be moved to
/Library/SharedFrameworks/Electron/9.0.0-1234abc. This change alone makes it
such that two apps using identical versions of a framework can share
resources.

\- Each time the app runs, it tells the OS which version of the framework it's
using. For apps that don't want to do anything fancy, this will simply be the
version of the framework it shipped with, and the OS should take this to be
the default for legacy apps. The key here is to be conservative -- the default
setting should absolutely not cause more points of failure than if we didn't
have this system.

\- But if apps want to do more deduplication and take advantage of extra
features of newer versions of the framework that other apps might have
installed on the system, they can do that.

\- Note: I think it's preferable to have an API that allows the app to request
other versions of the framework, rather having the app specify a static
dependency range. You don't know how apps might go about checking whether a
newer version of a framework is safe to use. For example, maybe the developer
wants the app to potentially check the newer framework version's hash against
an online whitelist. This flexible solution allows for that.

\- The OS keeps track of the frameworks that the app last used. Once no app
has last used a version of a framework, that version can be discarded.

\- Caveat: If an app allows the user to switch between multiple versions of a
framework for some reason (e.g., LaTEX), it will tell the OS that it is using
all of those versions. This will ensure that the version that isn't currently
being used doesn't get discarded by the OS.

\- Bonus points: Apps can also use an OS-provided API to install new versions
of a framework. But the API doesn't allow for explicit removal, since other
apps might be using it. This also allows apps that always want to use the
latest version of a framework to ship with a much smaller app bundle, and
download the framework on first launch. (Chrome could probably benefit from
this!)

I wanted to write this out to (1) put together learnings I've gleaned from
every previous time I've seen this problem brought up and (2) to point out how
complex of a solution it would take to get this right. I think this would be
way out of the scope of any framework and would be much better suited to be
handled at the OS-level. This "framework-managing framework" could also
potentially be a third-party library, but its functionality would probably
trip up macOS's app checksumming, since frameworks would be removed from the
app bundle.

~~~
dmitrygr
You have just almost exactly described how WinSxS works in windows.

------
azmenak
Are there any other release notes? Surprised to see just 2 (seemingly?) minor
fixes merit a major version bump

~~~
xellisx
[https://www.electronjs.org/blog/cadence-
pause](https://www.electronjs.org/blog/cadence-pause)

~~~
shakna
> Electron 9 stable will target Chromium M83 and be released on May 19, 2020,
> in response to Chromium's announcement of skipping the M82 stable date and
> adjusting the M83 stable date.

This is probably the most important part of that.

------
dkmar
Mostly unrelated, but does anyone know how apple managed to make the macOS
Apple Music app feel like electron?

I imagine that they didn’t actually use electron, but the app feels pretty far
from native imo

~~~
OkGoDoIt
Isn’t it built on their iOS application framework that lets you also compile
for macOS?

~~~
dkmar
I remember reading speculation about that as well. After some googling, it
appears only speculation that the Music app would be built using
Marzipan/Catalyst.

9to5mac writes in a correcting update that “We’ve now learned that the code
for the new Music app for macOS will be based on iTunes, not iOS”.

[https://9to5mac.com/2019/04/10/macos-10-15-itunes-
standalone...](https://9to5mac.com/2019/04/10/macos-10-15-itunes-standalone-
apps/)

------
ge96
So far I really like using Electron. Granted I am not developing anything
extreme but it's really cool, I build my reactjs project then package my
electron app and boom it works. Recently tried the transparent/frameless
window that was pretty cool.

------
vidanay
I have a strong suspicion that this is going to be related to an announcement
of some kind from Microsoft tomorrow during Build. I anticipate further
definition of their cross platform Blazor/Electron roadmap.

------
AnonC
It’s perhaps due to my subconscious dislike of Electron that I read the title
as “Electron 0.9” and for a brief moment wondered what a 1.0 release would
look like.

On performance, the release notes state that there’s an improvement on Linux
(I don’t understand the nuances of that). Are there any contenders to Electron
(upcoming or available) that focus on better power consumption and lower
memory usage?

