Hacker News Reader

Comment by Joker_vD | Hacker News Reader

> sooner or later, someone is going to want to display some HTML (or an actual website!) within their application. We’d really rather not bundle an entire browser engine to accomplish this

Theoretically speaking, yes, but in practice it seems most people just gave up and simply ship their apps with embedded Chromium, which is why now almost every single piece of software has installer that's at least 500 MB large.

View on HN

> which is why now almost every single piece of software has installer that's at least 500 MB large.

I know pessimism about software is in fashion, but exaggerating the problem doesn't help. The actual size of the latest version of Electron (on Windows) is 181 MB uncompressed, 77 MB zip-compressed, and 51 MB 7z-compressed. Not great, but again, let's not make it look worse than it is.

Also, there is hope. Microsoft's WebView2 [1] means that Windows has a modern, shared, embeddable web rendering engine for the first time in several years. And Tauri [2] is making it easier for web developers to take advantage of WebView2 on Windows, and WebKit on Mac and Linux, to create lightweight native applications using web technologies.

[1]: https://docs.microsoft.com/en-us/microsoft-edge/webview2/

[2]: https://tauri.studio/en/

I have two Electron apps on my computer, one is 470MB and the other 511MB.

Which ones? I have two too (Obsidian and IRCCloud), each weighing in on 88M and 52M. So it does seem it's possible.

That doesn't mean it's elecrron taking up the space. Native apps are ofteb much larger than that.

At the moment, realistically using WebView2 requires shipping a WebView2 Runtime, either a fixed version or a bootstrapper. That's still over a hundred MB. I don't quite understand why that isn't being included with Edgeium, maybe it will be there in the future, but as of now, having Edge installed is no guarantee that any software trying to use WebView2 will work.

I've got too many scars from needing to ship shared Microsoft runtimes in the past to be entirely happy about this current situation.

Webview is not a replacement.

Webviews for GUIs is the worst of all worlds. You're packaging up two separate event based runtimes, chromium and node, and have no ability to interface with V8, meaning youre actually losing significant performance by having to serialize/deserislize data from node, to the browsers window, then deserislized on message in the browsers packaged JS engine.

It makes no sense to treat your desktop GUIs as closed sandboxes, what's the threat model?

Electron is not simply chromium, it has a bunch of optimizations, fixes, and prebundled functionality.

This entire thread is about which webview to use as an actual web view in an otherwise native application, not trying to use them as apps

Shipping WebView2 runtime "in-box" in Windows is supposed to start with Windows 10 21H2 and Windows 11. I believe soon after both release (Chromium) Edge will also start shipping it by default down to previous Windows 10 versions still in security support.

I've got a lot of scars from MS... but the bootstrapper is 1.7MB. It will then pull in WebView2.

WebView2 btw is awesome (I've spent a lot of time with it already, see my profile if you want to know why)

Well bashing Electron is popular, this is why even a blatantly incorrect comment is automatically the top one as long as they are denigrating Electron.

Just wanna give a shout out to tauri's mobile site; it has a "Learn More" button prominently on the first screen, ABOVE the standard "Get Started" button most projects use. I greatly appreciate the opportunity to understand what I'm starting before doing it.

Webviews can't access the V8 engine, have different implementations on every platform, and are worse in performance.

As a business would you save 120MB in filesize, or thousands of hours in development time?

Electron isn't even unique in this. Blender is over 200MB now. Photoshop and Autodesk products have been big for a long time.

I'm still getting my head around electron development, but only the main process in electron is really supposed to access the V8 engine right (if you turn sandboxing on anyways). With sandboxing on, you're still doing IPC from your render context to some backend, where for webview would be whatever framework is using the webview right?

Is the V8 performance benefit really that high compared to something like C# just calling system calls?

I’d assume it’s more about the tooling and libraries for JS. If I want to build an HTML based UI, I have thousands of JavaScript libraries alongside thousands of developers who know how to use them. If I want to build HTML that calls into C# I’ll need to do a lot more work myself.

Blender includes art assets like HDR cubemaps.

And so so so much functionality. Video editor, modeler, several renderers, image editor, python text editor, sculpt software, importer, video audio mixer, compositor, graph editor, scripting engine, .. monkey model. So much functionality comparing it with irc clients is not fair.

I would ship a daemon/service that makes use of the user installed browser, if a Web interface must be.

And you would then be back to debugging small intricate differences across browsers, which is what people ship Electron to avoid.

Since I don't want to be part of Chrome marketing force, that is a very good thing to do.

Either go native or Web standards.

That's nice technically, but awful in terms of usability.

Only if the developer doesn't know any better.

It can replicate Electron UI/UX without the bloat or Chrome marketing.

Why?

Would WASM solve the performance issue? One can imagine writing a webview GUI in a compiled language in order to get the speed and size benefits.

No, that would be worse actually. Imagine a circumstance where you need to use a library to fetch some network data that you can't do in a browser. Now you have to import the whole data stream via text serialize/deseralize into the browsers sandbox.

Wasm is also quite slower and bulkier because you'd have to compile your entire runtime into wasm, and then have it in the browser.

> sooner or later, someone is going to want to display some HTML (or an actual website!) within their application. We’d really rather not bundle an entire browser engine to accomplish this

I read that and cannot avoid thinking: yeah well, sooner or later someone is going to want to play an MP3 file. Should now all GUI toolkits include multimedia playback support?

Someone is going to want to display and edit a PSD file, does it mean the GUI toolkit should be able to handle the Photoshop file format?

I get where it's going (I've been a GUI developer myself, working with Qt which does include a browser engine), but to be honest I think that already crosses the line from GUI framework to do-it-all framework.

Qt has a reduced version of HTML and CSS that it uses for Widgets styling, which is why you can make words bold, or underlined or whatever, in labels and pretty much everywhere in the GUI. This is very useful to have. Many more basic toolkits include no such functionality, or have a divide between "plain text" widgets, which can do no formatting at all, and a real browser-ish HTML widget. (There's also capital-R-T Rich Text used in some parts of Windows but you really don't want to go there)

I mean yes? Because either the toolkit does it or the platform does it and the toolkit wraps the functionality.

I think it’s easier to flip the script. If you didn’t include the ability for your toolkit to display HTML with a browser widget how do you imagine your user proceeding? I don’t think most end-programmers would be expected to know how to take WebKit and maybe a JS engine and make it into a custom widget in your framework.

You forgot rhe most important: to send email. (jwz)

If I watch my non-techie family members use their computers, they hardly use anything that isn't either in the browser or using electron.

I used to see a few things like Acrobat Reader (now killed off by pdf.js), Word (the college seems to now launch the web version by default), Skype (now Electron MS Teams) etc.

To be fair, the only non-electron (or browser) thing I can think of that I use for work on a regular basis is the terminal. VSCode is electron, Joplin is electron, Teams is electron.

To be honest I've done a complete 180 in my views on electron. As long as the application is well made and optimised (which, to be fair, is somewhat rare) I often prefer it to native. People talk about vendor lock-in when it comes to their data, but very few people seem to consider OS lock-in as another, just as important factor. If I'm using a native app that only runs on windows, that'll discourage me from moving over the linux should the want ever arise (and it does). Obviously there are exceptions like Sublime, which are both native and cross-platform, but like the well made electron apps, they're an exception to the rule

Do you find Teams well made and optimized? Eveyone that I know hates it.

God no, I was referring more to vscode (and obsidian, which I use personally)

Don't get me wrong, its better, you can always instantly tell how much work has been put into an electron app, especially on windows (and when you have a dark theme on) because the poorly made ones will use a default white titlebar, whereas those with some effort will have the titlebar match the rest of the application. So Teams has that going for it.

But optimisation wise, yeh, its not pretty. I used to use Linux at work, and it was soley responsible for my twice-weekly crashes (I knew because sometimes, if I were quick enough, I could stop the crash before my laptop slowed to a halt by force closing teams). On Windows, its better, but thats not saying much.

They are moving it to Edge Webview and off of Electron. It's supposed to use 1/2 the memory.

https://tomtalks.blog/2021/06/microsoft-teams-2-0-will-use-h...

It's trash, but mostly because it's got that standard Microsoft schmear on it, not because of electron.

The fact that this is relevant to the discussion means we aren't trying to advance technology anymore, just make more sales.

Chromium is not 500mb, and at this point the discussion is a dead horse. Every time it's brought up someone makes up new numbers because they've never worked with it nor understand why it's used. If you don't know, don't comment, it's that simple.

The actual bundled size is about 120MB, it can be lowered. Actual memory usage is about the same but is relative on how much memory your system has overall.

My solution to this (it's been done before), is to use the existing browser engine (not the system webview) installed. So far I only utilize Chrome, but as the way I connect to it is over the Chrome DevTools protocol which is somewhat fluent with the Remote Debugging Protocol[0] that Firefox is doing, this is a reasonable approach.

So far my "tool" to do this is simply a template repository with some conveniences, providing in essence a skeleton for these types of apps. I hope to flesh this out a little more, and expose a much richer API, as well as convert some of my existing popular apps (like 22120[1]) to the "framework".

The benefit of this is Graderjs has a built in 'app builder' that can create a cross-platform binary (excluding or ignoring the necessity (on MacOS) and near-necessity (on Windows) to sign your executable somehow, that lets you display your UI in JS/HTML/CSS using the already installed browser engine, as well as run code in NodeJS and using the rich APIs[2] of the browser engine itself. I'm really happy with this project and think that, even tho it's small now, it will in time become my most popular and powerful one: even bigger than my remote browser and popular web archiver.

Just give it time! :)

[0]: https://firefox-source-docs.mozilla.org/remote/index.html

[1]: https://github.com/i5ik/22120

[2]: https://chromedevtools.github.io/devtools-protocol/tot/Brows...

The GraderJS: https://github.com/i5ik/graderjs

The article also talks about MS Edge not being crossplatfom. Well.. that's about to change [1]. There's a beta for Linux, macOS, Android & iOS. What surprised me most about all this is that MS even provides the Edge for retired versions of their own OS (Windows 7 & Server 2008). I'm very impressed by that.

For Windows you don't have to include the WebView2 installer, your installer, can basically include a "stub", the evergreen bootstrapper [2], that then goes out to the internet and grabs the latest version.

edit: The great thing about WebView2 is that Microsoft keeps their control up to date. (At least on Windows, not sure what that is going to be on other platforms, time will tell)

[1] https://www.microsoftedgeinsider.com/en-us/download/?platfor...

[2] https://developer.microsoft.com/en-us/microsoft-edge/webview...

Just to add, the Evergreen option also doesn't require multiple installs if multiple programs are using it. The client machine just needs a single install that all programs will share [1]. Further, if the client also has Microsoft Edge installed and up-to-date, Edge and WebView2 will be hard-linked allowing them to share the same libraries and processes, further reducing the performance, memory, and storage footprints.

[1]: https://docs.microsoft.com/en-us/microsoft-edge/webview2/con...

I'm hoping that it improves performance ;)

Thanks for expanding on that part. It's really nice how Microsoft deals with these updates.

>I'm very impressed by that.

Why? Chrome supports those platforms. There's no reason for Edge to not.

MS does not normally provide support for retired versions of their platforms. They have no direct financial incentives to do so.

Edge may become crossplatform, but it's still just a skin on top of Chromium.

We didn't give up.... we use one these three when someone needs to be shown a web page:

  ShellExecuteW(NULL, L"open", (LPCWSTR)wuri, NULL, NULL, SW_SHOWNORMAL);

   [[NSWorkspace sharedWorkspace] openURL:nsurl];

  ::execlp ("xdg-open", "xdg-open", s.c_str(), (char*)NULL);

> now almost every single piece of software has an installer that's at least 500 MB large.

First, that's 500MB initially. It goes up from there.

Second, that works only if a small number of apps are bundling Chrome, and RAM can keep up; once too many Electron apps promulgate, people will start installing fewer apps.

If your I dunno, weather widget starts consuming 1GB to show me current weather, I'm going to trash it, if it conflicts with my IDE.

Yeah. But what are the options really for poor multi-billion dollar companies while making GUI based applications. They all have "carefully evaluated strategic options" and come to same conclusion: Electron is the way to go.

The article deals with this in a later section and has an interesting discussion about the tradeoffs. Note that you don't have to ship Chromium with every app, you can also go use web rendering engines supplied by the platforms.

And why Chrome market share keeps increasing.

Luckily, Google our beneficient overlord would never use it for anything nefarious after all their motto is "Do No Evil" /sarc.

was*

I think that was included in the "/sarc".

[EDIT:] I thought it was for quite a while after it wasn't any more. [/EDIT]

Well you can use the installed browser on the OS if it's just to display content.

A) But then you need to install a web server component with your app. (And make sure that starts with it, keep track of that process staying alive, etc.)

B) As was mentioned, I think both in the article itself and several comments here, then you get to contend with the same problem Web devs do: Browser differences.

Reply on news.ycombinator.com