Electron 9.0
github.com
github.com
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
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.
Also, Eclipse and Jet Brains software feel more similar to each other and now that you mentioned Java, that makes sense.
Is swing poorly optimized, is it due to being in Java?
I'm not a UI dev and have not thought about it much.
Though, when done right, it feels fairly close to native. I earn my pay working with IDEA and if you turn off the plugins you don't need its actually quite snappy where you would reasonably expect it to be. I would bet it takes far less optimization to get there than an equivalent Electron application
Lint/hints taking forever to update after code editing, autocomplete popup takes a second to show, etc. This depends on codebase naturally but in my experience for the cases where VS Code works well (mostly typescript) on the same codebase and same PC it's much more responsive than IDEA tools or Visual Studio (and I'm running this on a i9 MBP with 32GB ram so not a weak HW thing).
I type on a 60hz monitor and I'm not particularly sensitive to that kind of latency (this is where I consider VS Code good enough)
I mean sure, faster is better, but door unlock speed is probably not the problem that makes people think a car is “slow”.
If the feature becomes on par with IntelliJ, everyone would jump ship. But not today.
Aren't browsers native apps? Edit: Chrome on windows is just as native an app as MS Word on windows, so that "feel" may have nothing to do with the tech it was built on, but a native vs browser mindset that even blinds you to the fact that all mainstream browsers are actually very native apps, regardless of the "feeling" they give you.
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.
Any half-decent dev is aware that VSCode would be slightly better if it was a native app. Any half-decent dev is also aware that doing so with cross-platform support would be a humongous PITA.
The first time I experienced such a feeling was when Visual Studio .NET came out. Compared to the previous version, Visual Studio 6, the dialogs and wizards in VS.NET gave me a "web-like" feeling. I guess it was one of the first attemps to use the web technologies to make a desktop app. Along with the Active Desktop feature, they were truly ahead of time.
However, that doesn't mean I loved them. VS.NET was slow as hell and I believe it was one of the reasons why VS6 lasted for so long.
VS Code is also not an outlier for Electron apps, as most of them are a lot jankier, IMO.
And we're saying that people who use Catalina are expecting a gold-standard, performant experience? Do we use the same Catalina? Because it represents a major regression in the macOS line.
Maybe we're long overdue for a paradigm shift.
What are you talking about? That has never happened.
They posted this blog post [1] on July 22, 2019 and you probably misunderstood their point.
They did not rewrite the application to build on native libraries, they simply redesigned the architecture of their UI logic to draw web components only when strictly necessary, sharing states between workspaces and stuff like that, but it is —as of today May 19, 2020— still 100% a web application running on top of Electron. They recently announced another visual rewrite [2] on March 18, 2020 which also resulted in the same web application running on top of Electron, no changes in that part whatsoever.
[1] https://slack.engineering/rebuilding-slack-on-the-desktop-30...
Perhaps this thread could discuss the v9.0.0 release of Electron instead?
Whereas, a UI framework such as Bulma is spun up by a bunch of people who are not as well funded: https://bulma.io/
The broader point is the one I already made: this isn't new. None of this is. Going over the same points every time there's any post about Electron is pretty tiresome.
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.
Yeah, and web UI design languages and the frameworks implementing them like Material Design and Fluent UI have neither research nor deep-pockets vendors behind them.
One can't help but think, maybe web stack makes it the easiest to build good looking apps that are responsive
The web stack is the easiest to hire for.
The web stack is the easiest to deploy to.
The web stack has the most inertia, so its substantial and glaring flaws actually get addressed, whereas other GUI stacks change at a much slower pace (for better or worse).
So I’m not sure this arguments outweighs the cost of having to maintain different native apps.
What I'm getting to is; if people wanted something better, something better would've come along already. Most developers are shielded by user ignorance, if users knew what happens behind the scenes at most banks, they wouldn't want to bank with them anymore. Same goes for almost every software system.
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.
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.
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...
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.
It's death by a thousand cuts. You're probably not going to switch your MBP from 8GB to 16GB because of spotify/slack alone, but if you have four electron apps using 500MB each, you're missing a quarter of your memory. That may very well push you to get the option 16GB (+$100).
But it's true, he obviously doesn't care about the performance of his computer. Why should he, it's not his job to think about such things.
In your opinion what do all the other companies have to gain with the added cost required to reach the same outcome?
Even for big companies it's hard to organize multiple projects to be on the same level, especially if we are talking about some more arcane platforms where you have a hard time to find people with enough experience.
Of course, downside there is you now need to handle cross-browser compatibility issues (particularly Internet Explorer on Windows)
- 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.
On Windows, if you use an OS WebView, you'll have to support IE11 on Windows 7. On Windows 10, you'll get whatever random version of Edge was installed, or the new Chromium-based Edge.
On macOS, you'll have to support whatever version of Safari was installed on the user's Mac, which is better than IE11, but it could still be years out of date.
You might say, "Who cares? I have to support old browsers on my website, too" but this is way worse, forcing you to support browser versions you rarely see on the web. Windows 7 users typically just install the latest Chrome/Firefox and run that rather than surfing the web in IE11, but when you rely on the OS-bundled browser, all of your Win7 users will be on IE11. Your IE11 support can't be an "acceptable fallback"; it's the only/primary experience.
With Electron, you can ensure that your app will use Chromium; the exact version of Chromium you provided in your installer.
FWIW, Microsoft plans to ship a new "WebView 2" that will let you provide your own Chromium or depend on the latest Edge Chromium, with support all the way back to Windows 7. https://docs.microsoft.com/en-us/microsoft-edge/webview2/
That's cool for Windows, but macOS is still just gonna give you whatever version of Safari the user has installed, and if you want Linux support, you really have no better option than to ship a browser runtime like Electron.
But, at that point, if you've shipped an Electron app for macOS and Linux, maybe you just wanna ship an Electron app for Windows and call it a day?
They've already gone fairly far in integrating PWAs with the new Edgeium, so we'll see where this goes. (Your installed PWAs appear in the control panel for uninstallation, for example, which even Chrome doesn't do yet.)
Electron at the moment is just not stable enough for this IMHO. You need to have at least a certainty of that your app would be runnnable for 5-10 years without demand for updates from you, before a developer should seriously consider this.
Though, from a user-perspective this of course is desirable. Thouhg, how big is the overhead even that could be reduced that way?
This is probably the most important part of that.
For more info on our release cadence: https://www.electronjs.org/blog/12-week-cadence
Also there are some NPM packages that have to create builds for specific versions of Electron, and those builds come out after Electron does, so I'm always 1 or 2 versions behind on Electron which leads into dependency hell situations.
Trying to stay up to date is exhausting.
update: they arrived
I imagine that they didn’t actually use electron, but the app feels pretty far from native imo
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...
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?