8 ms·
Electron 9.0
- azmenak 6y agoAre there any other release notes? Surprised to see just 2 (seemingly?) minor fixes merit a major version bump
- rodw 6y agoNormally there is a detailed list here - https://www.electronjs.org/releases/stable https://www.electronjs.org/releases/stable - but right now there is no mention of v9 on that page.
- xellisx 6y agohttps://www.electronjs.org/blog/cadence-pause https://www.electronjs.org/blog/cadence-pause
- shakna 6y ago> 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.
- untog 6y agoElectron bumps their major version number when they move to a new major version of Chromium. Which is what they've done here.
- dsteinman 6y agoThis is turning out to be a bad decision because there's been 5 major version bumps in the past year, yet the functionality in Electron hasn't materially changed very much, mostly bug fixes and minor changes.
- marshallofsound 6y agoInterested in why you think this was a bad decision. For a multitude of reasons surrounding security, performance and wanting the Latest And Greatest JS features we want to stay as close to upstream Chromium as possible. Curious what you feel the negative impact of major-versioning is? For more info on our release cadence: https://www.electronjs.org/blog/12-week-cadence https://www.electronjs.org/blog/12-week-cadence
- ec109685 6y agoWith semantic versioning, you can tell the magnitude of the release (and if backwards compatibility is broken) by looking at the major version number.
- dsteinman 6y agoThe Electron version numbers are essentially meaningless now. I have no idea what even changed between Electron 4 and 8, the changelogs are all just bug fixes that didn't necessitate so many major version releases. 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.
- hombre_fatal 6y agoEvery new version gives HNers a new opportunity to circlejerk about how bad Javascript and Electron are.
- nornagon 6y agoThere was a hiccup in our release process, the updated release notes will be coming soon! update: they arrived
- fermienrico 6y agoI 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.
- cageface 6y agoMatching native UI with non-native toolkits is extremely difficult. But the success of so many electron apps suggests that in many cases this doesn't matter that much.
- fermienrico 6y agoI don't know - success of x and some property of x can be orthogonal. It probably is orthogonal in the case of electron apps. The main reason for their popularity is because they are easy to develop in cross-platform way. Doesn't mean that "x property doesn't matter".
- cageface 6y agoUsers choose to use them anyway. So obviously being platform native matters less than other considerations.
- DenseComet 6y agoAre 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.
- rvz 6y agoAFAICT, This has been discussed in the past [0] and Electron doesn't have a stable runtime for developers to program against unlike the JRE, etc. You could try to do that at least on macOS, by moving the Electron.framework library in /Library/Frameworks and see if it will run. Some will, some won't. I won't be surprised if it doesn't work. [0] https://github.com/electron/electron/issues/673 https://github.com/electron/electron/issues/673
- saagarjha 6y agoI am sure that codesigning will kill this idea very quickly.
- gen220 6y agoI wouldn’t be super surprised if this was on the Chromium / Chrome OS roadmap. I might vaguely remember hear something about this a year or two ago in a podcast with a chromium developer, but I could be wrong :P
- untog 6y agoI've never used it, but DeskGap uses native OS webviews: https://deskgap.com/ https://deskgap.com/ Of course, downside there is you now need to handle cross-browser compatibility issues (particularly Internet Explorer on Windows)
- szhu 6y agoI 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.
- untog 6y agoYou 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 6y agoNative apps have UI elements that have tremendous research behind it by operating system vendors with deep pockets: https://developer.apple.com/design/human-interface-guidelines/macos/overview/themes/ https://developer.apple.com/design/human-interface-guideline... 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/
- untog 6y agoCounterpoint: Google's Material Design framework has tremendous research behind it, and has a variety of both native and web implementations. 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.
- stonogo 6y agoProblems do not stop being problems merely because you tire of hearing about them.
- locusm 6y agoAm 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 6y agoThat 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.
- cageface 6y agoThe only native music streaming app I've tried is Apple Music, which is worse than Spotify, Idagio and Tidal in many ways. It's certainly slower and less responsive. This might be for legacy reasons but if even Apple with limitless resources can't be bothered to build a new native client on their own stack why should we expect companies a small fraction of their size to do it?
- saagarjha 6y agoApple Music on desktop is a poor web view wrapper with mildly-offensive "native" UI.
- cageface 6y agoI didn't realize the new one was a web wrapper. I guess the point still stands though that even Apple can't be bothered to build a truly native app on their own platform.
- harrygeez 6y agoOne trend I noticed is many large software these days: Office, Adobe Suite, Spotify, Steam, Apple Store/iTunes/etc are all using web technology to build at least, their frontends. One can't help but think, maybe web stack makes it the easiest to build good looking apps that are responsive
- vidanay 6y agoI 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.
- dkmar 6y agoMostly 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 6y agoIsn’t it built on their iOS application framework that lets you also compile for macOS?
- dkmar 6y agoI 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-apps/ https://9to5mac.com/2019/04/10/macos-10-15-itunes-standalone...
- scarlac 6y agoIf you sniff the network traffic you’ll find why: it essentially is a hybrid html and native app. All pages of the App Store are set up in XML and loaded server side, hardly ever cached. Just like <select> in HTML iTunes uses similar structure to instruct and deliver native or semi-native components. It’s a big web page. And it’s slower than Safari. That’s why.
- AnonC 6y agoIt’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?
- ge96 6y agoSo 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.