While this is definitely an improvement on Electron and Chromium Embedded Framework, in terms of bloat, this is IMHO only solving part of the problem. Another problem with this web-app as desktop app framework is the lack of integration with the OS look and feel, which is really annoying me.
Anyway, you’re still loading a java-script engine and web renderer just to display widgets and handle click events, but it’s the ones shipped with you OS instead of the ones shipped with the app. :/
Another problem with this web-app as desktop app framework is the lack of integration with the OS look and feel, which is really annoying me.
That boat has sailed. For well over 10 years, people have been consistently choosing custom styled apps. In fact, I suspect many applications became popular just by slapping a slick html design on it, while established native apps got labeled as “archaic with dated appearance”. It is a very silly reality to say the least. But that’s just how things have been. Visuals trump everything.
Thing is, even if you use “native” toolkits, if you’re writing a cross-platform application, it will look out of place on every single platform that isn’t the toolkit’s main target.
GTK? That’s not going to look native on a KDE desktop, let alone Windows or macOS. You can get close, but the design the app is built with, will be GTK, regardless of how you skin it. Integration involves much more than colors and window decoration. The design guidelines for the major platforms all differ, sometimes in big ways, sometimes in small.
Same goes for QT, and every other cross-platform toolkit.
If the goal is desktop integration, that’s at least 3-4 frontends to build. Very few can afford that.
If the goal is desktop integration, that’s at least 3-4 frontends to build. Very few can afford that.
This is always the argument that we hear. So, if Slack doesn’t have the resources to build 4 frontends, why do we have a bunch of third-party clients developed by solo indie developers that have most of the functionality? For a previous job, I have used a third-party client and it worked great (and only used 30MiB RAM).
And then even if we buy this argument. For e.g. Apple platforms, they have to develop a separate iOS version for Slack anyway. Why can’t they just make a Catalyst Mac app, which would be far less work than developing a new frontend and would be a net improvement over an Electron app [1]? Heck, even the iPad version of Slack used to work on M1 Macs and some people preferred that over the Mac Electron app. However, Slack has disabled the option for Mac users to disable the iPad version.
My take: companies making the most commonly-used Electron apps (Slack, Teams, Skype, etc.) have enough money to develop platform-specific frontends. But they just prefer to externalize the cost to the user, since it saves them money, and most users do not have a choice anyway. And this is how we end up with Electron apps like Ora, which regularly consume >1GiB of memory for a relatively simple task manager.
[1] To Twitter’s credit, they did write their app with Catalyst. It’s definitely not as great as an AppKit app, but it’s definitely better than a lot of Electron apps.
That is the reality, though. As an indie developer, I can build one frontend. I can’t afford more, so I’ll have to choose my tools wisely, and - like many - I chose one that lets me build an application that looks the same everywhere, so when my users switch between platforms, they’ll have a familiar experience.
So, if Slack doesn’t have the resources to build 4 frontends, why do we have a bunch of third-party clients developed by solo indie developers that have most of the functionality?
Because people didn’t like the look of the official app. Doesn’t mean the official app is wrong in any way. There’s no one app that will please everybody. For Slack, it’s pretty simple to see how we ended up in this situation: when they started out, they certainly did not have the resources to build N+1 native apps. Once they did, they already had an official app that people were familiar with, so why change?
My take: companies making the most commonly-used Electron apps (Slack, Teams, Skype, etc.) have enough money to develop platform-specific frontends.
My take: indie developers and smaller companies can’t afford that, and those matter a heck of a lot more than the big players who just don’t care.
Electron & the like let people build things they otherwise wouldn’t be able to. Insisting that everyone should “just make native apps” isn’t helping. It’s very discouraging for those of us who can’t afford that. Would be nice? Certainly. I’d much prefer native apps over web frontends + whatever backends, most of the time. Often times, that’d be easier to build, too - for one platform. But it’s not practical to do so as an indie developer. Very few can afford to develop different frontends. You yourself listed some of the big names - they could, for sure. But the vast majority can’t.
Qt last I used it was native widgets on Mac and windows. But even if it still looks odd, it won’t look any more odd than electron, but it will perform better.
Qt last I used it was native widgets on Mac and windows.
Like I said, it can be skinned to look native. But it takes a whole lot more than skinning an app to make it look and behave natively. How the widgets are arranged, how they behave - that can vary between platforms, and the toolkits provide little help with that. Widgets alone won’t make your app feel native. Look, maybe, but not feel.
For example, on macOS, when you close a window, the app usually doesn’t stop, it continues running in the background, waiting for you to open a new window. On Windows and Linux, they usually do stop. That’s a subtle, but big difference. Keybindings likewise. The layout of a typical app can be very different between the platforms too.
No toolkit will solve that. If you want truly native, well integrated apps, you will need to build different frontends for the different platforms, otherwise it will never integrate well enough.
But even if it still looks odd, it won’t look any more odd than electron
I found that often times, an app that looks and behaves the same way on every platform is better received, and more useful than one that tries to adapt to the particularities of a given platform. As a user, I’m in that camp myself, I much prefer applications that look the same regardless of the platform over those that have different native frontends for each. There are a few exceptions, but in general, when there’s a cross-platform app, I hardly ever look for a native UI. I like my buttons where I expect them, so to say.
It is certainly easier to maintain a single frontend too, with a single look and feel, than it is to maintain three. Maintenance cost can be a huge factor, and as an indie developer, even more so. So if the app looks odd anyway, I’d prefer it to look the same kind of odd everywhere.
but it will perform better.
Yeah, it usually will. Question is: is it worth it?
I found that my users consider it a good thing that the application I develop looks the same everywhere. It’s consistent. It’s reliable. It’s not surprising. Even if they have to work on an unfamiliar platform, they can rest assured that an app built with non-native toolkits will more often be the same on every platform. That can be a great relief.
Tauri, Electron and similar stacks make that easy, along with the many other benefits they bring (along with a whole lot of baggage too, of course). QT, GTK and most native toolkits or toolkits that try to mimic the platform native one go the exact opposite way.
Neither is perfect, both have their pros and cons, and neither invalidates the other. There are cases where native toolkits are a better choice, and there are cases when they’re not, and that’s fine. Choosing a toolkit, a technology is always a compromise.
To me the flat design trend has destroyed distinctive looks of native OS toolkits. Mac OS X used to be impossible to fake. It had pixel-perfect buttons and multi-layered subtly textured gradients. Anything less than native Cocoa was an uncanny valley. But now? Slap border-radius or box-shadow on any semitransparent box, and it looks just as good or better than Big Sur’s Aquapocalypse.
On Windows there’s also nothing left to care about. Even Microsoft doesn’t know what is the look and feel of their OS any more: with every version they add yet another unfinished redesign to the pile. There’s nothing to be consistent with.
I linked to the tweet since there seems to be no blog post at https://tauri.app/ But in the page is where they highlight the new release, and they have v1 guides and documentation up to date.
Very exciting IMO, looking forward to trying it out
The tweet does at least give an elevator pitch, unlike the home page which makes the cardinal sin of not telling you WTF the thing is. You can scroll down and read between the lines of the feature pitch, but it took me some navigation to finally find a page that lays it out:
Tauri is a toolkit that helps developers make applications for the major desktop platforms - using virtually any frontend framework in existence. The core is built with Rust, and the CLI leverages Node.js making Tauri a genuinely polyglot approach to creating and maintaining great apps.
I have read the entire contents of their home page and I still have no clear idea what Tauri actually is. Something to do with JavaScript packaging or mobile apps or web front ends?
But I am mostly a backend guy so maybe this is a case of, “If you were the target audience, you would know.”
Except it doesn’t embed chromium inside of it like Electron, it uses the available webview on whichever platform the application is running on. I’ve set it up and played around with it a few times and it’s actually pretty nice and runs way leaner than electron apps do. Your frontend can technically just as easily be HTML pages rendered from the backend, it doesn’t actually need to be JS oriented.
Just watched the demo video and must say this looks pretty cool. Especially that you can write native components & then call/“invoke” from your JS code. Basically a kind of FFI, right? It says you can already do native dialogs, presumably through the same mechanism - I wonder whether that could extend out to eg Cocoa and/or Win via, I don’t know, QT or wx or something? That would be a real killer - desktop app with native logic layer, access to native GUI widgets, all scripted together with JS, bundled up into a small and decently-performing package that doesn’t eat up lots of resources. Unfortunately way above my native-GUI-experience/available time, but … a man can dream, can’t he?
Tauri has a similar architecture to Electron in this regard: both have a main process and a renderer. It just happens that with Electron, both are JS, and in case of Tauri, the main process is Rust. In both, the two processes can communicate via IPC. In both, you can make native calls to the OS (Electron can pop up native dialogs too, and the main process can use modules that have native, non-JS parts, etc).
A desktop app with a native backend is possible, both with Electron and Tauri. Access to native GUI widgets is also kind of possible, but in both cases, from the main process, not from the renderer. The renderer is pure JS in both, so you can’t (at least not easily, not without jumping through plenty of hoops) mix native widgets into a web view.
Thanks, this is interesting/useful, and I hadn’t understood that the invoke feature was (by the sounds of it) using IPC rather than an FFI like I thought. Wishful thinking I guess. Appreciate the feedback!
It is using IPC, not just by the sounds of it, but based on the code too.
Mind you, not having FFI in the WebView is generally a good thing. Electron defaulted to nodeIntegration: true for quite a while (and you can still set that option), which made node APIs available to the renderer process, and that becomes a security nightmare the moment your webview meets untrusted content.
I don’t think they’re focusing on integrating native widgets other than things like file open dialogs. It’s a web-based desktop app platform just like Electron except it uses the WebView library installed on your desktop and Rust. The JavaScript runtime has a fairly robust API to access the desktop, file system, etc. You rarely need to write functions in Rust.
Fair enough, & thanks for the info. I’m just wanting something different, I think, as part of the point of a native environment for me is to be able to access platform APIs but do the UI declaratively in a friendly/already-familiar cross-platform way. I’m probably not the target audience. It looks cool anyhow!
While this is definitely an improvement on Electron and Chromium Embedded Framework, in terms of bloat, this is IMHO only solving part of the problem. Another problem with this web-app as desktop app framework is the lack of integration with the OS look and feel, which is really annoying me.
Anyway, you’re still loading a java-script engine and web renderer just to display widgets and handle click events, but it’s the ones shipped with you OS instead of the ones shipped with the app. :/
That boat has sailed. For well over 10 years, people have been consistently choosing custom styled apps. In fact, I suspect many applications became popular just by slapping a slick html design on it, while established native apps got labeled as “archaic with dated appearance”. It is a very silly reality to say the least. But that’s just how things have been. Visuals trump everything.
Thing is, even if you use “native” toolkits, if you’re writing a cross-platform application, it will look out of place on every single platform that isn’t the toolkit’s main target.
GTK? That’s not going to look native on a KDE desktop, let alone Windows or macOS. You can get close, but the design the app is built with, will be GTK, regardless of how you skin it. Integration involves much more than colors and window decoration. The design guidelines for the major platforms all differ, sometimes in big ways, sometimes in small.
Same goes for QT, and every other cross-platform toolkit.
If the goal is desktop integration, that’s at least 3-4 frontends to build. Very few can afford that.
This is always the argument that we hear. So, if Slack doesn’t have the resources to build 4 frontends, why do we have a bunch of third-party clients developed by solo indie developers that have most of the functionality? For a previous job, I have used a third-party client and it worked great (and only used 30MiB RAM).
And then even if we buy this argument. For e.g. Apple platforms, they have to develop a separate iOS version for Slack anyway. Why can’t they just make a Catalyst Mac app, which would be far less work than developing a new frontend and would be a net improvement over an Electron app [1]? Heck, even the iPad version of Slack used to work on M1 Macs and some people preferred that over the Mac Electron app. However, Slack has disabled the option for Mac users to disable the iPad version.
My take: companies making the most commonly-used Electron apps (Slack, Teams, Skype, etc.) have enough money to develop platform-specific frontends. But they just prefer to externalize the cost to the user, since it saves them money, and most users do not have a choice anyway. And this is how we end up with Electron apps like Ora, which regularly consume >1GiB of memory for a relatively simple task manager.
[1] To Twitter’s credit, they did write their app with Catalyst. It’s definitely not as great as an AppKit app, but it’s definitely better than a lot of Electron apps.
That is the reality, though. As an indie developer, I can build one frontend. I can’t afford more, so I’ll have to choose my tools wisely, and - like many - I chose one that lets me build an application that looks the same everywhere, so when my users switch between platforms, they’ll have a familiar experience.
Because people didn’t like the look of the official app. Doesn’t mean the official app is wrong in any way. There’s no one app that will please everybody. For Slack, it’s pretty simple to see how we ended up in this situation: when they started out, they certainly did not have the resources to build N+1 native apps. Once they did, they already had an official app that people were familiar with, so why change?
My take: indie developers and smaller companies can’t afford that, and those matter a heck of a lot more than the big players who just don’t care.
Electron & the like let people build things they otherwise wouldn’t be able to. Insisting that everyone should “just make native apps” isn’t helping. It’s very discouraging for those of us who can’t afford that. Would be nice? Certainly. I’d much prefer native apps over web frontends + whatever backends, most of the time. Often times, that’d be easier to build, too - for one platform. But it’s not practical to do so as an indie developer. Very few can afford to develop different frontends. You yourself listed some of the big names - they could, for sure. But the vast majority can’t.
Qt last I used it was native widgets on Mac and windows. But even if it still looks odd, it won’t look any more odd than electron, but it will perform better.
Like I said, it can be skinned to look native. But it takes a whole lot more than skinning an app to make it look and behave natively. How the widgets are arranged, how they behave - that can vary between platforms, and the toolkits provide little help with that. Widgets alone won’t make your app feel native. Look, maybe, but not feel.
For example, on macOS, when you close a window, the app usually doesn’t stop, it continues running in the background, waiting for you to open a new window. On Windows and Linux, they usually do stop. That’s a subtle, but big difference. Keybindings likewise. The layout of a typical app can be very different between the platforms too.
No toolkit will solve that. If you want truly native, well integrated apps, you will need to build different frontends for the different platforms, otherwise it will never integrate well enough.
I found that often times, an app that looks and behaves the same way on every platform is better received, and more useful than one that tries to adapt to the particularities of a given platform. As a user, I’m in that camp myself, I much prefer applications that look the same regardless of the platform over those that have different native frontends for each. There are a few exceptions, but in general, when there’s a cross-platform app, I hardly ever look for a native UI. I like my buttons where I expect them, so to say.
It is certainly easier to maintain a single frontend too, with a single look and feel, than it is to maintain three. Maintenance cost can be a huge factor, and as an indie developer, even more so. So if the app looks odd anyway, I’d prefer it to look the same kind of odd everywhere.
Yeah, it usually will. Question is: is it worth it?
I found that my users consider it a good thing that the application I develop looks the same everywhere. It’s consistent. It’s reliable. It’s not surprising. Even if they have to work on an unfamiliar platform, they can rest assured that an app built with non-native toolkits will more often be the same on every platform. That can be a great relief.
Tauri, Electron and similar stacks make that easy, along with the many other benefits they bring (along with a whole lot of baggage too, of course). QT, GTK and most native toolkits or toolkits that try to mimic the platform native one go the exact opposite way.
Neither is perfect, both have their pros and cons, and neither invalidates the other. There are cases where native toolkits are a better choice, and there are cases when they’re not, and that’s fine. Choosing a toolkit, a technology is always a compromise.
To me the flat design trend has destroyed distinctive looks of native OS toolkits. Mac OS X used to be impossible to fake. It had pixel-perfect buttons and multi-layered subtly textured gradients. Anything less than native Cocoa was an uncanny valley. But now? Slap
border-radiusorbox-shadowon any semitransparent box, and it looks just as good or better than Big Sur’s Aquapocalypse.On Windows there’s also nothing left to care about. Even Microsoft doesn’t know what is the look and feel of their OS any more: with every version they add yet another unfinished redesign to the pile. There’s nothing to be consistent with.
I linked to the tweet since there seems to be no blog post at https://tauri.app/ But in the page is where they highlight the new release, and they have v1 guides and documentation up to date.
Very exciting IMO, looking forward to trying it out
The tweet does at least give an elevator pitch, unlike the home page which makes the cardinal sin of not telling you WTF the thing is. You can scroll down and read between the lines of the feature pitch, but it took me some navigation to finally find a page that lays it out:
This looks super cool!
Thanks for posting this, I’ve been tracking it for awhile to see how it comes along.
I have read the entire contents of their home page and I still have no clear idea what Tauri actually is. Something to do with JavaScript packaging or mobile apps or web front ends?
But I am mostly a backend guy so maybe this is a case of, “If you were the target audience, you would know.”
It’s basically Electron GUIs for Rust
Except it doesn’t embed chromium inside of it like Electron, it uses the available webview on whichever platform the application is running on. I’ve set it up and played around with it a few times and it’s actually pretty nice and runs way leaner than electron apps do. Your frontend can technically just as easily be HTML pages rendered from the backend, it doesn’t actually need to be JS oriented.
This is their webview layer which you can use all on its own https://crates.io/crates/wry
I should check it out before passing judgement, I suppose. But any web-based desktop application GUI makes me nervous.
Just watched the demo video and must say this looks pretty cool. Especially that you can write native components & then call/“invoke” from your JS code. Basically a kind of FFI, right? It says you can already do native dialogs, presumably through the same mechanism - I wonder whether that could extend out to eg Cocoa and/or Win via, I don’t know, QT or wx or something? That would be a real killer - desktop app with native logic layer, access to native GUI widgets, all scripted together with JS, bundled up into a small and decently-performing package that doesn’t eat up lots of resources. Unfortunately way above my native-GUI-experience/available time, but … a man can dream, can’t he?
Tauri has a similar architecture to Electron in this regard: both have a main process and a renderer. It just happens that with Electron, both are JS, and in case of Tauri, the main process is Rust. In both, the two processes can communicate via IPC. In both, you can make native calls to the OS (Electron can pop up native dialogs too, and the main process can use modules that have native, non-JS parts, etc).
A desktop app with a native backend is possible, both with Electron and Tauri. Access to native GUI widgets is also kind of possible, but in both cases, from the main process, not from the renderer. The renderer is pure JS in both, so you can’t (at least not easily, not without jumping through plenty of hoops) mix native widgets into a web view.
Thanks, this is interesting/useful, and I hadn’t understood that the
invokefeature was (by the sounds of it) using IPC rather than an FFI like I thought. Wishful thinking I guess. Appreciate the feedback!It is using IPC, not just by the sounds of it, but based on the code too.
Mind you, not having FFI in the WebView is generally a good thing. Electron defaulted to
nodeIntegration: truefor quite a while (and you can still set that option), which made node APIs available to the renderer process, and that becomes a security nightmare the moment your webview meets untrusted content.I don’t think they’re focusing on integrating native widgets other than things like file open dialogs. It’s a web-based desktop app platform just like Electron except it uses the WebView library installed on your desktop and Rust. The JavaScript runtime has a fairly robust API to access the desktop, file system, etc. You rarely need to write functions in Rust.
Fair enough, & thanks for the info. I’m just wanting something different, I think, as part of the point of a native environment for me is to be able to access platform APIs but do the UI declaratively in a friendly/already-familiar cross-platform way. I’m probably not the target audience. It looks cool anyhow!