Electron 30.0.0 | Hacker News Reader

Electron 30.0.0

electronjs.org

84 pointsaragonite20 comments

Open articleView on HN

> Electron 30.0.0 has been released! It includes upgrades to Chromium 124.0.6367.49

Chromium 124 broke support for Wayland. I've had to downgrade to 123 to get it working again.

Does it mean all apps upgrading to Electron 30 will also break?

https://issues.chromium.org/issues/329678163

Does electron explicitly use Wayland ozone? The default setting still uses x11 and wouldn't be affected.

Huh, I wonder if this is why YouTube videos are just white rectangles on my VM. I had to just turn off hardware acceleration in chromium's settings.

Huh, so this must be why chromium has been showing as a 100% transparent box with 90's style mouse cursor glitching the past while.

Not directly related, but compared with the event hell that UI development was twenty years ago, something like Vue.js (or React, but I haven’t used React) is a pleasure to work with. So it kind of makes sense to have something like electronjs that bridges blood-and-sweat-and-tears Javascript framework achievements with the world of desktop development.

your only problem with events is you dont know how to write code that remains simple

react and view frameworks arent the solution to that problem. react isnt even reactive - you still have to deal with event -> repaint.

react only tried to obscure that into a constraint language instead while actually hamstringing you and pushing the complexity elsewhere

events are here to stay and that's a good thing. these reactive frameworks borne out of an attempt to avoid events or complexity don't eliminate events or complexity - they make everything into an event or a necessarily complex structure in their attempt at pathological avoidance. the solution is factoring and proper honesty in your semantic names. but most people would rather blame their (very ample) tools than their skill or laziness or apathy.

i will say async/await is a big help for humans but synchronous code vs asynch as you may know is not the problem at hand here.

> your only problem with events is you dont know how to write code that remains simple

Yes, it's the "only" problem. All the higher level languages, frameworks, programming paradigms are trying to tackle this problem.

that's not even true, but I hate to break it to you, but literally every generation of language involves handling events unless you get into constraint systems which, as I mention, are for people who dont want to use the greater capability of the underlying generation.

wish people would be honest. it's obviously true that not every framework is trying to be avoidant about their lack of program skills. Some of them are actually useful. where I draw the line is forcing all of your application code to conform to a poorly thought out, half baked solution to reactive data flow, which doesn't even solve that particular problem and leaves you having to handle events anyway.

Thanks for the downvoted tho.

Are people using frameworks to avoid writing event handlers?? I use them to avoid having to manually sync UI state with data structures.

it's the same thing. and you still have to manually sync to the exact same degree using these frameworks or not. state setting is part of the von neumann architecture itself so it appears directly in all programming languages you use. so the problem you say you're using them to solve isn't the problem.

With Vue, I add an element to a list.

With vanilla JS, I would have to add the item to the list, then get the parent element, then create a div containing a bunch of hardcoded stuff, give it an id, keep track of that id, insert the item, then when I remove the item I would have to remove the item from the list.

That could double the amount of cod e needed in most stuff I do.

Vue is vanilla JS - it is a construct of vanilla JS - so it is not what I'm talking about when we talk about generations of languages etc. You still interact with it procedurally or imperatively.

Overall, Vue is honest. React is decidedly not.

I don't have any direct experience with React, but it does seem to be overwhelmingly popular. I assume the devs making insanely complicated stuff at fortune 500

that has nothing to do with it. There are a ton of React implementations, some by third parties, that are not complex. React has also changed majorly multiple times. I don't know how experienced you are, but that should tell you something (bad). It means they don't know what it really is and what they're building. That's another way of saying they don't know what they're doing. unless by complex, you mean that they're good at scamming people. Because that's pretty much what the company that made it is all about, in case you didn't notice.

Excessive breaking changes on a short time do seem like a pretty bad indicator of quality.

It's not a framework I would use by choice, I've been working with Vue for many years, and I've also done some minor Lit and Svelte work.

But it does seem like it's still very widely used, so I assume there must be something about it people really like.

At the very least, the ecosystem and legacy stuff seems like enough to justify using it on some projects, although Vue seems to have caught up.

> But it does seem like it's still very widely used, so I assume there must be something about it people really like.

this is very dangerous and flawed reasoning. There are many examples of where this goes horribly wrong. One of the nice ones is something called normalcy bias. but hey, let's just vote to murder Socrates again because he acknowledged that he was intentionally triggering us as an act of love.

Oops... this comment got cut off somehow.

I assume all the devs at the large companies know what they're doing with react, since I rarely hear that much complaining, so I suppose it's well suited for very large projects.

naive or crazy- I'll let you choose :p

Was Delphi really that bad?

I preferred the native Windows API[^1] from the point of view of organization. In theory, you could use it to design the data flow in your application in whichever way you wanted. And yes, the operating word is "design", meaning that you needed to be decent at architecting software. And this was before .Net and before many C++ facilities that would make life easier (e.g., std::shared_ptr, or even boost::shared_ptr), when making a large scale application in C/C++ required some serious chops I was too young to have.

[^1]: https://learn.microsoft.com/en-us/windows/win32/winmsg/using...

Reply on news.ycombinator.com