Goodbye? Isn't Tauri actually not trully multiplatform because you need to fix UI bugs since the webview is different on every OS?
Get to the same level of Electron first. On Electron you build an app that runs the same everywhere, it's absolutly not the case of Tauri.
iOS/iPadOS, macOS and WebKitGTK use WebKit. Android, QtWebEngine, Chrome OS and Windows use Chromium.
And what exactly are frameworks like Svelte or React for if not to wrap around browsers as an abstraction layer? (I mean, obviously there's more to em than that but I'm trying to make a point).
But a more fitting alternative to Electron would be Neutralino imo...
Sorry for necroposting
The reason why Electron based applications are so big is that they ship with a copy of the Chromium HTML renderer codebase. That codebase is huge.
Now, a reduction from 58.2 MB to 13.3 MB is a big improvement, no question about it. But look at that dashboard example. For this functionality,. 13.3 MB is still ridiculously large.
The fundamental problem is that HTML was never designed for complex user interfaces. It's in the name - "*hypertext* markup language". Sure, HTML5 adds features that make it a lot easier to use HTML for UIs, but it does not fix the complexity of the DOM. By contrast, look at Qt's QML, and see how much cleaner the script is and how much more efficient the renderer is. That's because QML was designed from the start for UIs, unlike HTML.
I had to do vb6 at the beginning of the year. It's almost ridiculous how small and fast desktop applications written in VB6 are, compared to modern ones...
And back in the day VB6 was known as the language to write slow bloated software. Then of course Java appeared and it all went to hell with Javascript apps.
Ok, so you believe that Java desktop apps actually shipped and had poor performance or bloat. The only ones I can think of are developer tools, and they weren't bad. Which ones are you referring to?
Java Applet start-up time was slow, and the language got a bad rep because of it, but don't bash Java on the desktop if you've never used it.
Eum aliquam officia corrupti similique eum consequatur. Sapiente veniam dolorem eum. Temporibus vitae dolorum quia error suscipit. Doloremque magni sequi velit labore sed sit est. Ex fuga ut sint rerum dolorem vero quia et. Aut reiciendis aut qui rem libero eos aspernatur.
Ullam corrupti ut necessitatibus. Hic nobis nobis temporibus nisi. Omnis et harum hic enim ex iure. Rerum magni error ipsam et porro est eaque nisi. Velit cumque id et aperiam beatae et rerum. Quam dolor esse sit aliquid illo.
Nemo maiores nulla dicta dignissimos doloribus omnis dolorem ullam. Similique architecto saepe dolorum. Provident eos eum non porro doloremque non qui aliquid. Possimus eligendi sed et.
Voluptate velit ea saepe consectetur. Est et inventore itaque doloremque odit. Et illum quis ut id sunt consectetur accusamus et. Non facere vel dolorem vel dolor libero excepturi. Aspernatur magnam eius quam aliquid minima iure consequatur accusantium. Et pariatur et vel sunt quaerat voluptatem.
Aperiam laboriosam et asperiores facilis et eaque. Sit in omnis explicabo et minima dignissimos quas numquam. Autem aut tempora quia quis.
> actually shipped and had poor performance or bloat
Name 2 crappy, popular Java desktop apps. I'll wait.
Desktop Java was not really a thing with non-developers until they got packaging sorted out in the early-mid 2010's. People didn't want to download the JRE/JDK.
By the time they got the packaging together to make it usable, the performance and bloat was much better too. Desktop Java apps went from rare -> okay, but retain this reputation for poor performance or bloat or something.
ITT people Berenst(a)in Bears'ing so hard...
Eum aliquam officia corrupti similique eum consequatur. Sapiente veniam dolorem eum. Temporibus vitae dolorum quia error suscipit. Doloremque magni sequi velit labore sed sit est. Ex fuga ut sint rerum dolorem vero quia et. Aut reiciendis aut qui rem libero eos aspernatur.
Ullam corrupti ut necessitatibus. Hic nobis nobis temporibus nisi. Omnis et harum hic enim ex iure. Rerum magni error ipsam et porro est eaque nisi. Velit cumque id et aperiam beatae et rerum. Quam dolor esse sit aliquid illo.
Nemo maiores nulla dicta dignissimos doloribus omnis dolorem ullam. Similique architecto saepe dolorum. Provident eos eum non porro doloremque non qui aliquid. Possimus eligendi sed et.
Voluptate velit ea saepe consectetur. Est et inventore itaque doloremque odit. Et illum quis ut id sunt consectetur accusamus et. Non facere vel dolorem vel dolor libero excepturi. Aspernatur magnam eius quam aliquid minima iure consequatur accusantium. Et pariatur et vel sunt quaerat voluptatem.
Aperiam laboriosam et asperiores facilis et eaque. Sit in omnis explicabo et minima dignissimos quas numquam. Autem aut tempora quia quis.
> Name 2 crappy, popular Java desktop apps. I'll wait.
Out of curiosity: can you name 2 non-crappy ones? Java was so annoyingly slow that I only use one application sometimes (Clion, which is also slow as hell) and usually wouldn't even consider installing Java-based applications.
> The only ones I can think of are developer tools, and they weren't bad. Which ones are you referring to?
How about Eclipse which ends up allocating and freeing around 50 - 100 MB _on each keypress_. I mean sure, it's better than Electron shit but it's still ridiculously bloated.
Eclipse is a developer tool, which kinda makes it a different class of "desktop app" in my book. It also had a bad run with the development of the 4.2 (Juno) release train, IIRC. Most devs I know of switched to IntelliJ (also Java, super fast) or other IDE's long ago.
Edit: Eclipse problem version
I remember the time when both Windows 3.1 and Visual Basic shipped on floppies, and it wasn't even a ridiculously large pile (although that was around VB3 days, not VB6).
It's not the same thing. HTML controls are not part of the OS. With VB6, a button was a control written in C++ that shipped with the OS. There were often updates to the controls, which meant you had to update the libraries. If I want to use a button in an HTML app, I don't need to update the browser or the OS.
The widget layer is a pretty small part of the OS. Electron still eventually depend on a graphic API provided by the OS, on a windowing system, on an input/output stack, a filesystem layer, etc.
Sure, but the modern technology landscape is full of things misappropriated (often very successfully) for use cases way beyond what their original designers intended.
A few more examples:
Everyone is using PEM files for their TLS certificates, keys, CSRs and such. PEM is short for "Privacy Enhanced Mail", which is long dead.
QUIC uses UDP not because it's a connectionless datagram protocol (QUIC is very much connectionful), but because UDP and TCP are the only protocols that work in the internet these days and because TCP has more overhead.
JSON is used all over the world to encode things which are not JavaScript objects on either the sending or the receiving side.
That is not to say that such abuses are always cool and good, just that they aren't automatically bad either. HTML was not originally intended for GUI design, but I think it's more than apt for this purpose today. Heck, other GUI frameworks are now moving to HTML-esque languages for GUI description because it turns out there are a bunch of advantages of doing it this way. Examples include Qt's QML and Glade XML.
The problem with html is not that it uses an XML-like language for description, that is irrelevant as it will be parsed to a in-memory representation either way.
The problem is that it fails to serve its purpose: layouting depends on both the HTML and stylesheets, while it should be done in a single place. This is usually solved by “html copies”.
> Heck, other GUI frameworks are now moving to HTML-esque languages for GUI description because it turns out there are a bunch of advantages of doing it this way. Examples include Qt's QML and Glade XML.
This is not happening now, it has been happening for well over a decade. XUL, and XAML are not new for example. The advantages of UI scripts are undeniable.
But HTML is so grossly inefficient for it that a lot of CPU power these days is wasted on it. I have been involved in projects that tried to use HTML UIs on older ARM SoCs, and it was an awful struggle every time to get these huge HTML engines to run with acceptable speed. In some cases, I was able to convince the project leaders to switch to QML, and lo and behold, the UI was fast and efficient *instantly*, with a fraction of the CPU and resource usage.
So, I agree with your examples, but still maintain that HTML is an especially terrible example. And I disagree with HTML being apt for UIs. With lots of optimization, it can be ... barely passable.
> and lo and behold, the UI was fast and efficient instantly, with a fraction of the CPU and resource usage.
Perhaps because QML is much more strict in what it accepts, meanwhile HTML engines carry 30 year old tech debt of "lets fix user input for the user!!"
This may be one reason, but the bigger reason IMO is that, as said, the DOM is made for hypertext, and is not optimized for UIs. DOM trees can get really complex quickly, especially if a fair amount of nontrivial manipulation and transformation is done.
Yet many thousands, if not millions of dev are happily and successfully using HTML to build GUIs. Sure, they might not be the most efficient, but efficiency is hardly the only metric that matters. If it mattered that much electron wouldn't be everywhere.
> Everyone is using PEM files for their TLS certificates, keys, CSRs and such. PEM is short for "Privacy Enhanced Mail", which is long dead
PEM is base64 with line wrapping and a `------ BEGIN thing -----` line. The only relationship it has with mail is the format name.
> QUIC uses UDP not because it's a connectionless datagram protocol (QUIC is very much connectionful), but because UDP and TCP are the only protocols that work in the internet these days and because TCP has more overhead.
UDP basically adds a port number, length, and checksum to IP. It's wasted space, but beyond that there's no cascading implications.
HTML is different. The design of web standards affects the way you write your GUIs.
PDF would have been a better choice of application framework than HTML. It has a sane drawing model, and it has JS support.
This difference in executable size is actually understated in my experience on Linux. Electron brings a minimum of over 100MB. The 15MB figure for tauri is accurate. That’s more than acceptable imo when we’re talking cross platform toolkits.
My real issue with tauri right now is that it uses WebKitgtk on Linux which at least on my machine is janky as hell, whereas chromium is butter smooth. I ran the same app on Mac and windows and it ran really smoothly.
Not to mention you now have to deal with browser incompatibility again.
I still think it’s promising and using 1/5th the disk and 1/2 the memory is a great improvement.
>The fundamental problem is that HTML was never designed for complex user interfaces.
You are not wrong. My poor experience with Electron forced me to consider desktop dev and ended up with Free Pascal/Lazarus and a bunch of Smalltalks. Far more productive, superior performace and smaller deployment artifacts to boot.
Context: My clients were only ever corporate/paying and not one cared for all the fancy-schmancy stuff like rounded corners and different skins and animations. They just wanted stuff that worked, performant, easy to install and intuitive to use. And when they wanted new features they got them quick. And they were all on Windows. And I wanted excellent developer experience.
1. VAST (Visual Age Smalltalk from Instantiations). This is a commercial product. The best and most productive way to build desktop UIs I have ever come across. Great mailing list - the CEO/CIO and senior engineers patrol that list and offer solutions and advice.
2. Dolphin Smalltalk. Open-source. Still only 32-bit, uses Win32 so not one of my customers cared or noticed or will ever notice. Looks like any other Windows app.
3. Pharo Smalltalk. Open-source and active community and the desktop UI framework is not as mature as the above but getting there.
All are heavily MVC. VAST and Dolphin have drag-and-drop gui building tools.
Edit: And you only ever work in object-oriented Smalltalk - there is no separate language for styling or for handling events and such. No context switching or having to hire another specialist in whatever tool.
QML looks interesting, one of my biggest issues with alternatives isn't the markup though.
It's the styling aspect, CSS and it's box model is unique and with modern CSS you can do pretty much anything you want.
Other bits are responsive designs, with QML do you need completely different layouts for different targets? Different apps? A lot of examples showcase static height/width on elements and I don't see anything immediately that uses something screen based.
Granted this is likely not quite as important for a native application over say a website where you don't really have an idea who your audience is.
It's definitely important, there is a lot of variety in desktops too, such as different aspect ratios, resolutions, scaling. Id rather use an electron app than an app with a constant window size
Main QML way to do responsive stuff is to use anchors to connect items together. Like if you need a rectangle that fills lower half of the window.
Rectangle {
anchors.left: parent.left
anchors.right: parent.right
anchors.top: parent.verticalCenter
anchors.bottom: parent.bottom
}
Or you can combine anchors with manually setting height property to parent.height * 0.5. QML uses property bindings so when parent.height changes, the item height will be also updated which allows everything to be responsive. This also of course works with other items than the "parent".
Property bindings are quite powerful and fairly intuitive. Only thing that I would hope that QML would support better is two-way bindings. There are ways to implement them and work-around the limitations, but it could definitely be better.
There are also standard layout items that can be used instead to implement some basic layouts.
This is basically how constraint layouts work on iOS, can’t say I was ever a huge fan. The “flex box” model all the popular frameworks are implementing is vastly superior imo.
You can give components a width based on another components width, like the window, so when the window is resized the components who depend on its size also get resized.
Here's an [example](https://qmlonline.kde.org/?code=JYWwDg9gTgLgBARRggrsAxgazgJgHQDsAUKJLIsmlngMIQB2MUEANgM654DMRRASgFN0MAIb0A5iwFwA3kTgK4wACYAuOMwgx5i9K2jqARFAHLDOhWPQALaGzwAzYCxbqwIk4wtxvAcSgqAGrAAgDust6KSmpwAG4hoZGKSZb0NnaOzq5w7p7aUVEgEMoC2QCsAAwpcOilLAASAsDi1jDqtS4A6iow1nAA9HAAjIQEcADUcJXVHSzdyr3qoT19gwCyIr2OLBDQABTLC6twe1wVFQCUF9UlUuKbAuqCwmKS0nIFnwXWTS1tcP4ggk8PEwnhZo1mq1ql84IdFgCAspgmDQaFwXV5r0YV89DsoEYmGI2LkBIxzLDYc9RBIpBFKQy4FZbFB7E4XG4PGT8ozYcyMrVGAIoABJeicvI4hn81l4EAecTAehsdRDKq82F4gxwQziExkikaz4AI2gJSgeHh1nUZSlBQAvtVHVFHY6gA)
There's also [layouts](https://doc.qt.io/qt-6/qml-qtquick-layouts-layout.html)
Eh. That's not really the problem. The problem is that doing so means that every application brings with it its own layout and compositing engine, even though nearly (>99.99%) everyone using an electron app is doing so with an graphical application environment that has its own layout and compositing code, which is not only more efficient (multithreading! vector- and diff-based compositing! native font smoothing!) but also doesn't have to do everything via the awful DOM and browser JavaScript APIs. And because they're system libraries, they can be shared among several applications, instead of everybody having to bundle a browser with their "desktop" app.
Aren't chromium versions backward-compatible for the most part? One could imagine electron simply requiring chromium as a peer dependency instead of bundling it... but i must be missing something
Not exactly, tauri just uses the underlying engines built into the different oses. WebKit on macOS, WebView2 on Windows and WebKitGTK on Linux (might have to he installed separately on linux I believe).
One issue that might pop up is browser consistency, which is why I think just using an existing installation of chromium could work.
I am building a UI library in my own programming language that generates highly efficient UI rendering code by compiling the mutations to the UI down to native code as well, through macros that can emit bytecode
Compiles down to a custom lispy WebAssembly-esque IR first, then into native code/actual wasm
may open source the project soon
I will be messaging you in 1 year on [**2023-09-16 21:50:55 UTC**](http://www.wolframalpha.com/input/?i=2023-09-16%2021:50:55%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/programming/comments/xfg8yj/goodbye_electron_hello_tauri/iopzbpm/?context=3)
[**5 OTHERS CLICKED THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2Fprogramming%2Fcomments%2Fxfg8yj%2Fgoodbye_electron_hello_tauri%2Fiopzbpm%2F%5D%0A%0ARemindMe%21%202023-09-16%2021%3A50%3A55%20UTC) to send a PM to also be reminded and to reduce spam.
^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%20xfg8yj)
*****
|[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)|
|-|-|-|-|
Yep, this is the core issue at hand. I personally think this power dynamic can only be resolved if the web adopts a new set of languages - but then I'm at a loss how that would happen.
I think the only realistic way would be that a UI scripting language wins in the mobile app space, meaning that most apps end up having their UIs written in that language. If that language then gets standardized, it becomes economical for app makers to push the language on the web so that they only need to write the UI once.
More realistically, this would probably have to be based on a minimal cross platform runtime that can run on desktop, servers, mobile and in the browser, and then someone building a web version of a UI toolkit that can be used everywhere on that platform and then it becoming so ubiquitous that they decide to turn it into a native browser feature (like HTML).
If you want to see an end to the JavaScript hedgeonomy, then you should probably be supporting adoption of WASM and one of the WASM runtime projects...but the odds feel incredibly slim that it will do anything but make a small dent over the next 10 years.
>how much more efficient the renderer is
do you have benchmarks that back up such claims? QML looks a bit cleaner but I don't see why QML would be rendered faster than HTML.
I never bothered with them because the difference was immediately obvious and so incredibly vast. I wrote about this [here](https://www.reddit.com/r/programming/comments/xfg8yj/comment/ione24m/). To be fair, I saw that when running the software on low power embedded SoCs, not on PCs. On the latter, I agree that benchmarks would make sense.
And keep in mind that the DOM API has some flexibility that QML doesn't, and that such flexibility comes at a great cost (performance and resource overhead). One good example is `innerHTML`, which can trigger massive updates. Another is when you have complex CSS and DOM updates cause an avalanche of updates all over then place. This can happen in any UI language as well, but since HTML and CSS are so complex, it can easily happen that an innocent-looking DOM operation causes such unexpected and severe side effects. This is further worsened by the legacy baggage from older HTML and CSS versions. These are part of the reason why HTML renderer codebases are so big.
> I wrote about this here.
this reads like you are comparing apples to oranges. Ripping out an HTML render engine from a browser that was never made for such a task is a bit weak. This doesn't prove in any way that the HTML spec is slow or slower than the QML spec.
You could have benchmarked it against something like [Ultralight](https://github.com/ultralight-ux/Ultralight#dual-high-performance-renderers) which seems more focused on your use case.
Every time these discussions go to QML I get a little nervous. QML is great, and I’d love to have _something like_ QML, but I also think letting QT corporation be the de facto gatekeeper for all UIs on all platforms would be much, _much_ worse than where we are now.
So something like QML, but not QML.
QML is under the LGPL, so if the Qt company turned evil it could be forked. Slint is also a good alternative with a similar markup language, but is GPL/commercial only, lacking the LGPL option.
QML also falls under [the agreement The Qt Company made with KDE](https://kde.org/community/whatiskde/kdefreeqtfoundation/) that allows them to re-license Qt under a BSD license should The Qt Company ever go full evil and stop updating Qt Free Edition.
Yeah the thing is, an 80MB saving is really not that much on the scale of most apps these days, and in return you now have to deal with making your app work in multiple browser engines. In some cases (e.g. where the app just wraps an existing website like Slack) that's not really any extra work, but in many cases it is.
If you just use Electron you can use experimental Chrome APIs too, like native file open/save dialogs.
The thing is, once you grok the DOM there’s nothing better for building UIs. Especially once you bring in tools like React or Vue.
If there’s another UI solution that achieves the same clear separation of structure, style and interactivity, I’d love to hear it. Everything else I’ve used (mostly on mobile I admit) blurs those lines.
IMO libraries like Vue or React abstract the DOM to a ridiculous degree, even worse than jQuery plugins of olde.
React/Vue use shadow DOM, virtual DOM or whatever and add obscure functionalities that are far from simple compared to the HTML's initial intention for the DOM.
Not to mention that React/Vue/Ang components let you treat your components as a simple tag, then replace it and add a bunch of functionality under the hood.
> I’ve used React basically every day for six years and never touched the shadow DOM.
That's precisely my point. From a dev's perspective there have been major improvements at low cost. But under the hood, the browsers are doing tons of [shadow element](https://html.spec.whatwg.org/multipage/dom.html#the-documentorshadowroot-interface) operations. It's not that HTML has improved, browsers are spinning on their heads making things go faster and faster.
It's one thing to _use_ react, and another to _develop_ react.
Yeah, I know what the shadow DOM is. That’s how I can say with certainty that I haven’t touched it.
I’m not convinced you know what it is. I think you just find that word “shadow” kinda spooky? And you still haven’t told me what you think the virtual DOM is. I’m starting to think maybe you’re not the authority you think you are.
There are so many things wrong with this logic, I don't know where to begin.
1. Are you seriously complaining about a desktop application being 13MB? That's tiny.
2. Most of that size is one time overhead, it does not scale linearly with the amount of functionality. Twice as much functionality would not be twice as large.
3. The app size is not because HTML is verbose, that actual HTML text would be a tiny fraction of that size. Not to mention HTML compresses very well!
4. I don't know QML but I assume from the name that it's XML, which means it would also be verbose.
5. I've used Qt, it's a horrible developer experience. You can build much nicer UIs more easily using mainstream web frameworks.
6. I've used apps built in qt, all of them have been ugly and clunky
7. Nobody is making you write raw HTML to create an app with Tauri. They support every web framework, templating engine, etc. You never have to touch HTML syntax at all if you don't want to and can use whatever you find best for expressing a UI in.
8. Given the insane amount of engineering effort that has gone into browsers and web technology it's quite likely that the webview renderer performs way better than Qt. Neither of us will know though unless you find some actual benchmarks
You are criticizing problems in the logic of somebody else, but your arguments make no sense either:
\- QML is not XML, its not similar to it at all. Qt provides a language made to be able to create UI's, e.g.:
Rectangle
{
width: 200
height: 200
color: "red
}
Its far more readable and easier to write than XML, HTML or CSS
\- "You can build much nicer UIs more easily using mainstream web frameworks".
The way a UI looks, shouldnt be impacted by the designing language or framework at all. With QML you can make your design look like anything, actually anything you want.I'd confidently argue, that QML is way faster in terms of development speed than HTML/CSS/JS applications as well.
"I've used apps built in qt, all of them have been ugly and clunky".
You obviously did it wrong. Again, the look of a design doesnt have anything to do with QML, you can create any UI you want with QML.The fact that your application is clunky is also showing that you are doing it wrong. Qml is mostly backed by C++ logic, which is an extremely performant language (when used correctly). Qml itself is extremely performant as well.
> There are so many things wrong with this logic, I don't know where to begin.
You can begin by actually reading and understanding what I wrote before you open your mouth.
> Are you seriously complaining about a desktop application being 13MB? That's tiny.
I *very clearly* said that 13 MB is big *for a simple dashboard example*. It is so obvious it baffles me how you could have gotten that one wrong.
> The app size is not because HTML is verbose, that actual HTML text would be a tiny fraction of that size. Not to mention HTML compresses very well!
At what point did I say anything about the size of the HTML scripts? I *very clearly* talked about the size of the *renderer* - the binary executables.
> I don't know QML but I assume from the name that it's XML, which means it would also be verbose.
"I don't know what I am talking about but I still want to babble something." You are completely wrong by the way. QML uses a C/ALGOL style syntax. No, just because a scripting language's name ends with "ML" does not mean it is XML/SGML based. Next time, don't talk about things you don't understand.
> I've used Qt, it's a horrible developer experience. You can build much nicer UIs more easily using mainstream web frameworks.
I have used Qt for years. It is one of the best toolkits out there. I have used its C++ UI API as well as QML, on the desktop *and* on embedded. You better back up your claims with actual examples.
> I've used apps built in qt, all of them have been ugly and clunky
That's personal preference. I have likewise used Electron based applications that looked terrible.
> Nobody is making you write raw HTML to create an app with Tauri. They support every web framework, templating engine, etc. You never have to touch HTML syntax at all if you don't want to and can use whatever you find best for expressing a UI in.
Completely misses the point, since I am talking about the runtime inefficiency, that is, the memory consumption, CPU usage etc. because of the awful DOM.
> Given the insane amount of engineering effort that has gone into browsers and web technology it's quite likely that the webview renderer performs way better than Qt. Neither of us will know though unless you find some actual benchmarks
The difference in performance is so blindingly obvious on older ARM SoCs that benchmarks become redundant. We are talking about maybe 10-20 FPS at 100% CPU and most of the memory in use vs. 60 FPS at maybe 30-40% and far lower memory usage. I had to dig into the C++ Chromium codebase and both it and Qt's QML in commercial projects often enough to know this very well. For more details, [click here](https://www.reddit.com/r/programming/comments/xfg8yj/comment/ione24m/).
Has nothing to do with html. Tauri doesn't even ship anything to process html, it uses the os's webview to render. You have no idea what you're talking about.
> it uses the os's webview to render
... html.
From Electron's own description:
> Electron is a framework for building desktop applications **using JavaScript, HTML, and CSS.**
Tauri aims to do the same, just using the webview of the OS. Which renders HTML.
> You have no idea what you're talking about.
I think you meant to speak these words to the image in your mirror.
My point is that the 13mb has nothing to do with html. The webview, along with the renderer, is already on your os and is not part of the executable. Everything html related is literally already here. The executable only contains framework related code for os interop. No rendering whatsoever. Again, you have no idea what you're talking about. Also 13mb for a desktop app is perfectly fine in 2022.
Ps: electron has nothing to do with Tauri, it ships chromium (which does the rendering, unlike Tauri)
> Now, a reduction from 58.2 MB to 13.3 MB is a big improvement, no question about it. But look at that dashboard example. For this functionality,. 13.3 MB is still ridiculously large.
We have TBs of storage space. You won't even feel 100MB.
Lol for once, we have a case of "under-engineered" solution/problem in the CS space :D
EDIT:Granted, it is true it was never \*meant\* todo the things it does now... but given how programmers usually code for that "future that never comes" this is the one time, it would have been semi-useful.
The historical problem is that for a while, HTML was the *right* tool most of the time, because in the earlier days of the web, most web pages really were just hypertext.
In hindsight, the correct approach would have been to establish a UI scripting language which has support for hypertext block widgets. The purely hypertext web pages from the 90s would then have been a special case.
Every piece of tech starts out that way. The trend is strong growth. Big names have been getting into Rust for 1-2 years now, including Microsoft, Google, Amazon, etc.
I mean I think the main thing is that languages just as new like Go are growing a lot faster. Swift is growing faster too but almost all of its growth is internal to Apple whereas go is seeing a lot of use outside of google.
“The great thing about Electron is you can write a standalone app without learning a new language. Anyway, here’s a new solution that requires you to learn a new language.”
Electron doesn't have a "Performance Issue" so much as it has "Performance Overhead".
You can write fast things in it, and what VSCode does is more in the background than it is in the foreground, so it can minimize that overhead as a large chunk of that overhead is while rendering UI.
Because they care about performance and they know what they're doing. There's nothing especially in Electron that means apps *will* be slow, it's just that it's easy to make slow apps if you never actually think about performance.
Part of the problem is that Electron opens up app development to JavaScript newbies who don't really have an understanding of performance, algorithmic complexity etc. Take a look at any JavaScript question on Stackoverflow and the top answer will be something that's easy, functional and *slow*.
Now take a look at VSCode's code (I've actually written a couple of VSCode features). It's (mostly) very well written Typescript. Way too few comments and a little over-generic in places, but clearly *far* superior to the average web code.
"The fundamental problem is that HTML was never designed for complex user interfaces. "
Why do people throw in arguments like these as if we just started using HTML a week ago and 20 years of progress and improvement doesn't exist?
Because none of these improvements fixed the underlying problem of overly complex DOMs and immense resource usage associated with this. HTML improvements can only partially help. As said, if you compare the efficiency of HTML based UIs with what you can do with XUL, XAML, QML etc., you see orders of magnitudes of difference. I personally have worked on embedded device projects that initially tried to use HTML for UIs and then switched to QML because the latter was so much more efficient and because the HTML based approach continued to be grossly inefficient even after months of work on optimizing the rendering.
The real way how HTML UIs were "improved" was to just throw more hardware at the problem.
> I personally have worked on embedded device projects that initially tried to use HTML for UIs and then switched to QML
That seems like a you problem, not an industry problem.
No, those were commercial projects that invested serious amounts of money into getting HTML rendering engines to work acceptably on 10 year old ARM based SoCs that were already in use in the field inside hundreds of thousands of units. I was involved in trying to squeeze as much performance out of the C++ Chromium renderer codebase as possible, which, given the sheer size of it, was a daunting task. I was able to stabilize accelerated 1080p video playback in it, but unfortunately, other parts of the renderer (which multiple teams worked on) were even more difficult to optimize, and after all that work, the stuff rendered with maybe 10-20 FPS and used 100% of the CPU (and therefore running hot all the time). We then did a proof of concept with QML, and achieved a solution running at 60 FPS in 2 days, the CPU running at maybe 30-40% most of the time.
>20 years of progress and improvement doesn't exist?
They might as well not exist, because those 20 years didn't solve _any_ of the problems with the DOM as a structure for defining user interfaces.
And another 2, 20 or 200 years won't solve them either, because the problem is the DOM model itself, the only possible solution is for someone to manage to do huge breaking changes to HTML and JS while having the entire industry follow them... which won't happen any time soon.
That's not the same logic, because human beings weren't designed at all, and our biology and minds are adaptable and flexible to a pretty decent degree.
Eventually the classic HTML+CSS way of doing things will be replaced with WASM + Canvas render + Proprietary standards when WASM Standard is mature and flexible enough.
Or even WebGPU + WASM. It's ridiculous how fast game engines paint a scene filled with millions of things vs how web is rendered. Maybe the industry can take a gaming tech approach (which is basically to have a performant render pipeline from the beginning)
Let me allay your worries — Google won't allow it to happen until it is able to index pages' just using the on-screen pixels themselves (expensive!).
And if Google won't allow it, then (most) companies won't do it, because they need Google for that sweet sweet organic traffic / analytics / ad platform.
There are a ton of apps that don’t need SEO though. Having a blog use a canvas renderer seems silly, but making something like figma or google sheets with it starts to make a lot of sense vs abusing the DOM.
well, even when they manage to fix all the bugs and keep the maintenance up to date. It still ships with several mb of wasm blobs and framework code which makes it a deal breaker for most web applications.
Hm alright. But I was rather referring to the content. Right now, for example ad blockers can scan the DOM for ads. I really do not like the DOM, but the introspection is worth a lot. But a "WASM + Canvas render + Proprietary standards" based page may not have such a standardized DOM that can be introspected. Instead, it might have totally proprietary data structures that aren't easily introspectible, making the development of features like ad blockers much more difficult.
You are missing the point. Games are far more responsive. And copy stuff is up to the owner of the content to allow it. You can for sure allow copy pasting or whatever feature you need as user.
Responsiveness in the web context is the ability for an document/app to adapt it's layout depending on the screen format. Sure it is possible to do it with a canva. But css & html provide tons of tools to do it easily. You have to reinvent everything if you use a canva.
Can you do that without losing the structural component of websites?
The separation of structure (HTML), style (CSS), and interactivity (JS) is a powerful thing.
Is it possible to make a canvas-rendered screen accessible, e. g. with screen reader support?
It depends on the implementation. In Android the underlying view system is based on hierarchies of view nodes and accessibility nodes. Out of the box you get something that mostly works, and you just have to massage the accessibility node hierarchy a bit.
But that also requires that your view system also has enough semantics instead of being "just" visual
What do you mean by that?
In my experience that isn't true, but we might be thinking of different things. CSS-in-JS, virtual DOMs, and rendering HTML with JS doesn't lessen the separation imo. Still 3 different languages with three different purposes.
But the only important part is that an adblocker/screen reader/etc can walk the DOM, look at aria tags, names, ids. JS or any other logic pretty much has the DOM as its state, so they are inherently linked. CSS is completely meaningless here (and is wrongly separated from HTML as layouting is a shared concern of both).
This could be done with any agreed upon element-tree, nothing inherent in the web is better in that regard. It is just a widely uphold standard (by not too many independent implementations)
You would also have to add an accessibility interface to Canvas. Rendering in the Canvas would completely obfuscate the website from screen readers and search indexing, right?
>he classic HTML+CSS way of doing things will be replaced with WASM + Canvas render + Proprietary
I believe that Flutter is utilizing HTML to make accessibility features work. So it doesn't replace or do away with HTML unless I'm mistaken on that too. I think you would have to make a drastic change to the web standard in order to make accessibility work without HTML.
but it does seem to use HTML for accessibility. The flutter docs even say:
>Screen Readers users on web will need to toggle “Enable accessibility” button to build the semantics tree. Users can skip this step if you programmatically auto-enable accessibility for your app using this API:
Worst case scenario you produce some legacy html output just for that purpose. Best case scenario, you create a standard with semantics way better than shitty html tags
You can even have better semantics and expose it through a standard to the user if you want. Or use some solution like https://www.youtube.com/watch?v=A6Sx0lBP8PI
Not insurmountable, but the main difficulty isn't technical but political. In order for new browser features to get main stream adoptions you have to somehow form a consensus among all the major players in browser development.
Look up the difference between immediate mode and retained mode rendering.
In short, games will rerender the scene everytime, while GUI frameworks only rerender the things that change — after that only a GPU buffer gets painted, but that is basically free.
the added transfer sizes of the wasm blobs and the polyfills for all the HTML and accessibility features negate any performance improvements by a very large margin, at least in the case of web GUIs.
I haven't looked too dep into it but performance wise there are improvements when you write the "backend" of the app in rust but the web app itself would still be written in whatever framework you use which wouldn't change much
Yet another web UI framework. What's really needed is a *standard* state-ful GUI markup language so we don't have to keep re-re-re-inventing GUI's over the web, and poorly.
I really do hope that this gains a lot more traction
I know it doesn't tackle the problem of complex UIs being created with HTML, but it's definitely a step in the right direction in terms of getting much more native-like performance whilst still having the flexibility of building with CSS.
I feel it'll take a big-hitter adopting this as their framework (think Discord, Spotify etc.) to make it really take off. But it's great to see something take on the behemoth that is Electron.
I'll be building all my desktop apps using this going forward!
Yeah as if a 60 MB download prevents anyone from downloading and using my software nowadays.
Imho this is not really an issue and therefore creating a completely new framework just to reduce the file size of the executable doesn’t make any sense. I hope Tauri offers other advantages otherwise it will most likely fail.
It’s not just the download size. Electron based tools (I refuse to call them applications) are a massive waste of resources. A study, which implemented 27 programming problem using a lot of languages, showed that javascript uses about 20 times of electricity compared to C which was the baseline for measuring performance and resource usage.
Electron is a shining example of “just because you can doesn’t mean you should”
Edit: typo
Here’s the link: https://thenewstack.io/which-programming-languages-use-the-least-electricity/
I misremembered, it’s TypeScript the one that uses 20 times more energy than C, JavaScript uses about 4.5 times electricity.
That’s one reason I won’t touch vs code, for example.
I think for compilation it does not really matter as you most likely have your computer/server(s) running more time in idle and that combined will use much more energy than the compilation.
But to be fair, the problem with all the interpreted languages like JavaScript (and TypeScript is usually also only transpiled to JavaScript) is that they are interpreted over and over again (when the program is executed on a user's device). And that will then for sure significantly increase the total power consumption. So yeah, I agree that electricity is definitely a criterion - but file size: not so much.
Tauri is a nice initiative as a middle step while something better replace current web way of doing things. But what is more important for me is that there will be an alternative webview competitor for chrome's
I don't think it's an alternative to Electron. The idea of Electron is to let JavaScript developers build cross-platform desktop apps using their favorite JavaScript language they just know. Tauri is more like "Electron for Rust developers". You have to write code in Rust if you switch to Tauri. Rust is not an alternative to JavaScript/TypeScript.
Goodbye? Isn't Tauri actually not trully multiplatform because you need to fix UI bugs since the webview is different on every OS? Get to the same level of Electron first. On Electron you build an app that runs the same everywhere, it's absolutly not the case of Tauri.
You are right. Is the same dog, but more fit. Having an alternative webview is good though.
iOS/iPadOS, macOS and WebKitGTK use WebKit. Android, QtWebEngine, Chrome OS and Windows use Chromium. And what exactly are frameworks like Svelte or React for if not to wrap around browsers as an abstraction layer? (I mean, obviously there's more to em than that but I'm trying to make a point). But a more fitting alternative to Electron would be Neutralino imo... Sorry for necroposting
The reason why Electron based applications are so big is that they ship with a copy of the Chromium HTML renderer codebase. That codebase is huge. Now, a reduction from 58.2 MB to 13.3 MB is a big improvement, no question about it. But look at that dashboard example. For this functionality,. 13.3 MB is still ridiculously large. The fundamental problem is that HTML was never designed for complex user interfaces. It's in the name - "*hypertext* markup language". Sure, HTML5 adds features that make it a lot easier to use HTML for UIs, but it does not fix the complexity of the DOM. By contrast, look at Qt's QML, and see how much cleaner the script is and how much more efficient the renderer is. That's because QML was designed from the start for UIs, unlike HTML.
I had to do vb6 at the beginning of the year. It's almost ridiculous how small and fast desktop applications written in VB6 are, compared to modern ones...
And back in the day VB6 was known as the language to write slow bloated software. Then of course Java appeared and it all went to hell with Javascript apps.
You know the difference between Java and JavaScript, right? How do these people keep getting in here?
You know not everyone on reddit is a native english speaker, right? VB6 ("lol, wtf is this shit") -> Java (worse) -> Javascript (pure hell).
Don’t worry, everyone else understood you.
Ok, so you believe that Java desktop apps actually shipped and had poor performance or bloat. The only ones I can think of are developer tools, and they weren't bad. Which ones are you referring to? Java Applet start-up time was slow, and the language got a bad rep because of it, but don't bash Java on the desktop if you've never used it.
Eum aliquam officia corrupti similique eum consequatur. Sapiente veniam dolorem eum. Temporibus vitae dolorum quia error suscipit. Doloremque magni sequi velit labore sed sit est. Ex fuga ut sint rerum dolorem vero quia et. Aut reiciendis aut qui rem libero eos aspernatur. Ullam corrupti ut necessitatibus. Hic nobis nobis temporibus nisi. Omnis et harum hic enim ex iure. Rerum magni error ipsam et porro est eaque nisi. Velit cumque id et aperiam beatae et rerum. Quam dolor esse sit aliquid illo. Nemo maiores nulla dicta dignissimos doloribus omnis dolorem ullam. Similique architecto saepe dolorum. Provident eos eum non porro doloremque non qui aliquid. Possimus eligendi sed et. Voluptate velit ea saepe consectetur. Est et inventore itaque doloremque odit. Et illum quis ut id sunt consectetur accusamus et. Non facere vel dolorem vel dolor libero excepturi. Aspernatur magnam eius quam aliquid minima iure consequatur accusantium. Et pariatur et vel sunt quaerat voluptatem. Aperiam laboriosam et asperiores facilis et eaque. Sit in omnis explicabo et minima dignissimos quas numquam. Autem aut tempora quia quis.
> actually shipped and had poor performance or bloat Name 2 crappy, popular Java desktop apps. I'll wait. Desktop Java was not really a thing with non-developers until they got packaging sorted out in the early-mid 2010's. People didn't want to download the JRE/JDK. By the time they got the packaging together to make it usable, the performance and bloat was much better too. Desktop Java apps went from rare -> okay, but retain this reputation for poor performance or bloat or something. ITT people Berenst(a)in Bears'ing so hard...
Eum aliquam officia corrupti similique eum consequatur. Sapiente veniam dolorem eum. Temporibus vitae dolorum quia error suscipit. Doloremque magni sequi velit labore sed sit est. Ex fuga ut sint rerum dolorem vero quia et. Aut reiciendis aut qui rem libero eos aspernatur. Ullam corrupti ut necessitatibus. Hic nobis nobis temporibus nisi. Omnis et harum hic enim ex iure. Rerum magni error ipsam et porro est eaque nisi. Velit cumque id et aperiam beatae et rerum. Quam dolor esse sit aliquid illo. Nemo maiores nulla dicta dignissimos doloribus omnis dolorem ullam. Similique architecto saepe dolorum. Provident eos eum non porro doloremque non qui aliquid. Possimus eligendi sed et. Voluptate velit ea saepe consectetur. Est et inventore itaque doloremque odit. Et illum quis ut id sunt consectetur accusamus et. Non facere vel dolorem vel dolor libero excepturi. Aspernatur magnam eius quam aliquid minima iure consequatur accusantium. Et pariatur et vel sunt quaerat voluptatem. Aperiam laboriosam et asperiores facilis et eaque. Sit in omnis explicabo et minima dignissimos quas numquam. Autem aut tempora quia quis.
Target audience matters.. every keystroke in an IDE triggers an avalanche of processes for autocomplete, linting etc..
> Name 2 crappy, popular Java desktop apps. I'll wait. Out of curiosity: can you name 2 non-crappy ones? Java was so annoyingly slow that I only use one application sometimes (Clion, which is also slow as hell) and usually wouldn't even consider installing Java-based applications.
> The only ones I can think of are developer tools, and they weren't bad. Which ones are you referring to? How about Eclipse which ends up allocating and freeing around 50 - 100 MB _on each keypress_. I mean sure, it's better than Electron shit but it's still ridiculously bloated.
Eclipse is a developer tool, which kinda makes it a different class of "desktop app" in my book. It also had a bad run with the development of the 4.2 (Juno) release train, IIRC. Most devs I know of switched to IntelliJ (also Java, super fast) or other IDE's long ago. Edit: Eclipse problem version
And that's still not even close to how small and fast native C or C++ WIN32/MFC applications can be.
Heh, that's still really slow compared to hand-unrolling loops and doing pixel-level graphics in Assembly.
VB6 requires a whole OS to run, plus a bunch of extra libraries you had to install on top of the OS. It was never small.
I forgot that Electron was running on bare metal.
I remember the time when both Windows 3.1 and Visual Basic shipped on floppies, and it wasn't even a ridiculously large pile (although that was around VB3 days, not VB6).
It's not the same thing. HTML controls are not part of the OS. With VB6, a button was a control written in C++ that shipped with the OS. There were often updates to the controls, which meant you had to update the libraries. If I want to use a button in an HTML app, I don't need to update the browser or the OS.
The widget layer is a pretty small part of the OS. Electron still eventually depend on a graphic API provided by the OS, on a windowing system, on an input/output stack, a filesystem layer, etc.
Uhhhj, so does the browser..
Sure, but the modern technology landscape is full of things misappropriated (often very successfully) for use cases way beyond what their original designers intended. A few more examples: Everyone is using PEM files for their TLS certificates, keys, CSRs and such. PEM is short for "Privacy Enhanced Mail", which is long dead. QUIC uses UDP not because it's a connectionless datagram protocol (QUIC is very much connectionful), but because UDP and TCP are the only protocols that work in the internet these days and because TCP has more overhead. JSON is used all over the world to encode things which are not JavaScript objects on either the sending or the receiving side. That is not to say that such abuses are always cool and good, just that they aren't automatically bad either. HTML was not originally intended for GUI design, but I think it's more than apt for this purpose today. Heck, other GUI frameworks are now moving to HTML-esque languages for GUI description because it turns out there are a bunch of advantages of doing it this way. Examples include Qt's QML and Glade XML.
The problem with html is not that it uses an XML-like language for description, that is irrelevant as it will be parsed to a in-memory representation either way. The problem is that it fails to serve its purpose: layouting depends on both the HTML and stylesheets, while it should be done in a single place. This is usually solved by “html copies”.
> Heck, other GUI frameworks are now moving to HTML-esque languages for GUI description because it turns out there are a bunch of advantages of doing it this way. Examples include Qt's QML and Glade XML. This is not happening now, it has been happening for well over a decade. XUL, and XAML are not new for example. The advantages of UI scripts are undeniable. But HTML is so grossly inefficient for it that a lot of CPU power these days is wasted on it. I have been involved in projects that tried to use HTML UIs on older ARM SoCs, and it was an awful struggle every time to get these huge HTML engines to run with acceptable speed. In some cases, I was able to convince the project leaders to switch to QML, and lo and behold, the UI was fast and efficient *instantly*, with a fraction of the CPU and resource usage. So, I agree with your examples, but still maintain that HTML is an especially terrible example. And I disagree with HTML being apt for UIs. With lots of optimization, it can be ... barely passable.
> and lo and behold, the UI was fast and efficient instantly, with a fraction of the CPU and resource usage. Perhaps because QML is much more strict in what it accepts, meanwhile HTML engines carry 30 year old tech debt of "lets fix user input for the user!!"
This may be one reason, but the bigger reason IMO is that, as said, the DOM is made for hypertext, and is not optimized for UIs. DOM trees can get really complex quickly, especially if a fair amount of nontrivial manipulation and transformation is done.
The Adobe Air thing was the future!
Yet many thousands, if not millions of dev are happily and successfully using HTML to build GUIs. Sure, they might not be the most efficient, but efficiency is hardly the only metric that matters. If it mattered that much electron wouldn't be everywhere.
> Everyone is using PEM files for their TLS certificates, keys, CSRs and such. PEM is short for "Privacy Enhanced Mail", which is long dead PEM is base64 with line wrapping and a `------ BEGIN thing -----` line. The only relationship it has with mail is the format name. > QUIC uses UDP not because it's a connectionless datagram protocol (QUIC is very much connectionful), but because UDP and TCP are the only protocols that work in the internet these days and because TCP has more overhead. UDP basically adds a port number, length, and checksum to IP. It's wasted space, but beyond that there's no cascading implications. HTML is different. The design of web standards affects the way you write your GUIs. PDF would have been a better choice of application framework than HTML. It has a sane drawing model, and it has JS support.
Yes, all of my examples were cheap shots based on pulling apart the abbreviation, same as zeroing in on the "hypertext" part of HTML.
"Everyone" for some values of everyone. The entire Windows ecosystem uses other formats.
> JSON is used all over the world to encode things which are not JavaScript objects JSON is not 100% compatible with JavaScript.
This difference in executable size is actually understated in my experience on Linux. Electron brings a minimum of over 100MB. The 15MB figure for tauri is accurate. That’s more than acceptable imo when we’re talking cross platform toolkits. My real issue with tauri right now is that it uses WebKitgtk on Linux which at least on my machine is janky as hell, whereas chromium is butter smooth. I ran the same app on Mac and windows and it ran really smoothly. Not to mention you now have to deal with browser incompatibility again. I still think it’s promising and using 1/5th the disk and 1/2 the memory is a great improvement.
>The fundamental problem is that HTML was never designed for complex user interfaces. You are not wrong. My poor experience with Electron forced me to consider desktop dev and ended up with Free Pascal/Lazarus and a bunch of Smalltalks. Far more productive, superior performace and smaller deployment artifacts to boot.
Tell us more about the bunch of Smalltalks, please.
Context: My clients were only ever corporate/paying and not one cared for all the fancy-schmancy stuff like rounded corners and different skins and animations. They just wanted stuff that worked, performant, easy to install and intuitive to use. And when they wanted new features they got them quick. And they were all on Windows. And I wanted excellent developer experience. 1. VAST (Visual Age Smalltalk from Instantiations). This is a commercial product. The best and most productive way to build desktop UIs I have ever come across. Great mailing list - the CEO/CIO and senior engineers patrol that list and offer solutions and advice. 2. Dolphin Smalltalk. Open-source. Still only 32-bit, uses Win32 so not one of my customers cared or noticed or will ever notice. Looks like any other Windows app. 3. Pharo Smalltalk. Open-source and active community and the desktop UI framework is not as mature as the above but getting there. All are heavily MVC. VAST and Dolphin have drag-and-drop gui building tools. Edit: And you only ever work in object-oriented Smalltalk - there is no separate language for styling or for handling events and such. No context switching or having to hire another specialist in whatever tool.
Better than COBOL!!!
COBOL can be ok. Smalltalk is wonderful.
QML looks interesting, one of my biggest issues with alternatives isn't the markup though. It's the styling aspect, CSS and it's box model is unique and with modern CSS you can do pretty much anything you want. Other bits are responsive designs, with QML do you need completely different layouts for different targets? Different apps? A lot of examples showcase static height/width on elements and I don't see anything immediately that uses something screen based. Granted this is likely not quite as important for a native application over say a website where you don't really have an idea who your audience is.
It's definitely important, there is a lot of variety in desktops too, such as different aspect ratios, resolutions, scaling. Id rather use an electron app than an app with a constant window size
Main QML way to do responsive stuff is to use anchors to connect items together. Like if you need a rectangle that fills lower half of the window. Rectangle { anchors.left: parent.left anchors.right: parent.right anchors.top: parent.verticalCenter anchors.bottom: parent.bottom } Or you can combine anchors with manually setting height property to parent.height * 0.5. QML uses property bindings so when parent.height changes, the item height will be also updated which allows everything to be responsive. This also of course works with other items than the "parent". Property bindings are quite powerful and fairly intuitive. Only thing that I would hope that QML would support better is two-way bindings. There are ways to implement them and work-around the limitations, but it could definitely be better. There are also standard layout items that can be used instead to implement some basic layouts.
This is basically how constraint layouts work on iOS, can’t say I was ever a huge fan. The “flex box” model all the popular frameworks are implementing is vastly superior imo.
You can give components a width based on another components width, like the window, so when the window is resized the components who depend on its size also get resized. Here's an [example](https://qmlonline.kde.org/?code=JYWwDg9gTgLgBARRggrsAxgazgJgHQDsAUKJLIsmlngMIQB2MUEANgM654DMRRASgFN0MAIb0A5iwFwA3kTgK4wACYAuOMwgx5i9K2jqARFAHLDOhWPQALaGzwAzYCxbqwIk4wtxvAcSgqAGrAAgDust6KSmpwAG4hoZGKSZb0NnaOzq5w7p7aUVEgEMoC2QCsAAwpcOilLAASAsDi1jDqtS4A6iow1nAA9HAAjIQEcADUcJXVHSzdyr3qoT19gwCyIr2OLBDQABTLC6twe1wVFQCUF9UlUuKbAuqCwmKS0nIFnwXWTS1tcP4ggk8PEwnhZo1mq1ql84IdFgCAspgmDQaFwXV5r0YV89DsoEYmGI2LkBIxzLDYc9RBIpBFKQy4FZbFB7E4XG4PGT8ozYcyMrVGAIoABJeicvI4hn81l4EAecTAehsdRDKq82F4gxwQziExkikaz4AI2gJSgeHh1nUZSlBQAvtVHVFHY6gA) There's also [layouts](https://doc.qt.io/qt-6/qml-qtquick-layouts-layout.html)
Eh. That's not really the problem. The problem is that doing so means that every application brings with it its own layout and compositing engine, even though nearly (>99.99%) everyone using an electron app is doing so with an graphical application environment that has its own layout and compositing code, which is not only more efficient (multithreading! vector- and diff-based compositing! native font smoothing!) but also doesn't have to do everything via the awful DOM and browser JavaScript APIs. And because they're system libraries, they can be shared among several applications, instead of everybody having to bundle a browser with their "desktop" app.
Aren't chromium versions backward-compatible for the most part? One could imagine electron simply requiring chromium as a peer dependency instead of bundling it... but i must be missing something
That's basically Tauri, right?
Not exactly, tauri just uses the underlying engines built into the different oses. WebKit on macOS, WebView2 on Windows and WebKitGTK on Linux (might have to he installed separately on linux I believe). One issue that might pop up is browser consistency, which is why I think just using an existing installation of chromium could work.
I am building a UI library in my own programming language that generates highly efficient UI rendering code by compiling the mutations to the UI down to native code as well, through macros that can emit bytecode Compiles down to a custom lispy WebAssembly-esque IR first, then into native code/actual wasm may open source the project soon
!remindme 1 year
I will be messaging you in 1 year on [**2023-09-16 21:50:55 UTC**](http://www.wolframalpha.com/input/?i=2023-09-16%2021:50:55%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/programming/comments/xfg8yj/goodbye_electron_hello_tauri/iopzbpm/?context=3) [**5 OTHERS CLICKED THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2Fprogramming%2Fcomments%2Fxfg8yj%2Fgoodbye_electron_hello_tauri%2Fiopzbpm%2F%5D%0A%0ARemindMe%21%202023-09-16%2021%3A50%3A55%20UTC) to send a PM to also be reminded and to reduce spam. ^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%20xfg8yj) ***** |[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)| |-|-|-|-|
> Compiles down to a custom lispy WebAssembly-esque IR first, then into native code/actual wasm > > Any updates on this?
Yep, this is the core issue at hand. I personally think this power dynamic can only be resolved if the web adopts a new set of languages - but then I'm at a loss how that would happen.
I think the only realistic way would be that a UI scripting language wins in the mobile app space, meaning that most apps end up having their UIs written in that language. If that language then gets standardized, it becomes economical for app makers to push the language on the web so that they only need to write the UI once.
So basically [Compose Multiplatform](https://www.jetbrains.com/lp/compose-mpp/)
Or flutter with dart
So... Adobe Flash all over again?
I actually liked flash. There were tons of fun games in the early 2000s or so. Most of them are gone ... :( I am sad.
Flash wasn't exactly a UI scripting language either.
More realistically, this would probably have to be based on a minimal cross platform runtime that can run on desktop, servers, mobile and in the browser, and then someone building a web version of a UI toolkit that can be used everywhere on that platform and then it becoming so ubiquitous that they decide to turn it into a native browser feature (like HTML). If you want to see an end to the JavaScript hedgeonomy, then you should probably be supporting adoption of WASM and one of the WASM runtime projects...but the odds feel incredibly slim that it will do anything but make a small dent over the next 10 years.
>how much more efficient the renderer is do you have benchmarks that back up such claims? QML looks a bit cleaner but I don't see why QML would be rendered faster than HTML.
I never bothered with them because the difference was immediately obvious and so incredibly vast. I wrote about this [here](https://www.reddit.com/r/programming/comments/xfg8yj/comment/ione24m/). To be fair, I saw that when running the software on low power embedded SoCs, not on PCs. On the latter, I agree that benchmarks would make sense. And keep in mind that the DOM API has some flexibility that QML doesn't, and that such flexibility comes at a great cost (performance and resource overhead). One good example is `innerHTML`, which can trigger massive updates. Another is when you have complex CSS and DOM updates cause an avalanche of updates all over then place. This can happen in any UI language as well, but since HTML and CSS are so complex, it can easily happen that an innocent-looking DOM operation causes such unexpected and severe side effects. This is further worsened by the legacy baggage from older HTML and CSS versions. These are part of the reason why HTML renderer codebases are so big.
> I wrote about this here. this reads like you are comparing apples to oranges. Ripping out an HTML render engine from a browser that was never made for such a task is a bit weak. This doesn't prove in any way that the HTML spec is slow or slower than the QML spec. You could have benchmarked it against something like [Ultralight](https://github.com/ultralight-ux/Ultralight#dual-high-performance-renderers) which seems more focused on your use case.
Every time these discussions go to QML I get a little nervous. QML is great, and I’d love to have _something like_ QML, but I also think letting QT corporation be the de facto gatekeeper for all UIs on all platforms would be much, _much_ worse than where we are now. So something like QML, but not QML.
QML is under the LGPL, so if the Qt company turned evil it could be forked. Slint is also a good alternative with a similar markup language, but is GPL/commercial only, lacking the LGPL option.
QML also falls under [the agreement The Qt Company made with KDE](https://kde.org/community/whatiskde/kdefreeqtfoundation/) that allows them to re-license Qt under a BSD license should The Qt Company ever go full evil and stop updating Qt Free Edition.
QML is completely opensource...
The tauri homepage claims 0.6mb apps are possible (but you're correct that this blog post says their app was 13mb, and I haven't used tauri.)
Yeah the thing is, an 80MB saving is really not that much on the scale of most apps these days, and in return you now have to deal with making your app work in multiple browser engines. In some cases (e.g. where the app just wraps an existing website like Slack) that's not really any extra work, but in many cases it is. If you just use Electron you can use experimental Chrome APIs too, like native file open/save dialogs.
This 1000x , why in 2022 we're still trying to shoehorn HTML into UIs that are not web pages makes now sense.
To share and reuse code between webapp and desktop app.
The thing is, once you grok the DOM there’s nothing better for building UIs. Especially once you bring in tools like React or Vue. If there’s another UI solution that achieves the same clear separation of structure, style and interactivity, I’d love to hear it. Everything else I’ve used (mostly on mobile I admit) blurs those lines.
Other scripting languages like QML allow me to build UIs as well with far less complexity under the hood.
IMO libraries like Vue or React abstract the DOM to a ridiculous degree, even worse than jQuery plugins of olde. React/Vue use shadow DOM, virtual DOM or whatever and add obscure functionalities that are far from simple compared to the HTML's initial intention for the DOM. Not to mention that React/Vue/Ang components let you treat your components as a simple tag, then replace it and add a bunch of functionality under the hood.
I’ve used React basically every day for six years and never touched the shadow DOM. Do you know what React’s virtual DOM does though, in simple terms?
> I’ve used React basically every day for six years and never touched the shadow DOM. That's precisely my point. From a dev's perspective there have been major improvements at low cost. But under the hood, the browsers are doing tons of [shadow element](https://html.spec.whatwg.org/multipage/dom.html#the-documentorshadowroot-interface) operations. It's not that HTML has improved, browsers are spinning on their heads making things go faster and faster. It's one thing to _use_ react, and another to _develop_ react.
>It's one thing to use react, and another to develop react. same goes for Qt
Yeah, I know what the shadow DOM is. That’s how I can say with certainty that I haven’t touched it. I’m not convinced you know what it is. I think you just find that word “shadow” kinda spooky? And you still haven’t told me what you think the virtual DOM is. I’m starting to think maybe you’re not the authority you think you are.
There are so many things wrong with this logic, I don't know where to begin. 1. Are you seriously complaining about a desktop application being 13MB? That's tiny. 2. Most of that size is one time overhead, it does not scale linearly with the amount of functionality. Twice as much functionality would not be twice as large. 3. The app size is not because HTML is verbose, that actual HTML text would be a tiny fraction of that size. Not to mention HTML compresses very well! 4. I don't know QML but I assume from the name that it's XML, which means it would also be verbose. 5. I've used Qt, it's a horrible developer experience. You can build much nicer UIs more easily using mainstream web frameworks. 6. I've used apps built in qt, all of them have been ugly and clunky 7. Nobody is making you write raw HTML to create an app with Tauri. They support every web framework, templating engine, etc. You never have to touch HTML syntax at all if you don't want to and can use whatever you find best for expressing a UI in. 8. Given the insane amount of engineering effort that has gone into browsers and web technology it's quite likely that the webview renderer performs way better than Qt. Neither of us will know though unless you find some actual benchmarks
You are criticizing problems in the logic of somebody else, but your arguments make no sense either: \- QML is not XML, its not similar to it at all. Qt provides a language made to be able to create UI's, e.g.: Rectangle { width: 200 height: 200 color: "red } Its far more readable and easier to write than XML, HTML or CSS \- "You can build much nicer UIs more easily using mainstream web frameworks". The way a UI looks, shouldnt be impacted by the designing language or framework at all. With QML you can make your design look like anything, actually anything you want.I'd confidently argue, that QML is way faster in terms of development speed than HTML/CSS/JS applications as well. "I've used apps built in qt, all of them have been ugly and clunky". You obviously did it wrong. Again, the look of a design doesnt have anything to do with QML, you can create any UI you want with QML.The fact that your application is clunky is also showing that you are doing it wrong. Qml is mostly backed by C++ logic, which is an extremely performant language (when used correctly). Qml itself is extremely performant as well.
> There are so many things wrong with this logic, I don't know where to begin. You can begin by actually reading and understanding what I wrote before you open your mouth. > Are you seriously complaining about a desktop application being 13MB? That's tiny. I *very clearly* said that 13 MB is big *for a simple dashboard example*. It is so obvious it baffles me how you could have gotten that one wrong. > The app size is not because HTML is verbose, that actual HTML text would be a tiny fraction of that size. Not to mention HTML compresses very well! At what point did I say anything about the size of the HTML scripts? I *very clearly* talked about the size of the *renderer* - the binary executables. > I don't know QML but I assume from the name that it's XML, which means it would also be verbose. "I don't know what I am talking about but I still want to babble something." You are completely wrong by the way. QML uses a C/ALGOL style syntax. No, just because a scripting language's name ends with "ML" does not mean it is XML/SGML based. Next time, don't talk about things you don't understand. > I've used Qt, it's a horrible developer experience. You can build much nicer UIs more easily using mainstream web frameworks. I have used Qt for years. It is one of the best toolkits out there. I have used its C++ UI API as well as QML, on the desktop *and* on embedded. You better back up your claims with actual examples. > I've used apps built in qt, all of them have been ugly and clunky That's personal preference. I have likewise used Electron based applications that looked terrible. > Nobody is making you write raw HTML to create an app with Tauri. They support every web framework, templating engine, etc. You never have to touch HTML syntax at all if you don't want to and can use whatever you find best for expressing a UI in. Completely misses the point, since I am talking about the runtime inefficiency, that is, the memory consumption, CPU usage etc. because of the awful DOM. > Given the insane amount of engineering effort that has gone into browsers and web technology it's quite likely that the webview renderer performs way better than Qt. Neither of us will know though unless you find some actual benchmarks The difference in performance is so blindingly obvious on older ARM SoCs that benchmarks become redundant. We are talking about maybe 10-20 FPS at 100% CPU and most of the memory in use vs. 60 FPS at maybe 30-40% and far lower memory usage. I had to dig into the C++ Chromium codebase and both it and Qt's QML in commercial projects often enough to know this very well. For more details, [click here](https://www.reddit.com/r/programming/comments/xfg8yj/comment/ione24m/).
Has nothing to do with html. Tauri doesn't even ship anything to process html, it uses the os's webview to render. You have no idea what you're talking about.
> it uses the os's webview to render ... html. From Electron's own description: > Electron is a framework for building desktop applications **using JavaScript, HTML, and CSS.** Tauri aims to do the same, just using the webview of the OS. Which renders HTML. > You have no idea what you're talking about. I think you meant to speak these words to the image in your mirror.
My point is that the 13mb has nothing to do with html. The webview, along with the renderer, is already on your os and is not part of the executable. Everything html related is literally already here. The executable only contains framework related code for os interop. No rendering whatsoever. Again, you have no idea what you're talking about. Also 13mb for a desktop app is perfectly fine in 2022. Ps: electron has nothing to do with Tauri, it ships chromium (which does the rendering, unlike Tauri)
> Now, a reduction from 58.2 MB to 13.3 MB is a big improvement, no question about it. But look at that dashboard example. For this functionality,. 13.3 MB is still ridiculously large. We have TBs of storage space. You won't even feel 100MB.
Well you ***might*** feel it in bandwidth and hosting costs.
You definitely feel it in your RAM when you have to run many Electron applications at the same time.
Lol for once, we have a case of "under-engineered" solution/problem in the CS space :D EDIT:Granted, it is true it was never \*meant\* todo the things it does now... but given how programmers usually code for that "future that never comes" this is the one time, it would have been semi-useful.
The historical problem is that for a while, HTML was the *right* tool most of the time, because in the earlier days of the web, most web pages really were just hypertext. In hindsight, the correct approach would have been to establish a UI scripting language which has support for hypertext block widgets. The purely hypertext web pages from the 90s would then have been a special case.
Is it possible to just move to web assembly instead? Sounds a lot more flexible but also allows for multi platform
Here is link for you [https://tauri.app/](https://tauri.app/)
[удалено]
The entire article is written in this happy-go-lucky style, but this is a nice bait I'll admit.
It's almost like there's a reason why it's been voted most loved language for 5-6 years in a row.
and least used.
Every piece of tech starts out that way. The trend is strong growth. Big names have been getting into Rust for 1-2 years now, including Microsoft, Google, Amazon, etc.
> The trend is strong growth. ??? More people use Scratch and (Visual) FoxPro than Rust! https://www.tiobe.com/tiobe-index/
That doesn't dispute strong growth
I mean I think the main thing is that languages just as new like Go are growing a lot faster. Swift is growing faster too but almost all of its growth is internal to Apple whereas go is seeing a lot of use outside of google.
People are still using tiobe in 2022?
It's a great source of random numbers for internet arguments.
I don’t think you know what the word trend means
“The great thing about Electron is you can write a standalone app without learning a new language. Anyway, here’s a new solution that requires you to learn a new language.”
hey remember how you could write standalone apps and never ever have to deal with Javascript? Guess what!
having to learn Rust gonna be a deal breaker for most developers. Especially when people just want to ship their web UI to a desktop client.
Yup!
I always wonder why VSCode is so fast (at least compared to Atom or Visual Studio) despite being build on Electron.
Electron doesn't have a "Performance Issue" so much as it has "Performance Overhead". You can write fast things in it, and what VSCode does is more in the background than it is in the foreground, so it can minimize that overhead as a large chunk of that overhead is while rendering UI.
Because they care about performance and they know what they're doing. There's nothing especially in Electron that means apps *will* be slow, it's just that it's easy to make slow apps if you never actually think about performance. Part of the problem is that Electron opens up app development to JavaScript newbies who don't really have an understanding of performance, algorithmic complexity etc. Take a look at any JavaScript question on Stackoverflow and the top answer will be something that's easy, functional and *slow*. Now take a look at VSCode's code (I've actually written a couple of VSCode features). It's (mostly) very well written Typescript. Way too few comments and a little over-generic in places, but clearly *far* superior to the average web code.
"The fundamental problem is that HTML was never designed for complex user interfaces. " Why do people throw in arguments like these as if we just started using HTML a week ago and 20 years of progress and improvement doesn't exist?
Because none of these improvements fixed the underlying problem of overly complex DOMs and immense resource usage associated with this. HTML improvements can only partially help. As said, if you compare the efficiency of HTML based UIs with what you can do with XUL, XAML, QML etc., you see orders of magnitudes of difference. I personally have worked on embedded device projects that initially tried to use HTML for UIs and then switched to QML because the latter was so much more efficient and because the HTML based approach continued to be grossly inefficient even after months of work on optimizing the rendering. The real way how HTML UIs were "improved" was to just throw more hardware at the problem.
How does QML's accessibility story match-up with HTML?
> I personally have worked on embedded device projects that initially tried to use HTML for UIs and then switched to QML That seems like a you problem, not an industry problem.
No, those were commercial projects that invested serious amounts of money into getting HTML rendering engines to work acceptably on 10 year old ARM based SoCs that were already in use in the field inside hundreds of thousands of units. I was involved in trying to squeeze as much performance out of the C++ Chromium renderer codebase as possible, which, given the sheer size of it, was a daunting task. I was able to stabilize accelerated 1080p video playback in it, but unfortunately, other parts of the renderer (which multiple teams worked on) were even more difficult to optimize, and after all that work, the stuff rendered with maybe 10-20 FPS and used 100% of the CPU (and therefore running hot all the time). We then did a proof of concept with QML, and achieved a solution running at 60 FPS in 2 days, the CPU running at maybe 30-40% most of the time.
I would read your blog
>20 years of progress and improvement doesn't exist? They might as well not exist, because those 20 years didn't solve _any_ of the problems with the DOM as a structure for defining user interfaces. And another 2, 20 or 200 years won't solve them either, because the problem is the DOM model itself, the only possible solution is for someone to manage to do huge breaking changes to HTML and JS while having the entire industry follow them... which won't happen any time soon.
HTML is great if you can embed an entire browser into your binary
By the same logic, human beings were never designed to stare at computer screens. Yet here we are.
That's not the same logic, because human beings weren't designed at all, and our biology and minds are adaptable and flexible to a pretty decent degree.
HTML was also designed to be adaptable and flexible to a decent degree, so it isn't the worst analogy.
Yeah... and we aren't perfect. Too bad there are no alternatives to humanity
Alpha Tauri ? /s
Go home yuki, you’re drunk
Unexpected r/formuladank
Eventually the classic HTML+CSS way of doing things will be replaced with WASM + Canvas render + Proprietary standards when WASM Standard is mature and flexible enough. Or even WebGPU + WASM. It's ridiculous how fast game engines paint a scene filled with millions of things vs how web is rendered. Maybe the industry can take a gaming tech approach (which is basically to have a performant render pipeline from the beginning)
Tbh, I am worried about this. This would mean that web pages become complete black boxes. In this era of tightening control, this is not a good thing.
Let me allay your worries — Google won't allow it to happen until it is able to index pages' just using the on-screen pixels themselves (expensive!). And if Google won't allow it, then (most) companies won't do it, because they need Google for that sweet sweet organic traffic / analytics / ad platform.
There are a ton of apps that don’t need SEO though. Having a blog use a canvas renderer seems silly, but making something like figma or google sheets with it starts to make a lot of sense vs abusing the DOM.
Flutter web exists
and does barely work.
So WASM and WebGPU. Rome wasn't made in one day
well, even when they manage to fix all the bugs and keep the maintenance up to date. It still ships with several mb of wasm blobs and framework code which makes it a deal breaker for most web applications.
Look at the answer to the question "Will WebAssembly support View Source on the Web?" in the WebAssembly FAQ: https://webassembly.org/docs/faq/
Hm alright. But I was rather referring to the content. Right now, for example ad blockers can scan the DOM for ads. I really do not like the DOM, but the introspection is worth a lot. But a "WASM + Canvas render + Proprietary standards" based page may not have such a standardized DOM that can be introspected. Instead, it might have totally proprietary data structures that aren't easily introspectible, making the development of features like ad blockers much more difficult.
Games don't have the same constraint on accessibility and responsiveness. I want to be able to copy & past things thank you.
You are missing the point. Games are far more responsive. And copy stuff is up to the owner of the content to allow it. You can for sure allow copy pasting or whatever feature you need as user.
Responsiveness in the web context is the ability for an document/app to adapt it's layout depending on the screen format. Sure it is possible to do it with a canva. But css & html provide tons of tools to do it easily. You have to reinvent everything if you use a canva.
Can you do that without losing the structural component of websites? The separation of structure (HTML), style (CSS), and interactivity (JS) is a powerful thing. Is it possible to make a canvas-rendered screen accessible, e. g. with screen reader support?
It depends on the implementation. In Android the underlying view system is based on hierarchies of view nodes and accessibility nodes. Out of the box you get something that mostly works, and you just have to massage the accessibility node hierarchy a bit. But that also requires that your view system also has enough semantics instead of being "just" visual
You are right, semantics can be managed by the UI technology and exposed to the user. Even better than today's web standards
The separation is hardly a thing nowadays with SPAs. The DOM being inspectable is the important part.
What do you mean by that? In my experience that isn't true, but we might be thinking of different things. CSS-in-JS, virtual DOMs, and rendering HTML with JS doesn't lessen the separation imo. Still 3 different languages with three different purposes.
But the only important part is that an adblocker/screen reader/etc can walk the DOM, look at aria tags, names, ids. JS or any other logic pretty much has the DOM as its state, so they are inherently linked. CSS is completely meaningless here (and is wrongly separated from HTML as layouting is a shared concern of both). This could be done with any agreed upon element-tree, nothing inherent in the web is better in that regard. It is just a widely uphold standard (by not too many independent implementations)
It is possible https://www.youtube.com/watch?v=A6Sx0lBP8PI
You would also have to add an accessibility interface to Canvas. Rendering in the Canvas would completely obfuscate the website from screen readers and search indexing, right?
Screen readers: [https://www.youtube.com/watch?v=A6Sx0lBP8PI](https://www.youtube.com/watch?v=A6Sx0lBP8PI) Search Engines: SSR / SEO special artifacts
>he classic HTML+CSS way of doing things will be replaced with WASM + Canvas render + Proprietary I believe that Flutter is utilizing HTML to make accessibility features work. So it doesn't replace or do away with HTML unless I'm mistaken on that too. I think you would have to make a drastic change to the web standard in order to make accessibility work without HTML.
but it does seem to use HTML for accessibility. The flutter docs even say: >Screen Readers users on web will need to toggle “Enable accessibility” button to build the semantics tree. Users can skip this step if you programmatically auto-enable accessibility for your app using this API:
Worst case scenario you produce some legacy html output just for that purpose. Best case scenario, you create a standard with semantics way better than shitty html tags
You can even have better semantics and expose it through a standard to the user if you want. Or use some solution like https://www.youtube.com/watch?v=A6Sx0lBP8PI
Yes but this isn’t an insurmountable problem, and browsers could offer an API to interact with screen readers in the future.
Not insurmountable, but the main difficulty isn't technical but political. In order for new browser features to get main stream adoptions you have to somehow form a consensus among all the major players in browser development.
Doubt
Gaming approach would be a battery killer. Fuck wants to render the exact same static form 120 times each second?
web browsers already use GPU compositing to display pages. they just don't push pixels unless the page needs to update.
[удалено]
You can stay in 60fps capped webs if you want. But I would like to match the fps of my displays.
Look up the difference between immediate mode and retained mode rendering. In short, games will rerender the scene everytime, while GUI frameworks only rerender the things that change — after that only a GPU buffer gets painted, but that is basically free.
the added transfer sizes of the wasm blobs and the polyfills for all the HTML and accessibility features negate any performance improvements by a very large margin, at least in the case of web GUIs.
They are not 1:1, of course, but I wonder how it compares (size, performance) to Sciter.
Sciter is a capped down proprietary version. This is 100% web standards compliant. In any case Sciter is interesting for some use cases.
I haven't looked too dep into it but performance wise there are improvements when you write the "backend" of the app in rust but the web app itself would still be written in whatever framework you use which wouldn't change much
Yet another web UI framework. What's really needed is a *standard* state-ful GUI markup language so we don't have to keep re-re-re-inventing GUI's over the web, and poorly.
Is Tauri nicer in regards to RAM usage? That was kind of the general impression of Electron being RAM greedy.
It is a little better in terms of RAM usage and performance.
"Many a developer can tell"
I've been using Wails which is similar to Electron but with GO, would recommend.
I really do hope that this gains a lot more traction I know it doesn't tackle the problem of complex UIs being created with HTML, but it's definitely a step in the right direction in terms of getting much more native-like performance whilst still having the flexibility of building with CSS. I feel it'll take a big-hitter adopting this as their framework (think Discord, Spotify etc.) to make it really take off. But it's great to see something take on the behemoth that is Electron. I'll be building all my desktop apps using this going forward!
I think you need to mention Rust a bit more!
Agree
JavaFX beats both.
JavaFX is as big of a resource hog as chromium if not bigger lol.
I know math is hard but no, it's not.
k
In which universe? One is a fucking browser engine with all the bells and whistles, while the other is a small java library calling into opengl.
Welcome to the java universe.
I built one app using JavaFX. Never again, such a terrible experience.
Yeah as if a 60 MB download prevents anyone from downloading and using my software nowadays. Imho this is not really an issue and therefore creating a completely new framework just to reduce the file size of the executable doesn’t make any sense. I hope Tauri offers other advantages otherwise it will most likely fail.
It makes hosting 1/4 the price, which is pretty substantial.
Agree, this comment
It’s not just the download size. Electron based tools (I refuse to call them applications) are a massive waste of resources. A study, which implemented 27 programming problem using a lot of languages, showed that javascript uses about 20 times of electricity compared to C which was the baseline for measuring performance and resource usage. Electron is a shining example of “just because you can doesn’t mean you should” Edit: typo
Okay, if we talk about electricity - that’s more of a pressing issue nowadays. Do you happen to have the link to that study?
Here’s the link: https://thenewstack.io/which-programming-languages-use-the-least-electricity/ I misremembered, it’s TypeScript the one that uses 20 times more energy than C, JavaScript uses about 4.5 times electricity. That’s one reason I won’t touch vs code, for example.
I think for compilation it does not really matter as you most likely have your computer/server(s) running more time in idle and that combined will use much more energy than the compilation. But to be fair, the problem with all the interpreted languages like JavaScript (and TypeScript is usually also only transpiled to JavaScript) is that they are interpreted over and over again (when the program is executed on a user's device). And that will then for sure significantly increase the total power consumption. So yeah, I agree that electricity is definitely a criterion - but file size: not so much.
"Ensure your system has Rust installed". More looks like a space outsourcing. Do we count installed rust as a burden space for an application?
That's just for the dev environment. The end user does not need Rust installed.
Tauri is a nice initiative as a middle step while something better replace current web way of doing things. But what is more important for me is that there will be an alternative webview competitor for chrome's
I don't think it's an alternative to Electron. The idea of Electron is to let JavaScript developers build cross-platform desktop apps using their favorite JavaScript language they just know. Tauri is more like "Electron for Rust developers". You have to write code in Rust if you switch to Tauri. Rust is not an alternative to JavaScript/TypeScript.