321–330 of 435 posts
Earlier quoted context omitted.
Right now, the various Electron apps I have running: 1Password, 155mb Discord, 441mb Element: 38.7mb Signal: 91mb Slack: 46.2mb A few higher but a couple that are lower...
How are you measuring this? Slack on my Mac is 325 MiB on disk (probably because it is a universal binary). A freshly-started Slack uses 461MiB RAM for all it's processes (usually getting worse when it has been running for a while).
Earlier quoted context omitted.
That's actually not true in general, tell me how to compile Proxy and regex lookarounds to ES5 or whatever version that doesn't support these features. In fact tell me how to polyfill these features in any way at all.
There's a proxy polyfill. And if you really wanted there's at least one pcre2 wasm build you could wrap to make a polyfill, lol. Barely anyone uses lookahead/lookbehind even in pcre, though.
> The polyfill supports just a limited number of proxy 'traps'. It also works by calling seal on the object passed to Proxy. This means that the properties you want to proxy must be known at creation time.
i.e. that's not a polyfill for Proxy. It's a polyfill for a subset of the thing, maybe that's useful for somebody, but it's useless for the use cases I had for Proxy so far.
Shipping an entire regex engine with your app: right, that's the only way to do something like that. Not that that's actually the same thing though, I can't just load this and use lookarounds as normal, i.e. it's not a polyfill.
For all practical purposes these features are not polyfillable. If your idea of a polyfill includes not actually polyfilling the entire thing or shipping an entire engine with your app then sure, anything is polyfillable, you could even run Java in the browser.
Earlier quoted context omitted.
HTML and CSS, while not perfect, are still the best tools I've found to create a pleasant UI. Other libraries like Qt do work , but it's more difficult to get things looking exactly how you want them to look.
It is definitely slightly subjective, but come on. God damn winforms were more productive than HTML+CSS hooks you have to go through. In sane frameworks you have proper layouting (not some third party css library with ton of boilerplate to do something like vbox/hbox) and easy customizability through inheritance (eg. try to create a datepicker in HTML.)
WPF has amazing layouts.
CSS is irritating as hell. Even modern CSS, justify-content, justify-items, seriously?
Flex has so many weird edge cases it is overwhelming. I have used flex type systems in other frameworks that worked 10x better, while Flexbox is way better than what existed before on the web, it is still and endless source of frustration.
And yes, Winforms is 100x more productive than HTML. Awhile back I designed a fully functioning UI in Winforms to get an idea what I wanted my website to look like. I hadn't used Winforms in years. Took me less than a day to get a UI up and running with data binding to my backend and all the features implemented.
TWO MONTHS of web dev later I had the same thing working in a browser.
Now the browser was styled, and responsive, sure. But 2 months vs 6 hours. The loss of productivity there is insane.
Earlier quoted context omitted.
By this logic requiring web devs to write ES3 code should be acceptable too. The platform changed significantly, improved significantly, in the past few years, some of these major advancements can't be ignored just because a browser doesn't implement them.
What advancements do you have in mind?
Earlier quoted context omitted.
Back in the day people coded lightweight because it wouldn't run otherwise, and speed mattered in single core sub-GHz CPUs. We don't have that same constraint today, how do we get people to write more efficient code?
Who says using a ton of RAM isn't efficient? Unless your system OOMs what's the downside of having a bunch of allocated memory? Especially if it isn't even paged in.
Several reasons why this principle doesn't apply in this specific (Electron) situation:
(1) Every single Electron/webtech application I've used hasn't just consumed tons of RAM, but also had a noticeable CPU (-> battery & performance) impact.
(2) Most webtech apps I've seen have had memory consumption in the 200-400 MB range - which isn't a problem on my 16 GB desktop, but is a problem on my 4 GB RAM laptop. People have less RAM than you think, and want to run more applications than just yours. Which is better: to be able to run Spotify, Discord, Slack, Matrix, Obsidian, your web browser and a video game all at once, or to have to manually open and close applications when you OOM?
That is - wasting 200 MB of RAM isn't bad if your available RAM is far in excess of 200 MB. For most people, it isn't. If Electron apps each used only 5 MB more than necessary, you would see virtually no complaints at all.
(3) Inefficiency is making bad use of available resources. Not only are chat applications like Slack and Discord not intrinsically difficult problems, but the very existence of third-party clients like Ripcord[1] show that these applications are making extremely poor use of the resources given.
Earlier quoted context omitted.
> Under high memory pressure Just to again note that just because a program says it's using N MB of RAM doesn't mean that all of that RAM is actually paged in. Every thread you execute has an 8+MB stack but most of it won't get allocated for the majority of programs. > we start digging into swap, and at that point, the UI is starting to significantly chug. Only if you're constantly swapping in and out of swap. Just p…
>Only if you're constantly swapping in and out of swap. Which, in the experience I just gave, is what's happening. System memory at some high 90s percent utilization, swap usage creeping up, kswapd with a ton of CPU usage, and worst of all, UI chugging . If it wasn't 'actual' memory usage, why does dropping caches, instantly freeing up some amount of memory, restore responsiveness? I've tried operating swapless befor…
Earlier quoted context omitted.
I guess but compatibility issues on the web, while they existe, are pretty discrete these days. Browser monoculture is exceedingly worse, both practically and from a business perspective, in my opinion.
As someone who uses Safari on Mac, I can say that compatibility issues are a big deal. Granted many of the issues are simply from sites checking for Chrome and telling everything else to f--- off. I've even seen a site fail to run on (chromium) Edge because it really wanted Chrome. However, real compatibility issues are a thing as well. That said, I hate electron. I hate that I have to run 4-5 instances of chrome on…
Earlier quoted context omitted.
We built our product for the web. People wanted our product as a desktop app. So we wrapped it in Electron and now we have 3 desktop apps. People wanted our product as a mobile app. So we wrapped it in Capacitor and now we have two mobile apps. There are just two of us building this product.
What prevents you from using Qt to do almost exactly the same thing?
I have a hard time understanding why platforms like electron are so popular. The predictions from Gary Bernhardt seem to really be true, in the future everything will be javascript. I wonder if somebody actually tried to make an OS that only has a browser, that's what Chrome OS actually is, after all.
Aside from the improvements to project timelines, Electron and similar products are popular because they improve the developer experience, and in 2022 the developer experience is what matters the most to many software companies (yes, in many cases ahead of the customer experience). DX directly drives engagement and retention, and good developers are hard to find (and keep!). And like it or not, there are more and mor…
This is what happens when you keep lowering the bar, and more and more developers can do less and less.
I used this a bit, it was really great. Writing a Rust backend & exposing it to TypeScript was really slick! There was one issue I ran into that made me think about jumping to Electron mid project, but I can't remember what it was now, but I think it was something like making my app bleed the entire MacOS window while still being moveable. The other downside is you're going to be tempted to go down the rabbit hole an…