Hacker News Reader

Hacker News

Comment by forgotmyoldacc | Hacker News Reader

Full thread

forgotmyoldacc

If anyone wants to know how it works:

> [leverages] WebKit on macOS, WebView2 on Windows and WebKitGTK on Linux.

So cross-platform compatibility isn't guaranteed, unlike Electron.

https://github.com/tauri-apps/tauri

View on HN

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.

I don't know about that, one data point: an ES2018 feature, regex lookarounds, is still not implemented in Safari. And the JS engine is the thing that's the most compatible across browsers, nowhere near the level of incompatibility of the rendering engine for example.

Ignore stuff that was added to HTML, CSS, and JS for last 4-5 years. You'll still have a pretty solid? GUI platform, likely more capable and accessible than Qt or GTK or AWT.

With the usual compiler / transpiler stack, you'll have a nice, fast-to-market, non-esoteric development environment. All without the need to ship 100MB binaries.

Sorry but requiring web devs to ignore the last 4~5 years of progress is just unacceptable.

Not that that would fix the situation, there are still rendering inconsistencies between browsers when using stuff like margins floats and tables.

But you won't be developing a web app, you'd be developing a desktop app, much like with React Native.

Having web developers learn C++ and Qt instead would be much more unacceptable.

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.

Nope, you can compile code back to whatever ECMAScript version you like with tools like Babel or TypeScript. So the devs don’t even notice that they’re compiling to 4-5 year old ES.

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.

Proxy polyfill: assuming you are referring to this [0], since I haven't seen anything else like this, then I'll paste here what the readme says:

> 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.

[0]: https://github.com/GoogleChrome/proxy-polyfill

>Shipping an entire regex engine with your app: right, that's the only way to do something like that.

You mean like shipping an entire 100+ MB browser and rendering engine with your app?

Electron does not weigh 300+ MB for starter, and one means basically statically linking your app so that it ships with its own dependencies and works more consistently, while the other means shipping a language because the one you have to use is not implemented properly by the platform, pretty different things when you look at them. I'll give you though that in both cases you are shipping a big engine with your app, so it kinda sounds like the same thing.

What advancements do you have in mind?

A lot got released in the past 4/5 years. I don't have a list of favorites off the top of my mind. Many useful things got shipped though.

Then do as I: develop in Firefox and if it works there (and isn't a PWA where maybe you get in trouble with Safari?) then it works everywhere.

Less testing, less bugs. Whats not to like?

Contrast to Chrome first developers who often get caught by cross browsers incompatibilities just like they did back in the days when they were IE first developers : )

Unless I'm missing something that doesn't fixes the issue, the problem is symmetrical, browser A is different than browser B, so browser B is different than browser A, testing in either of them doesn't guarantee a correct output in both of them.

Chrome - like IE before it - has a number of "features" that only work/ed in Chrome/IE.

Writing for a standards compliant browser like Firefox makes your code more well defined today just as it did back then because you won't get away with the same sloppyness. (This also makes you catch and fix problems in early iterations over the problem instead of after QA calls to complain so it saves you time and context switching too and if you are good you might look like a cross browser superhero almost for free ;-)

Earlier on not every basic thing was supported everywhere, many people here will remember the ACID tests. Younger devs won't remember them as we stopped talking about them after every browser became compliant. Today every mainstream browser has comprehensive test suites to cover everything we need from CSS I think.

Testing on ~~Chrome~~ Firefox would save you from accidentally using Chrome-only features, but that's only part of the problem, caniuse.com kinda works better for that as you get data about other browsers too.

>Testing on Chrome would save you from accidentally using Chrome-only features, but that's only part of the problem,

How?

> caniuse.com kinda works better for that as you get data about other browsers too.

caniuse.com is nice but unlike using a standards compliant browser it requires you to be mentally alert and aware of it.

Using a standards compliant browser means you'll see the result of sloppy css immediately on the screen.

>>Testing on Chrome would save you from accidentally using Chrome-only features, but that's only part of the problem, >How?

Sorry I meant "Firefox" and "Chrome-only" there.

In general though it's not like Firefox is spec compliant and others aren't, pretty much every browser works a little different in some areas. Just for the sake of saying something verifiable: no browser is spec compliant because the spec mandates a precise maximum length for strings and each main browser has a different, arbitrary (= I have the RAM, they just won't let me use it), lower limit on that.

I do this too, but still run into issues with Safari. Luckily, later Safari 14 versions and Safari 15 are not too bad.

> Contrast to Chrome first developers who often get caught by cross browsers incompatibilities just like they did back in the days when they were IE first developers : )

I'm not entirely sure how I feel about this statement (and comparison to IE). If anything, Safari is "the new IE" rather than Chrome.

MOST (hopefully the nitpickers pick up the caps lock) stuff in Chrome are drafts or standards.

Sure, Google pioneered/championed some of them, but that's kinda irrelevant if developers voted for those features. There's very little Chrome-specific stuff.

Also, other browsers have vendor specific stuff in them too, yet people rarely fling shit in their direction?

FWIW I also mostly use Firefox for dev because I prefer how some devtool features are designed/implemented.

Most of my cross browser issues in FF were "brief" in the senses that they were bugs that got fixed eventual.

> I'm not entirely sure how I feel about this statement (and comparison to IE). If anything, Safari is "the new IE" rather than Chrome.

Some people who either don't know history or willfully ignores it keeps claiming that Safari is the new IE, at one point one even made a webside out of it.

Don't fall for it.

Chrome is the new IE:

- technologically advanced? Check!

- implement a number of things without asking or waiting for consensus? Check!

- will be abandoned as soon as they have crushed every competitor? Well, it is produced by the worlds most famous company when it comes to killing its own software.

I can't believe you seriously just suggested Google is going to abandon Chrome.

Next up, Microsoft is going to abandon Word. Also, Facebook is going to abandon Facebook. This is why no one takes these conversations seriously. All vitriol, no substance.

IE still had released, but it stopped moving forward after 6 because there was no longer a good reason for ms to invest.

I doubt google would spend much on chrome if no other browser were popular.

But chromium is opensource. Even if google stop devoting to chrome, we can develop it. In fact, I think Mozilla should turn to chromium too like Microsoft, just be aware of keeping the licence open.

Dear Mozilla:

Fork Chromium.

Love, Your Old Users

I wouldn’t be shocked to see MS abandon Word or Facebook (erm Meta) abandon Facebook in the same sense Google would abandon Chrome.

Sure, some piece of software will have that name, but it won’t be aggressively developed like MS abandoned IE a few times.

I also won’t be shocked if Word or Facebook are like Edge where it’s a new different thing with an old name.

There’s plenty of weird cruft in Firefox’s ~30 year old codebase that causes bugs and unspecified behavior. For example, Firefox’s ContentEditable code deletes things “backwards” compared to all other browsers and operating systems (bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1735608) - this behavior isn’t standardized in any spec, and Firefox is different from other browsers.

There are plenty of gotchas in layout/rendering as well, where either the standard is under specified, or Firefox has some small bugs. Maybe Chrome has many-chrome only APIs, but the developer will always need to test in Chrome and iOS Safari 13 (or whatever your oldest supported iOS version is).

Chrome and iOS are where the users are, and a good website or app should be usable and beautiful for everyone.

Developing UI components based on ContentEditable is trial and error, with a lot of code held together by cross-browser integration tests where you always have to pray that a browser upgrade doesn't brake something new in a subtle and surprising way...

1/5, would not recommend. (But sometimes there's no way around it.)

> There’s plenty of weird cruft in Firefox’s ~30 year old codebase that causes bugs and unspecified behavior.

Just wondering where you're getting "30 years" from?

That asked, a Chrome-shaped monoculture doesn't help anybody. We need more competing implementations, not less. Anyone feel like collaborating on such?

Are you casually asking if anyone wants to start writing a rendering engine?

Netscape was founded in 1994, Firefox is derived from Gecko (1997) layout code code open-sourced from Netscape in 1998. See https://en.m.wikipedia.org/wiki/Gecko_(software) for some background. I was thinking 1994 when I wrote the comment, but it’s closer to ~25 years if you reckon from Gecko’s birth year of 1997.

This is absolutely not true. I wrote a simple flexbox layout in Firefox last year and it was majorly broken when I tried to test it on Chrome, since Firefox and Chrome disagreed on how to compute "min-width" for inline images and other replaced content. In this case, my layout worked in Firefox, but Chrome was the browser that was following the CSS standard correctly, and my code was broken.

"requiring web devs to ignore the last 4~5 years of progress is just unacceptable."

But this it not for "web devs", but for general UI development on desktops. Given some conventions there are decades old 4-5 years does not sound very ancient in comparison. And for desktop you probably want to trade bleeding edge hotness for tested and tried methods anyway. 4-5 years on desktop is a very brief span of time.

> Sorry but requiring web devs to ignore the last 4~5 years of progress is just unacceptable.

No it's not. "Web dev" is one of the things in my toolbox and I still clicked on this well-knowing it was likely not truly cross-platform and keeping up with bleeding-edge features.

Truth is all development is about tradeoffs and Electron is one heck of a blob to ship to users... in a lot of applications a lighter weight artifact may be desirable where the trade off of the last 4-5 years of browser advancements may be perfectly OK.

Is it unacceptable? Sure - if your application needs features out of the last 4-5 years of browser advancements... but that's not most applications. If you need a bleeding-edge solution that's truly cross-platform then Electron clearly still is your choice as you're just shipping around a fancied up Chromium.

The last 4-5 years of "progress" have been pretty unacceptable.

Safari not supporting lookbehinds is a bigger PitA than I ever imagined it would be.

Right? And that's not the kind of feature that you can just polyfill back in. I don't understand how it's possible that that's not implemented yet.

For language issues I assume using Babel, which in my opinion is not a big deal if you’re already making an app.

Render-wise, browsers are pretty uniform these days. I experience very few problems in this regard, and my app Pony runs out of the same web codebase on all platforms (iOS, Android, web). The worst offender is Safari, but it’s not that bad. The potential gains from something like Tauri (and I plan to try Tauri for Pony desktop) far exceed the compatibility concerns for me (which I’ve already had to address due to web).

Couldn't you just package your favorite regex library and expose it through a JS function binding in your app?

That's a big "just", but yes in theory that's doable, however:

- The performance you are going to get will be terrible compared to the native implementation.

- Oniguruma, which I think is Ruby's engine, weighs half a megabyte on its own, that's comparable to the core bundle of the app I'm working on. That's a lot to my eyes.

- If you need to use this engine in dependencies that just assume that lookarounds are available then you are going to need to fork every single dependency just to wire it with the regex engine you compiled, super messy.

As a guy who started web development when IE6 was the dominant platform I cannot cherish "browser monoculture" enough.

.clearfix

And now we have display of "flow-root" instead of clearfix.

However the only reason I ever used the clearfix hack was when using float to do layout. I haven’t done that for ages (i.e. since CSS grew to include flexbox and grid). And I only ever use float to—well—float images inside text where the inside display is always inline. So I haven’t ever seen a need for display flow-root in the wild... Although I’m sure it exists.

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 my machine all day long for various different apps instead of the developer checking that their stuff works across the 3 main rendering engines.

Granted many of the issues are simply from sites checking for Chrome and telling everything else to f--- off.

The world has circled back to the bad practices around IE 6! History doesn't repeat, but it sure does rhyme!

To be fair, I hate Safari with a passion. It took until iOS 15 for support for WebAssembly.initiateStreaming and there’s still no support for WebM or Opus on iPhones. Curiously, on platforms where Apple doesn’t mandate a browser engine, Safari is magically able to support codecs that aren’t patent-encumbered…

Just to clarify - WebKit does support Opus, but using their CAF container [1], which is a pain to deal as it requires double the space to store essentially the same encoded audio twice.

[1]: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/A...

Nobody tests on a Mac. If Apple wanted the platform to be supported they could make it much cheaper to test on, but instead they've made developer hostile moves for the last ten years.

Github actions has Mac runners at the same rate as Linux runners, including the free tier (though the free minutes burn faster, as I understand it).

It's a 10x multiplier to run mac on GitHub actions https://docs.github.com/en/billing/managing-billing-for-gith...

You are correct that Safari has major compatibility issues, but incorrect that the problem is simply that developers target Chrome (it happens sometimes, sure). Most things that work in Chrome also work in Firefox, but WebKit is ~10 years behind both Firefox and Chrome because Apple hasn't invested in keeping up to date with web APIs where their competitors have. Hell, even Edge (before it adopted Chromium) was more compatible than Safari.

Personally, I view Safari in 2022 the same way I viewed IE in 2012 - as a backwards browser holding back web development because the company developing it just doesn't care about the web. The compatibility issues aren't as bad, but I have to care about Safari because iOS still won't let any browser use anything other than WebKit, where there was a point where saying "Anyone choosing to use IE11 deserves a bad experience" made a certain amount of sense. No one gets a choice on their iPhone, so Apple makes things harder for web developers, probably because they want them all to be iOS app developers instead.

Personally, I think the last few versions of Safari have caught up a lot.

Safari development does seem to go through spurts, depending on who is working at Apple. Let's not forget that in the past, it's been a major driver of web innovation, particularly in the late 2000s to early 2010s.

Safari is missing features and has its own quirks so I wouldn't say that.

It's much bigger than you think.

If I'm building an electron app, it's because I need native code running in nodejs/V8 as native addons, often in the render process, or I'm using bleeding edge APIs not available on Safari.

This type of framework is simply not an option.

"cross-platform compatibility" isn't guaranteed on the web either, yet somehow "cross-platform compatible" websites exist.

It isn't a problem that's so difficult it requires wrapping a 60Mb runtime around every individual app instance.

Everyone is basically using Chrome or Safari nowadays - so WebKit. Very little incompatibilities to consider compared to writing something that works on different WebView implementations

Luckily, that is not the case. In Germany, FF still has 20% on Desktop and 10% total (and I wonder if those numbers are maybe too low, as FF blocks those trackers by default).

That means that there are about 8 million people using Firefox in Germany.

The world has more than 3 billion internet users

I don't understand why this relative metric matters. Past the size of a small city it just shouldn't matter how many more users the competition have. There are more firefox users today (~200M) than there were total internet users in 1998 (~150M), and surely you would agree that it does not make sense to discard that, any more than it makes sense to discard, say, UK or France from diplomatic relationships because they have ~70M inhabitants while India and China account for almost 3 billion.

Hmm it matters because when everyone basically uses competition, it doesn't matter if a few people use something else

Just because only 17M people live in the Netherlands, does not mean it's OK to block them. Just because people in wheelchairs don't wall, does not mean we don't need to build streets such they can get around too. Just because some people use the Greek script, does not mean ASCII is enough.

It's called accessibility, and it's a very good thing.

You are arguing against a straw man

WebKit, WebKitGTK and WebView2 are all webkit-based too currently. WebView2 was always chromium-based afaict, I think the old trident-based edge had a separate control.

Also, on the web, firefox still exists.

Sorry, I am using Firefox.

WebKit and Blink have many significant differences, especially when it comes to supporting newer features. In terms of incompatibilities they're about as different as Gecko is from Blink, if not more so.

Not sure how familiar you are with the history of browser engines, but Blink and WebKit are definitely more similar than Gecko and Blink.

Gecko comes from the heritage of Netscape. Blink comes from the chain of KHTML > WebKit WebCore. They don't share any points, while Blink probably wouldn't have existed without WebKit.

But yes, today there are differences between WebKit and Blink.

"In terms of incompatibilities they're about as different as Gecko is from Blink, if not more so."

> Not sure how familiar you are with the history of browser engines, but Blink and WebKit are definitely more similar than Gecko and Blink.

I see we interpreted parent poster differently, he wasn't talking about the history of rendering engines, but rather compability with the various web specs. Since Chrome forked WebKit quite a long time ago now and Blink has been reworked quite a bit they have deviated from eachothers implementations. Since everyone is trying to follow an open spec it might be that in certain areas FF and Chrome implement more of the same API's than Safari, which doesn't have anything to do with codebase history.

You might and probably will feel more comfortable in the WebKit codebase if you're a Blink developer or vice versa in comparision to Gecko, but that is if you're writing the engine itself and not pressing the pedals (targeting it).

> as different as Gecko is from Blink

As someone who has been playing with some web dev in early 2000s, that sounds funny. Gecko, WebKit and Blink seem very consistent to me. I remember dealing incompatibilities between IE6 and "standards-compliant" browsers (mainly Firefox/Mozilla Suite back then). And don't get me started on dealing with "classic" Netscape!

`<layer>` tag anyone?

I’ve always felt that engine inconsistencies in electron-alikes are a bit overblown, particularly now with the old IE-based webview out of the picture (modern Windows uses a Blink-based webview). They’re all capable of the basics, and the greatest inconsistencies will be found in newer features. Stick to a slightly older well supported set of features and you’ll be fine.

There are some significant differences between engines when it comes to things like local file access, but that’s what the native component of electron/tauri/etc is there for.

I'm not sure why downvoting is needed. What's said is true: on the web we already have to deal with different browsers and versions. It should be a fact of life for web developers. And things today are still infinitely better than back in the IE 6 days: many modern features work on all major targets. Why do people insist so much on engine consistency for "desktop web apps"?

Most cross compatibility issues have been resolved in browsers. Firefox and Chrome are pretty much at parity, Edge is chrome and Safari is the exception.

Web views are less standardized though and require more finesse.

> Firefox and Chrome are pretty much at parity, Edge is chrome and Safari is the exception.

Firefox and Safari are very much at parity. Chrome ships ~40-70 new "standard" APIs every month or so: https://web-confluence.appspot.com/#!/confluence

In my experience it’s Chrome that does weird things. I write for Safari and it works great in FF. Chrome and Edge will require some tweaking of CSS to make it look correct.

I mean… fair, but is the 60MB runtime the issue?

I really don’t care if my hello world UI is 60MB to download, I care that it consumes 1 GB of my precious ram to run.

How is running js with a rust backend any better than running js with a C++ backend?

I guess your “backend” is rust here, which is nice (because I <3 rust), but tell me this won’t sit there guzzling all the memory it can get it’s hands on for the UI?

Ie. really, do you get meaningful benefits from using this over say, literally just using https://github.com/webview/webview?

One can hope that the code of the engine will be shared across apps in memory, thanks to shared libraries, and that the engine itself will use shared things too, by virtue of being distributed with the OS.

... if you happen to run other browsers and apps using this WebKit / libwebkitgtk / webview.

and that embedded apps won't be obese frontend code with bazillion npm dependencies and a heavy, all too widespread framework, of course.

Hopefully, developers turning to Tauri will have some sensibility to lightness.

The code size is usually epsilon compared to the amounts that the JS heap, DOM, and JIT consume. These are not shareable.

> I really don’t care if my hello world UI is 60MB to download

lot of people cares, they may have a slow connection, must pay per MB and so on.

There is no reason why hello world UI should be 60MB.

I can remember using 56k dialup and downloading ISOs around 650MB.

A 60MB download would have been fine.

Indeed, with the annoying habit of proprietary software to install "Download managers" that download the actual software, I would be happy for just a 60MB runtime for the actual program itself.

I'm not sure you really remember. With 56k dialup, downloading 650MB could easily take days. Downloading 1MB could have taken 3 to 4 minutes.

60MB, even today, is really big when you have to download it while boarding a train or with poor connectivity (even in rich countries, just being in a metallic building is enough for 60MB to be painful to download.

You download desktop apps while boarding a train?

I remember leaving the computer on to download 650MB overnight, which used to be an ISO for an operating system. It was usually finished sometime the next day.

And 60MB would have been a couple of hours, not bad to wait for some software.

It wasn't prohibitive to do this.

Indeed, I seem to be back at square one, as downloading a AAA game for me once again takes about a day.

650,000 kb / 5 kb/s = 36 hours

Add a little line noise for the average 30-70y/o house wiring and you get 43 hours for 33.6 or 50 hours for 28.8. It took running a brand new line in order for me to get 56k. So, the parent comment is accurate.

It was absolutely prohibitive for the average person with a shared line, and the direct comparison to shared line today is a metered connection. Even in the US it can be as much as $30 per gigabyte which would make that 60MB download cost $1.80.

I also remember using 56k dialup, and we paid per minute. A 60 Mb download would take several hours.

While true, you pay the price to download a program once, but the price to run the program, every day.

But you don’t pay RAM usage fees.

Don't give them any ideas.

You would be surprised but that is exactly what you do when you access VMs on clouds.

To be short: if you can make your app less greedy - do it.

In some cultures we have a concept of "engineering conscience" (ru: "инженерная совесть"). Are we loosing all that?

Oh sure, not just VM, but in all rented server instances. But we’re talking about home machines here.

Yes, but this is my point.

https://github.com/tauri-apps/tauri/discussions/3162

> FabianLars, 3 hours ago, Collaborator

> ...for example my somewhat simple app uses ~120MB

> But only ~5MB is the actual tauri/rust process, the rest is WebView2.

So, if 60MB is a large download, surely a simple app using 120MB of ram is pretty outrageous too?

> There is no reason why hello world UI should be 60MB.

Absolutely, but you can't have everything. Fast. Small. Doesn't use any memory. Easy to develop for. Free. Consistent cross platform behaviour.

You can't have them all.

So... the question isn't "is 60MB ok?"

The question is: What do you care about the most? Is it really the download size?

It's not the download size for me.

I’d encourage you to rethink whether the “all” you describe is desirable. I couldn’t care less whether an app is consistent across platforms - in fact I consider that a strict negative since apps should be consistent with the platform on which they are running not with themselves on other platforms.

I don't think that "consistent" always necessarily refers to pixel-perfect equality. When using this term in web dev, most would refer to browser standards as in spacing, layout, JS apis, availability of native elements etc. In this context, consistency is rather the opposite of negative. I don't think anyone really cares about how date picker looks on Firefox vs. on Chrome.

Maybe you are referring to Gtk/Qt vs. win32 etc. with their integrations in the operating system. I agree that they look and feel the best for their respective OS, but eventually require you maintain multiple unrelated codebases. It is understandable and necessary for this approach to die. A middle ground would be best, say, Qt support on all existing platforms. Or more likely, prettier browser defaults for standard elements like lists and tables, with browsers themselves respecting the underlying OS theme. Probably never gonna happen...

I'm not that interested in using lower common denominator software on any platform - for my purposes I am only interested (and willing to pay for) software written to integrate with macOS in a first party manner. That means I want all of the accessibility controls to work, all of the system integration to work and so forth. I'd expect anyone serious about software to want the same on whatever platform they use. Lowest common denominator crap is the thing that needs to die.

Arguably both Slack and Spotify (and Visual Studio?) have reached significant scale with Electron apps - so at the end of the day it seems to be less of an issue for end consumers.

Spotify is built on Chromium Embedded Framework, not Electron. Common misunderstanding.

Lots of things are popular, but that doesn't imply quality. McDonald's does not make the best hamburger in the world.

Per https://github.com/Fournux/tauri-vs-electron it uses just 20 MB of ram on linux.

Why? I guess because webkit-gtk is less ram hungry than blink.

any idea why the memory usage difference on windows are very close but significantly different on linux?

WebView2 is chromium edge. This was the reason that I guessed webkit-gtk uses less ram than chromium.

ah, that makes sense. thanks

It's got better memory stats than electron on the tests I saw..

  > I really don’t care if my hello world UI is 60MB to download,

If you're writing Hello World for fun, then sure. But _I_ won't be using any of your software if it's that bloated. I'm not going to even complain to you about my internet connection or hard drive space or personal preferences. If you are not going to respect my resources as a dev, I will not use your software. Just like I won't ride with a cabbie who curses and cuts off other drivers.

How do you feel about video games that range hundreds of gigabytes?

Games with hundreds of GB are using high poly models and high res textures. The actual code segment of the game is much much less. This isn’t really the same.

Games at that size are not clocking in because of their models and textures. It's from use of lossless, uncompressed audio files, and shipping multiple language files.

The issue is most common on games that release on consoles, but also for ones that want to support older hardware: the audio formats they use are designed to minimize the amount of decompression necessary for play, and so reduce resource requirements in exchange for storage space.

i’ve not yet seen a sound sample above a few 100mb, uncompressed. however it’s quite common to see a source model, or even a cooked down version, can absolutely be above 1gb. sound, except soundtracks (mostly), are also reused whereas models are not usually. couple that with one of your reasons, supporting all possible resolutions (PC games are the big offender here), and i don’t see sound being a huge issue. you can also compress sound while in transit, textures will only compress so much. wavs/PCM compress quite well

I don't play video games, so I have no opinion of them. I actually do play Kerbal Space Program, though I think that it is a few hundred megabytes, certainly not even a single gigabyte.

1.9 GB on disk not including expansions.

https://www.gog.com/game/kerbal_space_program

In that case, I feel that I'm getting a decent experience for the size.

Would you argue the same for a 60 MB Hello, World application?

Depends, if someone presented a hello world example in unreal engine I would expect the binary to be larger than 60MB.

Fair point.

To download the zipped version of https://www.monsterwriter.app/ it needs 100MB. If I build an universal file (Intel and M1) it doubles in size.

I assume this to be a conversion killer. If you have to wait 10 min do download you loose interest in trying it out.

100MB in 10m is 166.7KB/s. I’m gonna go ahead and guess that most people have internet faster than that.

Yeah, and large fraction of the dev appeal of Electron is that a concern that has haunted web development for a quarter of a century is completely out of the picture when you do Electron. You're not even concerned with possible differences between past, present and future versions of the engine because your code runs with exactly the version you bundled.

Sure, if your app is just a faux-native variant of something that is developed for the browser anyways nothing is lost, but if it's an offline first application that just happens to use web tech for UI the difference is huge.

Chrome is the new IE6, and guarantees cross platform compatibility everywhere it uses its own renderer though. (Basically !iOS.) It's a strong reason for choosing to Electron for your "native" app.

Nice IE reference, helping Google to spread ChromeOS is exactly one reason not to package Electron everywhere, besides the bloat to have multiple copies.

Saw a comparison, Electron app size of 138MB Vs Tauri in single digit MB is a big difference though.

Sure, but Neutralino[1] already does this, it's just not Written in Rust™

[1] https://neutralino.js.org/

Does neutralino run on platforms other than a minimal SUSE?

</obligatory physics joke>

This is a feature. It means every process doesn't have its own copy of Chrome.

It might mean more testing for developers, but it's a benefit for users.

Yes, the lazy devs path, helping Google to spread Chrome everywhere.

Does the Chrome engine, embedded within Electron, contain any Chrome features which one could legitimately call into question (such as sync)?

If not, what's wrong with it "spread[ing]" everywhere?

It's hardly lazy dev work. It's a pragmatic approach to developing cross platform apps quickly. Apps that, it might be added, don't have a horrendous UI, which is common with other frameworks.

> If not, what's wrong with it "spread[ing]" everywhere?

Because then it's a monopoly. I'm taking shortcuts but having a single browser engine controlled by a single company means that you rely on that company to define what is tomorrow's web like.

Without this kind of thing happening at times, we might still be using Flash.

Yeah, it had nothing to do with work on open standards like HTML5 and CSS3. (And WebGL for more advanced rendering needs) /s

Electron feels to me a lot like stand-alone flash apps used to feel.

I get that same feeling when I open an program using it; kind of a 'oh...' slight disappointment. I get that it makes sense sometimes for a developer to sacrifice performance and size for ease of development... but as a user, it feels like a loss, a sign the developer will be taking too many shortcuts, or that I just won't like their general design philosophy.

Arguably that's like observing that the same feature works differently in 2+ browsers and blaming web devs for it. It's the job of the browser people to make correct, or at least consistent, platforms.

While part of being a web dev unfortunately is also dealing with this you can't necessarily blame web devs when Safari breaks IndexedDB for the nth time, or when after using ES2018 features like regex lookarounds you discover that Safari still hasn't implemented them (which year are we in now, 2022?).

You may also discover that mobile and desktop browsers work differently in some aspects, not everybody even has the resources to test every single thing in 3+ desktop browsers (which may require at least 1 VM already if you are not developing on macOS, which I think might even be illegal to run in a non-mac hardware, bizarrely) and 3+ mobile browsers (which may require at least one physical device or a macOS VM for the iPhone, and another physical device or another VM for Android, and all these VMs aren't exactly lightweight).

Besides an Electron app doesn't necessarily have to run anywhere else, there's no point in checking compatibility with Gecko when your app never has to run there.

Arguably that's like observing that the same feature works differently in 2+ POSIX OSes and blaming devs for it. It's the job of the OS people to make correct, or at least consistent, platforms.

I'd argue Babel-ing and polyfill-ing the webcompat delta is wiser than shipping chromium

It would be better to use Rust+Servo (no JS, or at least optional) IMO

>(no JS, or at least optional) IMO reply

At this point why not focus on some actual GUI toolokit, like write a Qt clone in Rust, for real world apps we don't need all the CSS and HTML crap, you need simple layout, GUI components and an option WebView you can embed in the app if needed. Probably there is no commercial interest to pay professional developers with real experience to implement this.

People are doing that too. https://sixtyfps.io/ is basically a Qt clone in Rust, actually developed by previous Qt developers.

I don't think "basically a Qt clone" is a fair framing, in both directions. (sixtyfps aims to cover things Qt doesn't, Qt does things sixtyfps doesn't and won't for a long time if at all)

I believe the interest is there, it's just not as easy as it seems: https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021....

egui is a really fantastic Rust GUI toolkit, best I've used in any language

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.

This is obviously a different camps kind of thing, but I don't think you're supposed to make everything look exactly pixel perfect to how you want it, you're supposed to follow the look and feel of the OS with native controls and such.

I understand both, I don't agree with either more than the other.

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.)

Hell even Swing had good layouts decades before CSS caught up with things.

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.

CSS has too much old crap, how many ways you can center a thing? How many ways you can horizontal align some stuff? There should be only 1 way and that way should not have hacks like use negative margins.

What a Qt or other similar frameworks gives you is consistency, all components in all apps will look and work the same (with the exception of customized ones). This means you can focus on UX and not on bad design. My experience is that some bad designer will force his opinion on the users, will force his preferred fonts, font sizes and font colors on the users(making text hard to read), will disabgle text selection for some weird reason, will fuck with the scrollbars because the native ones are ugly etc.

For a working app that is not a music player you don't need the "power" of css, say you seen video games have a small Launcher/config window that hase buttons,drop downs, checkboxes , I noticed those use Qt or Windows Forms. I am also noticing that modding tools , open source tools (that are not GNOME) also focus on functionality and you will not see buttons with round corners, fancy fonts and animated borders.

IMO Electron advantage is not his the "powerfull"css and html and it is that you can reuse the existing node ecosystem and existing web developers and the alternatives are also lacking for higher level languages (GTK is shit IMO)

> There should be only 1 way and that way should not have hacks like use negative margins.

There is: flexbox and grid. All kinds of alignment can be done with basically a one-liner in both layout systems, without any hacks.

>There is: flexbox and grid. All kinds of alignment can be done with basically a one-liner in both layout systems, without any hacks.

You missed the part with "there should be ONLY 1 way". I know about flex and grid, this are new and thanks the gods we finally we have something decent (not good).

Flexbox is great I wish to magically remove or magically fix all the code that does not use it and instead uses "float" or other shit.

You would say "don't use the other old shit" but my point was that we need a GUI framework that does not have 1 million lines of code for supporting this old stuff. If we really want to use HTMl a language for documents to write GUIs then we should make a new version that is the modern subset of html and css, where you ONLy have 1 way to do a thing (remove or limit the use of float, don't support all boxing models, simplify the layout rules so I don't have to google and find that to make something to work I have to set min=width=0 so the css engine follows a different path and does the correct thing)

I'm curious if you've found any GUI frameworks for any OS, in any language, that have ripped out all their legacy code and/or the design tradeoffs and hacks their legacy code required.

>I'm curious if you've found any GUI frameworks for any OS, in any language, that have ripped out all their legacy code and/or the design tradeoffs and hacks their legacy code required.

Yes, Qt4 is not compatible with Qt3 , Adobe Flex4 was not compatible with Flex3 , I only used at that time this new versions and did not had to work or learn the old stuff. Old projects continued to use the old stuff and continued to work.

HTML and CSS are probably the best tools for styling, layout and accessibility. Compared to other UI platforms though, their built-in controls are missing, limited, and inconsistent between browsers. See https://open-ui.org/ for an example of what controls could be improved and added.

Qt allows the use of (sort-of) CSS for customizing controls.

https://doc.qt.io/qt-5/stylesheet.html

I have written a full OS like GUI in JS proving that it can be tiny and memory efficient. The GUI part of the application is about 2k loc across two JS files plus CSS and includes full file system display and navigation. It’s all vanilla JS and static DOM methods so it’s as fast and memory efficient as the browser allows.

It’s amazing how fast the browser can be for this (and tiny) when you aren’t using querySelectors, vDOM, or event listeners.

Curious, what do you write that is 'OS like GUI' that doesn't require querySelectors, DOM and event handlers?

How do you handle the nuances of GUI and input handling?

Content is dynamically generated in response to user interactions. For example a user clicks a button to navigate to a parent directory the new directory contents are fetched and populated into DOM artifacts using a function which recognizes the returned object as a microservice instance.

Instead of querySelectors I use things like getElementById, getElementsByClassName, getElementsByTagName, and some custom DOM navigation utilities I wrote for this application like getAncestor, getModalsByModalType, getNodesByNodeType, and so forth.

You don't need any kind of framework or fancy wiring to work with events. You always know what you are working with from within the event handler, because event handlers receive an implicit event object as their first argument. From that there is event.target which returns the element the handler is assigned to or event.currentTarget which returns the element the user interacted with that fired the event after bubbling.

State management is also just as easy.

Because layout, rendering, and accessibility are not easy problems to solve and already handled by browser engines that come with your OS.

It's more work to reinvent those wheels than bind to them.

Tauri allows you to build apps that are pure rust - the js is optional and has multiple configurable integration models called 'patterns' that allow defining and constraining the engines includsd, the interfaces between them, and the tradeoff between binary size and distribution simplicity/robustness.

https://tauri.studio/en/docs/usage/patterns/about-patterns

> WebKitGTK

Is there something like WebkitQt? Guess it would use WebEngine.

Webkit not WebEngine. ( https://webkitgtk.org/ )

And here I was hoping it would use Servo.

Servo is kind of dead, no? I'm not sure anyone is working on it for their day job, at least.

Reply on news.ycombinator.com