Hacker News
3 years ago by brundolf

Looks like it uses system webviews instead of bundling a copy of Chromium? This to me seems like the real headlining feature, but strangely I had to dig pretty deep to find it: https://tauri.studio/en/docs/getting-started/technical-detai...

I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface.

Interesting thing I just thought about: since users don't get to choose their system webview, I wonder if this has the potential to broaden browser diversity a little bit?

3 years ago by the_duke

A major benefit of Electron is that you can develop against a single browser and runtime version and don't have to deal with all the small but time consuming compatibility quirks.

On Windows the default webview engine is still not the new Chromium but old Edge (WebView2 has to be installed separately), Safari has a fair amount of issues and gtk-webkit can be very quirky as well.

This is not so significant if your app has a web version and you have to deal with it anyway , but thereare a fair amount of Electron only apps. Or even with a web version, the desktop app often has special features not present on the web.

But webviews are as much a moving target as browsers and often behave differently from the regular browser version in a myriad of ways, so you need an even bigger testing matrix.

Webviews are also hard to properly secure and don't provide the extensive APIs of Electron, which you often have to bake yourself in a wrapper written in, eg, Rust or C++.

I say all this as someone who hates how resource hungry Electron apps are and groans each time about yet another one on my machine, but I understand why it is so popular.

3 years ago by brundolf

> don't have to deal with all the small but time consuming compatibility quirks

> Webviews are also a moving target so you need a big testing matrix

I say this as a front-end web app dev who would most likely be affected by this kind of shift: it might be slightly less convenient, but I wholeheartedly think it's worth doing, on several levels.

People built web apps 15 years ago in the dumpster-fire that was web standards at the time (and frankly, web tooling too). Browsers, even the good ones, didn't update themselves automatically. Most of the world was still on IE which was actively hostile to web standards for the sake of lock-in (and users weren't even on the same version of IE!). There was nothing like Babel to smooth over the rough edges, there were no polyfills. And even the standards that existed, when you got the opportunity to use them, mostly sucked.

I think, given all that, we can deal with supporting recent-ish Chromium and the latest Safari, if it means bolstering web diversity and saving an order of magnitude in RAM and storage.

3 years ago by danudey

Also: a lot of our "Electron" apps are essentially Electron frontends to the existing web frontend.

For example, Slack-the-Electron-app and Slack-the-web-app are fundamentally identical, aside from likely some platform integration features and so on. That means that, likely, a lot of these Electron apps would already work in, for example, a Safari or Edge webview, since the web version has to anyway. I sincerely doubt that they're taking the time to strip out that compatibility, since the only reason to do so would be efficiency and if you're using Electron that's not a priority.

IOW, for many applications, there's a near-100% chance that everything would function with little to no extra work, and for most of the rest it would likely take very little.

3 years ago by morpheuskafka

That's fine for someone who already keeps current with front-end stuff, but someone who is a desktop app developer is more likely to just go native than try to make a desktop app that tracks 3+ browser engines of wildly varying versions (luckily 7 is out of support now, but it still might be desired to support for some desktop apps in which case now you have IE to deal with). Electron gives the promise of total code re-use across platforms which is what makes web technologies more suitable for desktop apps.

3 years ago by jlokier

I run three browsers on my desktop, because the number of things that don't work properly in anything except recent Chrome is enough that I keep encountering issues, I don't want to use Chrome for my regular browsing, and both Safari and Firefox have issues on some sites.

On my tablet, a number of current websites don't run even on Chrome, because the tablet isn't particularly new, so it doesn't have current Chrome. It's still great hardware in perfect condition though, everything that does run on it is perfectly smooth and so on, and I still use it. Youtube in particular is fine. Literally the only reason to buy a new one would be to satisfy the software treadmill.

My old phone didn't run Chrome (or Safari). It had Firefox. The only reason I switched to a newer phone, using Android, was because of sites that gradually didn't run well on Firefox any more. That was annoying, having to ditch a perfectly great phone and replace it with something better for the web but worse for other things.

I have a Macbook Pro at home. I'm pretty happy with it, it's still a fine machine, I use it for work every day. It runs the latest Safari that's safe to run on it, but that's not the latest Safari, because it would have problems running the most recent OS.

This brave new world of "I'm sure we'll be fine supporting recentish Chrome and latest Safari" is a world of exclusion. I don't like the memory usage of Electron, but I prefer it to applications that are a bit broken!

Also, to be honest, I've been looking at memory usage. Electron uses much less than any of the three big browsers. You may know that Chrome famously starts a new process for each tab, and Safari does too. Firefox isn't far behind. As a result, the memory saved by running a new page in an already running browser compared with Electron isn't as much as it was long ago, back in the days when tabs shared memory. This is visible with Safari, as the website name shows up in the system utility for viewing process memory.

I know, that feels wrong somehow, but it's true.

Finally, when using a system WebView, will that save memory if it's opening a separate instance of the system's browser? It must be separate in some ways, if opening an application that uses a WebView doesn't open all your saved tabs from last time the browser was open. (And it's a horrible experience if opening an application does open all the other tabs.)

3 years ago by 908B64B197

> Most of the world was still on IE which was actively hostile to web standards for the sake of lock-in (and users weren't even on the same version of IE!)

More like: A lot of corporate users mandated a specific version of IE and wouldn't allow anything else to be installed.

3 years ago by munificent

> Webviews are also a moving target so you need a big testing matrix.

Even worse, an OS update after you ship your app can spontaneously break it on end user's machines without you knowing or being able to do anything about it.

At least with the web, when new browser versions come out, you can fix your site since users essentially "install" it every time they refresh the page. But an installed app that runs on top of a spontaneously updated framework is the worst of both worlds.

3 years ago by brundolf

It's not hard to silently auto-update an Electron app's internals; I assume the same is true for Tauri

3 years ago by undefined
[deleted]
3 years ago by snemvalts

Need a docker for electron

3 years ago by albertzeyer

But why would the system webview be less resource hungry? If it runs in an own process instance, the only memory you safe is (maybe) the executable code (i.e. maybe 100MB max).

Or you would need some common runtime which is shared across the OS, and somehow use IPC to it. Then you can potentially save some more memory. But I don't think this exists. And I'm also not sure how much you really would save.

The advantage of using the system webview is that you can update this component, in case there are any vulnerabilities or so.

3 years ago by cozzyd

100 MB / app is significant, especially on laptops.

Slack used to use so much memory on Linux that I couldn't afford to run the desktop app and ran it inside a Firefox tab for years... seems to have gotten better somehow.

3 years ago by undefined
[deleted]
3 years ago by sophiebits

Theyā€™re not inherently more efficient (other than the reduced application size), but Safari and Edge are both more resource-efficient than Chrome.

3 years ago by OskarS

Dynamically loaded system libraries use shared memory. You can load it once for the entire system.

3 years ago by runarberg

> don't have to deal with all the small but time consuming compatibility quirks.

Good, then developers might start to develop against standards instead of handpicked browsers. Or if they use a future (unstable) standard that is their own headache (as opposed to userā€™s; which are subsequently in practice forced to use chromium derived browser).

An app developed against a single browser (as opposed to the web standard) should be considered what it is, an ugly hack, and developers that do it should only do it for their own private apps never to be published until it is standard compliant.

3 years ago by hobofan

This is about desktop and not web development though. I agree that pages available on the web should be standard compliant and work with all browsers.

On the desktop you are developing against a runtime that the developer of the app gets to choose, so why not choose one that has less potential for quirks?

3 years ago by userbinator

"standards" - in practice, it's "what Google wants".

3 years ago by dfabulich

People have been trying the WebView approach for years. (Projects include: Quark, Electrino, DeskGap, Revery, and Neutralino.)

Historically, it worked terribly on Windows.

On Windows, if you used the OS WebView, your Windows 7 users would be forced to use IE11 to run your app, even if they had a newer/better browser installed locally. On Windows 10, you'd get whatever random version of Edge was installed, or the new Chromium-based Edge.

In 2021, we're in a new era for Windows WebViews, thanks to Microsoft shipping WebView2 at the end of 2020, which ensures that the OS-provided WebView will be a modern version of Chromium. https://docs.microsoft.com/en-us/microsoft-edge/webview2/ Tauri supports WebView2 and I bet it will work a lot better than historical approaches.

Support is still pretty dicey on other platforms, though. macOS doesn't have anything like WebView2, so if you want to support a five-year-old version of macOS (which isn't that old in desktop terms), you'll be forced to support and test your app on a five-year-old version of Safari. (The user might have upgraded to a two-year-old version of Safari, but they might not, if they prefer Firefox or Chrome, and that's now your problem.)

The easiest and best way to improve the user's experience on old OS versions is to provide your own copy of Chromium, like Electron does.

At that point, if you've shipped an Electron app for macOS and Linux, maybe you just wanna ship an Electron app for Windows and call it a day?

Having said that, if you can keep your OS-version support matrix tight, Tauri might work OK for you.

3 years ago by dmix

Fortunately MacOS users upgrade very quickly. High Serria which is slowly waning at 7% came out in 2017. Compared to windows where twice as many (16%) at still using Windows 7 and won't be able to download the Webview2 update which Microsoft kindly provides.

https://gs.statcounter.com/windows-version-market-share/desk...

https://gs.statcounter.com/os-version-market-share/macos/des...

Really depends on your market I guess and how much legacy webview browser support you need.

Or really how much you'd need to add polyfills like `@babel/preset-env` to keep the JS equal.

3 years ago by ac29

Webview2 supports Windows 7 according to the link in the comment you're responding to.

3 years ago by CommonGuy

We use the WebView approach for Kreya[1], though not with Tauri. We had some occassional issues with Chromium/Safari differences, but otherwise it works fine.

We use WebView2 on Windows, Safari on macOS and WebKit2GTK on Linux. Not shipping a whole Chromium installation on each install and update reduces the installer and on-disk size a lot!

[1] https://kreya.app

3 years ago by dfabulich

https://kreya.app/docs/getting-started

I see issues here!

> Apple Silicon (M1) is not yet supported.

And on Linux,

> you may install Kreya by downloading the tarball. Note that both libgtk-3 and libwebkit2gtk-4.0 dependencies are required. Install them manually if they aren't present on your system.

libwebkit2gtk is, itself, _an embedded browser_, 44MB installed size, plus dependencies.

It's convenient that you can make Snapcraft install it for you, but that's not really different from making Snapcraft install Electron and running that.

3 years ago by flanbiscuit

> I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface.

Like other replies have mentioned, it's not a new idea

DeskGap uses the native OS Webviews. https://github.com/patr0nus/DeskGap/

Electrino (4 years old) was an experiment where they forked Electron and removed Chromium to replace it with the native OS Web views. https://github.com/pojala/electrino

Quark is a fork of Electrino: https://github.com/jscherer92/Quark

There's also a way of building desktop GUIs using Deno, which uses Deno Webview, which is a binding for the same webview library that Tauri uses.

https://denotutorials.net/making-desktop-gui-applications-us... https://github.com/webview/webview

3 years ago by baxrob
3 years ago by devwastaken

Webviews don't work because they solve very different problems.

System webviews will always have different features, break things, and are entirely uncontrollable by the software distributor. This means your software will not be resilient to the future.

You cannot access the JS engine the same as you can V8 in most webviews. This means you can't interop with C libraries without some performance destroying hack like copying everything into the JS space through sockets.

This also means something as simple as reading a file has to, again, cross the sandbox in an inefficient way. You'd have the browser, it's javascript engine, and your own runtime in node or python or however too.

Electron develops patches that make chromium more performant and feature ready for desktop.

Electron conjoins the chromium and node v8 event loop to take advantage of libuv - again a performance improvement.

The decision of webviews and electron is based on what you're trying to do. If it's simple html/JS that's pretty much self contained then sure.

3 years ago by andrew_

It's been a minute since I attempted it on Windows, but transparency of borders and borderless windows with the webview on Windows was next to impossible. It's one of the reasons we used Electron. I'm curious to know if they've solved that, but can't find my mention of it.

3 years ago by saagarjha

If you cared about performance, would you really be using Electron?

3 years ago by innocenat

Yes. Why not? HTML/CSS great (from the development POV) for UI, and I can always write the performance critical code in C and linked them to the electron HTML/CSS frontend.

3 years ago by swagonomixxx

This kind of makes me think... is there room for a much more stripped down version of Chromium that is suitable for lower memory footprint? Or is this impossible?

It looks like Tauri uses system webviews, which use a lot less memory, but the burden is then on the developer to make sure that they build essentially 3 (maybe more) UI's on platforms that might change under their feet. That's why the Electron approach is simpler - it trades of performance for uniformity of experience across the major platforms.

But I'm wondering if it really has to be this way. Do modern browsers really need 2G of RAM in order to send and receive messages in a chat box (looking at you, Slack).

3 years ago by c-smile

"is this impossible?"

Possible, see Sciter.JS : https://github.com/c-smile/sciter-js-sdk

10 times more compact than Tauri, 20 times less than Electron.JS

Yet it has Rust API ( https://github.com/sciter-sdk/rust-sciter ), that if someone need "Made with Rust" label :)

And it works even on Windows 2000, do you remember that thing? See: https://sciter.com/necromancing-sciter-on-windows-2000/

3 years ago by croes

Too bad it's kickstarter campaign to make it open source failed.

3 years ago by gigel82

I like Sciter for the possibilities, but it needs better compatibility with web standards. Being able to port an existing application that uses React -for example- and have it just run would be the cat's meow.

Needing to rewrite with other UI/JS frameworks to account for quirks gives me pause.

3 years ago by c-smile

It depends on what application you have in mind.

React needs web browser compatibility layer to work in Sciter.JS as React was designed strictly for browsers.

For that matter: PReact ( https://preactjs.com/ ) works out of the box already, see : https://github.com/c-smile/sciter-js-sdk/tree/main/samples/p... ;

MithrilJS ( https://mithril.js.org/ ) works as it is also.

SvelteJS works as it is with Sciter.JS too.

Also Sciter.JS has its own native implementation of JSX ( it's built in JS core of Sciter.JS) and also DOM extended by native element.patch(vdom) that makes "reactivity" to work in Sciter.JS with native speed.

Yet quite a lot of UI components are natively built-in. For example:

https://sciter.com/behaviorvirtual-list-for-sciter-and-scite... and https://sciter.com/sciter-js-themes/

3 years ago by _jordan

sciter is a really wonderful piece of software. it's performance has been really impressive when I was benching it against qt

3 years ago by LockAndLol

From what I understand the internals (aka the engine). That is a problem IMO. I understand it's to create a dependency on the maintainer in order to make money, but yeah... it's the reason I've stayed away thus far.

3 years ago by vulcan01

> the burden is then on the developer to make sure that they build essentially 3 (maybe more) UI's on platforms that might change under their feet

Is this really different from the current state of web development? Front-end developers have to test against Chrome, Firefox, and Safari, at a minimum. For apps that are basically installable websites (like Slack, which has a perfectly functional webapp) this doesn't seem like that far of a stretch.

3 years ago by MattGaiser

> Front-end developers have to test against Chrome, Firefox, and Safari, at a minimum.

Do many companies actually do this though? I've only ever been with companies that test against Chrome. The one time at FF bug was found, that company told that client to switch to Chrome.

I know there was a kerfuffle about Airbnb and Groupon only doing Chrome as well.

https://www.reddit.com/r/AirBnB/comments/dv7v6n/customer_sup...

https://thenextweb.com/dd/2017/11/28/please-build-websites-w...

Maybe in theory all platforms are considered, but in practice many companies just do one and the others mostly just work.

3 years ago by joshuacc

Yes, absolutely. Every company that I've ever worked at had a list of officially supported browsers that included Chrome, FireFox, Safari and Edge/IE. QA engineers would make sure to rotate through various browsers while testing, and for crucial features would run through every scenario in every supported browser's oldest and newest supported versions.

3 years ago by calibas

Most companies today use frameworks that have good cross-compatibility so it tends to just work. In my opinion though, a responsible web developer is going to test on multiple browsers at the very least.

3 years ago by tambourine_man

Safari is huge. Doing Chrome only is suicide. Thankfully, cross browser compatibility is much easier these days, specially if you donā€™t use flex or grid.

3 years ago by swagonomixxx

In a previous company we had to do FF and Chrome. Not IE though, which was a big time saver. QA ran all their test cases on the latest stable of both FF and Chrome, and features would not be deployed to prod if they didn't work on both browsers.

3 years ago by dmix

And in recent years this has gotten much easier. Cross browser support used to be a pain in the ass.

Now most of the time changes arenā€™t even needed. Besides maybe the odd Firefox or Safari thing.

3 years ago by Kaze404

Funnily enough in my experience it's usually Chrome and Safari that do weird things, which as a Firefox user always gets me dinged on PR reviews :p

3 years ago by livre

Not much different but enough to be dangerous. Older Windows use Trident, 10 still uses EdgeHTML, many people are stuck with old Androids that don't have up to date engines (not sure if Android is a target, wasn't easy to find in their website), and webviews have access to the system in ways a website doesn't (like reading files or using the camera without having to ask for permission or being allowed to issue requests to arbitrary domains).

3 years ago by moron4hire

But we know from web statistics that these are very few people and shrinking every year.

3 years ago by munificent

> is there room for a much more stripped down version of Chromium that is suitable for lower memory footprint?

That's basically the history of Flutter. The initial goal was something like "Web: The Good Parts" and the results of that experiment led them to where they are now.

3 years ago by ducktective

I mean, where are they now? Promising or DoA? I fear touching it because of it being a Google project (killedbygoogle.com)

3 years ago by jonathanaird

Theyā€™re putting a lot of resources behind and it actually is thriving. They have a real financial interest as thereā€™s pretty thorough firebase support. Itā€™s also reviving their Dart language.

As someone thatā€™s using it, it is improving very quickly. Web support is getting quite good.

3 years ago by chgibb

We're pretty bought into Flutter. No cross platform toolkit is perfect but Flutter is miles ahead of everything else. For a not very scientific analysis: https://trends.google.com/trends/explore?date=today%205-y&q=...

3 years ago by kybernetikos

Have you seen how Sciter.JS has been developing https://github.com/c-smile/sciter-js-sdk

There are a few working examples, and they have dramatically lower memory footprint and are quicker to start than full fat browsers.

3 years ago by GirkovArpa

I've performed a couple experiments remaking Electron apps using Sciter.

My first target was https://github.com/AkashRajpurohit/clipper, a neat little clipboard manager. The owner was gratious enough to officially list my project under the "Clones" section of his readme =D The result was a 6mb file, compared to the original 165mb Electron app.

The second attempt was https://github.com/girkovarpa/temps-lite, an aesthetically-pleasing weather app which was motivated largely by the fact that the original was broken and abandoned yet still had people who wanted to use it. According to the open issues and forks trying to resurrect it, anyway. The file size savings were similar to the former, and they start virtually instantly. Unlike the Electron apps which have a bit of delay and then a blank window before they finish starting up.

3 years ago by yannoninator

I think the desktop seriously needs a production, RAM and developer friendly breakthrough that isn't Electron.

Tauri may be it, but the desktop SO needs this moment, I don't want to see 50 years on and Electron is still being used.

3 years ago by ZeroCool2u

I'm really hoping Flutter or Kotlin Desktop have a breakthrough here soon. Personally, I'm rooting for Flutter, but I'll take what I can get.

3 years ago by areille

It would be fun that Dart finally takes over Javascript this way (Flutter is written in Dart, which was originally written to be the new Javascript)

3 years ago by pictur

I wish the dart language was more common than typescript. but this is very hard.

3 years ago by calibas

There's React Native for Windows/macOS, though if you don't like Electron I doubt that's very appealing either.

I've had some nice experiences using PyInstaller to create desktop apps.

3 years ago by ianlevesque

React Native is fantastic as a user on macOS and Windows. Personally I think if thereā€™s any hope of winning the Electron crowd over thatā€™s it. I like to develop with stronger typed languages than JS, but there's clearly demand given electronā€™s popularity.

3 years ago by calibas

I started getting in the habit of using Typescript with JS. It's annoying at first, but worth it for any decent sized codebase. All the bugs from JavaScript's unexpected type conversions just disappear.

3 years ago by scarlac

Depends on why OP doesn't like Electron.

To be clear to everyone: Electron and React Native are not alike. Electron is a big web browser. React Native work completely differently: It neither renders, computes, or runs the same. React Native uses the Hermes engine, puppeteering native components.

3 years ago by ori_b

I feel like this is a monkey's paw wish. I've wanted to see QT and GTK replaced with something better for a long time.

We got Electron, and other browser based toolkits.

3 years ago by Razengan

SwiftUI is pretty good, if you don't care about Android/Linux/Windows.

3 years ago by twarge

Downloaded the demo app for macOS; feels like an alien UI even though effort was clearly made to use system widgets. On the positive side, the app is only 4 MB and consumes 50 MB at runtime, so at least they've succeeded in that important aspect.

3 years ago by vulcan01

If I'm not mistaken, this is just because the CSS styling isn't that good, right? Take Slack (which uses Electron) as an example: it looks almost the same on Windows and Mac, but it looks good ā€” because the styling (through CSS) is good.

3 years ago by millstone

You're talking about how the app looks, but GP was talking about how the app feels.

Slack looks nice but feels quite broken. For example, its non native context menus are beautiful, but do not dismiss properly, do not support single-click selection, do not support spacebar to pick, do not support type-select...

When I use Slack I am constantly frustrated that things don't work the way my other Mac apps work.

3 years ago by jcelerier

Slack definitely does not look good when your definition of "looks good" is "integrated with the rest of the OS"

3 years ago by MaxBarraclough

Is CSS really the major factor in the memory usage of an Electron app?

3 years ago by vulcan01

I wasn't responding to the memory usage portion of the GP's message, but rather to the alien feel.

3 years ago by gameswithgo

Its consuming more than that at runtime I believe, you just don't see it because its using webkit in another process? I recall some discussion along those lines.

3 years ago by kall

I think most companies that already decided on the electron UX vs dev effort tradeoff will happily trade user resources for a guaranteed, uniform browser version target. It makes a big difference in development and testing.

3 years ago by ryandrake

Yea, but as a user, it's disappointing, and kind of impossible for me to push back on this trend. I can avoid using these apps, but it's an impotent show of protest. It won't make a difference. User experience, native look and feel, and the user's RAM are all being sacrificed on the altar of More Comfortable Developer Experience.

3 years ago by undefined
[deleted]
3 years ago by undefined
[deleted]
3 years ago by stevenhuang

Same here for Windows. Feels like using a video game UI. Probably is the basic styling, but I'm really liking the file size (2.6MB) and mem usage (app.exe using 2.7MB with the "Desktop App Web Viewer" instance using 22MB) otherwise.

3 years ago by themihai

I think a better electron would be an Electron that you can build only with the features you use(i.e I don't use websql, I don't need CORS, web notifications, nfc, bluetooth, hundreds of legacy js and css features, no pdf/print support etc). I'm pretty sure that if you can drop all the stuff you don't use you get better performance/efficiency.

3 years ago by ianlevesque

It goes deeper than that. Frickinā€™ Spotify has a manual toggle for whether or not I want Hardware Acceleration turned on or not. Itā€™s not the only one. I donā€™t have any way to know which setting doesnā€™t spin up my laptop fans and burn me. How about just building your app in such a way that I donā€™t have to manually configure that. Weā€™ve had music players since the 90ā€™s, I donā€™t see why this is so hard.

3 years ago by hobofan

The Electron alternative that possibly isn't one.

Electron apps are usually quite heavy because they bundle Chrome. Tauri doesn't and instead relies on webview, which uses a different browser engine dependent on your platform, with all the incompatibilities that come with it.

3 years ago by Tuna-Fish

> Tauri doesn't and instead relies on webview, which uses a different browser engine dependent on your platform, with all the incompatibilities that come with it.

Isn't windows system webview now a chromium fork? This should make incompatibility on the major platforms now much less of an issue.

3 years ago by smasher164

People act as if they havenā€™t dealt browser incompatibilities in the past. Just feature-detect/polyfill and move on.

3 years ago by notatoad

Some people haven't dealt with browser incompatibilities in the past. Not every developer comes from a webapp background, and electron is a platform to develop desktop apps. desktop app developers don't want to deal with polyfills and feature-detection in their platform.

3 years ago by imbnwa

What browser incompatibilities do exist are case-by-case basis, not all at once, depending on business domain and solution design, and even if, like you point out, you can just carpet bomb the issue with a poly/ponyfill.

The infantilization in frontend is accelerated by its veneer of supporting Product's sole mission in life to ship products ASAP, and I fucking hate it, and I've been some frontend engineer somehwere unimportant for 5 years now.

I wager, generalizing from my quite limitde experience, that a concerning amount of frontend devs just know how to schlep bags of data around and eventually get a desirable outcome with a framework keeping things narrowly from getting out of control when they are obvious re-factors, massive simplifications, that would get just as much expressiveness with less code. You will have bossess who only understand technical discussion in the form of "what framework or library should we use for this new epic?", like, bro, let's model the problem and see what we need from there maybe before we start thinking about writing code? You can almost just ask a frontend dev, "How would you refactor this or that code? to find out if they're just a baggage handler trying to minimize any concerted thought on their part. It's like frontend is corporate's proving ground on how to flatten all thinking and passion out of software engineering

Sorry, end of rant. I came to frontend from academia naively thinking people wanted to think about problems and put effort into solutions

3 years ago by chrismorgan

That works for many scripting capabilities, but thereā€™s plenty you canā€™t polyfill. If youā€™re stuck with the old MSHTML-based web view (which you will be on all but very recent Windows 10 and even sometimes there), there are various CSS Grid features that you canā€™t polyfill, and youā€™ll have a number of weird and annoying SVG sizing and styling issues quite apart from any potential missing features, and a bunch of other things like thatā€”even if you polyfill everything in reach (which, even where possible, may perform terribly).

3 years ago by Klonoar

That updated Webview is, still, not the default on Windows. You have to ship it yourself.

3 years ago by mch82

> Today, Tauri uses Rust for the backend - but in the not too distant future, other backends like Go, Nim, Python, Csharp etc. will be possible. This is because we are maintaining the official Rust bindings to the webview organisation and plan to let you switch out the backend for your needs. Since our API can be implemented in any language with C interop, full compliance is only a PR away.

Sounds promising. Iā€™d love a web view front end for Python as an alternative to tkinter.

3 years ago by pachico

Each Electron application seems to think it's the only one running in a computer. It's the only way, I imagine, they think it's acceptable the amount of resources they need to run.

3 years ago by hctaw

As a developer shipping executables to MacOS, Windows, and Linux today this is the only assumption I can make. I cannot assume that dependencies exist or are the correct version, I can't assume the user knows that package managers exist or that the dependencies shipped by the package managers are correct, I can't assume anything exists on PATH or LD_LIBRARY_PATH, and I can't even assume that libc or libc++ on a system will work with the executable I compiled on mine.

Meanwhile 16GB of memory is becoming common and 1TB SSDs cost less than $100. So taking up a little bit more space saves me time and money and reduces the cost to ship to my customers. Oh well.

3 years ago by pachico

I understand your point, however I still think it's unacceptable to have 1-1.5 GB of RAM consumed by simply two Electron applications running idle.

3 years ago by fabiospampinato

That's not the baseline though, the baseline RAM consumption for an Electron app is about 100MB. If you have garbage code as input it doesn't matter which stack executes it, you'll have garbage performance output.

3 years ago by simias

Honestly I could try to ignore the memory consumption if at least it was snappy. The few electron apps I use have visible lag when I do something that forces a large redraw.

That's a problem that didn't have with GTK app running on a computer with one order of magnitude less computing power and RAM two decades ago. VS code on the first computer I used to program would probably be unusable (if it even launched), yet we had full fledged IDEs back then. I'm not talking about advanced language server plugins here, just basic usage.

The great side effect of this is that if you avoid all this wasteful crap and keep using old school technology, computers are snappier than ever. My terminal always pops up instantly, nvim fires up faster than I can press return, rg lets me search a huge codebase with barely noticeable latency. My IMAP mail client is faster, more configurable and more ergonomic than any webmail I've seen.

Life is good when you avoid the www.

3 years ago by undefined
[deleted]
3 years ago by troyvit

The problem is that every app developer is starting to believe the same thing, so we just end up with more and more bloat. Computer hardware has never been more powerful but because of bloated apps actual performance feels -- to this user -- the same as it was in 2010.

3 years ago by gameswithgo

It isn't your fault that you have to do this, it is that our industry hasn't created enough quality, easy to use, cross platform gui libraries for popular languages, such that the only viable place to turn is to use a whole web browser.

3 years ago by qbasic_forever

We've had about 60 years and multiple huge attempts at it, and IMHO HTML & CSS _are_ the easy to use cross-platform GUI platform. Nothing else stuck--flash, java swing, qt, etc. were all super capable and promising but failed to gain mass usage. HTML & CSS is the way. Nothing in existence has as much capability, developer usage and talent pool, accessibility and internationalization features, etc. A good GUI system is much more than just getting boxes and text on the screen.

3 years ago by eivarv

I don't think this is entirely true. Have you tried wxWidgets or even Qt?

In my experience, this is more about resources and economics ("reuse existing code" vs. having to learn something new).

3 years ago by hctaw

I didn't say I was shipping GUI software ;)

3 years ago by jlokier

> Meanwhile 16GB of memory

Oh if only that was enough. My Safari is currently using 25.33GBĀ¹ and and it regularly goes over 30.

> 1TB SSDs cost less than $100

Ah, if only it was that easy.

Ā¹ (According to iStat Menus; it's harder to see in Activity Monitor due to the separate processes.)

3 years ago by hctaw

you can't buy an M1 mac with more than 16GB of memory so it seems like you have bigger problems

Daily Digest

Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.