No question, just a small commendation. It pleases me that you acted appropriately to the criticism about Tauri not being native and removed this previously advertised claim.
Assuming you meant Deno, we used Node for the CLI because most web devs already have npm installed. We want the getting started process to be as simple as possible. Our Node CLI is just a wrapper really, as nearly all of the commands are actually implemented in Rust. You don't even need Node to build a Tauri app anymore. Node is not including in a shipped Tauri app, although we plan on supporting both Node and Deno as optional replacements for Rust in the future.
They use whatever is the system WebView on the platform you run the code on. On Windows that's the Edge engine, on MacOS it's Safari's engine, etc. Those are all some combination of C and C++.
I can’t speak for other developers but my app runs on electron and the web (because why not?), so I need to make sure my app works with those browsers as well.
A lot of the big electron apps I’m aware of are the same (slack, notion, discord, etc).
Electron has two "sides" to it — a renderer process, and a NodeJS process, that communicate over IPC (where as far as the renderer is concerned, the NodeJS process is kind of like a very intrusive browser extension.)
AFAIK, if you're writing a greenfield Electron app, it's best to do as little as possible in the renderer side, and as much as possible in the Node.js side, because the Node.js side has things like native threads and mmap(2), and everything running within the Node.js process can share that state, but things on the renderer side have to use it through RPC.
I would assume that this project is similar, but with arbitrary Rust code in place of Node.js (is that right?)
In that case, it doesn't matter how featureful the renderer is, as you're just using it as a GUI framework with a declarative view-model format. Just like a XAML or QML, but it's HTML+CSS.
As such, idiomatically, you won't be using fancy browser APIs like threads or WebRTC within the renderer; instead, you'll be using native code on the "app side" and then passing the renderer data. The features of Tauri itself are "whatever native libraries you want to bring into your Rust binary." (Plus whatever conveniences it already builds in, of course.)
This is actually untrue, you want to do as much as possible in the renderer process. The main NodeJS process is responsible for all user interaction, including mouse clicks and keyboard input. If you block the main process, the entire app will become unresponsive
But the main NodeJS process can spawn (regular POSIX) worker threads, just like any other GUI app’s main (event loop) process; and those worker threads can both 1. load native libraries and call into them, and 2. communicate just as directly with the renderer as the main thread can. The renderer, meanwhile, only gives you ServiceWorkers; and those can’t do anything natively. (Plus, they have all the same IPC overhead to the main renderer context that calling the renderer from Node does.)
Think of it like this: let’s say you’re creating an Electron equivalent to Mathematica. You have a big native blob of maths evaluation code. Where are you going to run it — in the renderer (as Emscripten WASM) or in a worker thread of the native app (as a native static library or DLL)?
Or let’s say you’re doing an Electron BitTorrent client. Where are you going to handle the network connections and do the file management and... basically everything the app does? Well, in this case, you have no real option: the renderer can’t open raw TCP sockets. You’ve got to do it native. (But it would have been the better choice anyway, for IOPS reasons—localStorage + virtualized attachment downloads don’t buy you very much disk concurrency.)
A less clear-cut case is a game engine. The answer there depends on whether you can get a handle to the renderer’s Canvas from your native code. If so, then the choice is obvious: native game engine, draw to renderer’s canvas. If not, it might still be more CPU efficient to go native: you might be able to approximate that over RPC if your game has a bandwidth-efficient wire protocol representation of its render command stream (as e.g. most 2D tile based games do.) Only if neither of these work would putting the game engine into the renderer be optimal.
So basically on Windows it will use Edge. The idea is good, but this is not the first time someone try this. At the end it is all about testing, tools that needs to make 100% ( not 99% or 99.99% ) sure functions and rendering on all platform are intended as it is.
So you need to make sure your code works on 3 different platform eventhough you're using a tool that's supposed to fix that problem in the first place?
I don't know the extend of WebView in Electron is it something common?
A ton of time and resources have been put into making web apps work across multiple rendering engines. These days, it can be difficult to have something break on one platform if you are using a modern development stack. The webview engines that Tauri uses are all quite modern, see https://github.com/tauri-apps/wry/discussions/202 for more details.
Worse, it needs to run on every version on every os. Windows 10 has an evergreen webview, but on Mac for compatibility reasons the webview is only updated with a new OS release.
Edit: This is not something you run into with electron. It's the reason electron apps are so big, they bundle the whole browser engine.
I see how the second part of my comment seemed like I'm asking for "Rust in the front-end", that was not my intention. My main point stands though, requiring Rust is not necessarily a "Con", it's in the "Pros" list for many people
It's off-topic, but it would be nice for someone to make a really good GUI toolkit for Rust. Something that integrates with system APIs for copy-paste and stuff like that.
I'm finishing this (no XUL tough), but the first impl(developer language) is in Swift. But the runtime the Swift access is pure C shims, so any other language can benefit from it.
If anyone is interested, it would be much easier to create those bindings to Rust. I'm super interested (and i would probably create a Rust SDK anyway) and there's a lot of other bonuses that neither Electron or Tauri can offer (as i target it not to be "just" a web-based app platform, but something that also had the soul of web browsers, by forming networks, addresses, etc).
If anyone is curious, there is more disclosure in another answer on this same thread.
i would love to give new all of those cool new languages that need a platform to thrive: Rust, Zig, Crystal, (and while not new) Python, a chance to have a 360 ecosystem, so we can stop being hostage of just Javascript being used.. and no, WebAssembly is definitely not it, as in the end it will give Javascript access to FFMPEG and the likes making it more prominent and ubiquitous
I’ve seen this before, and I still have no idea what it does.
If it’s an electron alternative, is it too much to ask to show an image of a webapp running on a desktop (preverably a variation of every OS) front and center on the landing page?
I’d like to see it working immediately, without needing to watch any videos.
I would be much more interested in a Gecko/Servo alternative to Electron than a native webview alternative.
Not that I don't also acknowledge the need for that, but my application is dramatically faster in Firefox than Chrome, yet we're stuck packaging a suboptimal experience in the desktop app because Chromium is our only option.
As a developer of an Electron app to me a competing framework that doesn't bundle its own rendering engine doesn't make sense, why would I want to trade control over how my app is rendered for ~100MB of disk space?
I might as well just ship a website at that point, almost everything that makes Electron appealing comes from shipping your own rendering engine.
Apple's brand new iMacs with the M1 CPU only have 8 GB of RAM.
If every little desktop widget loads its own browser engine, most of that RAM will be spent on redundant copies of Chromium.
If your Electron app is something that you expect users to run almost exclusively, then no problem. If it's just another little client app for some service, please consider a solution that would reduce its memory footprint.
That's a fair point, but just ship a website then, much easier and pretty much same result.
It makes sense to use frameworks like Electron if they enable new capabilities for your app, and Electron is very good at that, bundling Node.js with it, which allows you to share code between frontend and backend and tap into the same ecosystem of packages, plus chances are you already know Node.js, Tauri is enabling 0 of this, at least presently.
Actually better results even, because under macOS for example the webview is provided by Safari, but if you are using Chrome/Firefox as your browser of choice and you are using a Tauri app now you are using 2 browsers effectively, while if you ship a website you can use that website with whatever browser you prefer.
Order of magnitude memory reduction, not disk space, was the selling point last time I heard. And given how often I hear users complaining about memory consumption in Electron apps, I think that is something pretty attractive, if it pans out.
That doesn't make sense to me, you are still using a browser at the end of the day. Sure you can save some memory by not bundling Node (at the cost of making even reading a file much more difficult), but that's not orders of magnitudes.
> Also electron require multiple node backend services which each eat memory like crazy (based on electron app I use).
AFAIK Electron requires 1 Node instance (you can disable it for renderer processes and you can have 0 WebWorkers or only WebWorkers with Node.js disabled) which consumes like ~50MB or something like that, which probably accounts for stuff other than Node.js too, if the app you are using require multiple Node processes that use huge amounts of memory they are just badly written.
> Have one, real Multithreaded +, more efficient backend, will reduce memory and offer better performance.
You can't just share Node.js across multiple apps, Tauri just doesn't bundle it at all, which is a whole different story with mostly downsides from my point of view.
Of those apps I can only say that VS Code is well written and that Spotify is junk.
Is 600mb too much for VS Code? I guess it depends on what you are doing with it and which extensions you have installed etc., if you are running a pretty bare-bones installation and seeing 1GB+ memory usages in VS Code please open an issue in their issue tracker and tag me (same username as in HN).
> Slack is much better than it was.
And that didn't happen by switching to the website approach, I think you'll be disappointed if any of these apps end up switching to Tauri or Wails without significantly improving their code too. Which is why I'd predict no major player will jump ship.
for my work, vscode take between 1.5 to 2.5gb. Nothing has change since start using it 4 years ago, and my experience is consistent with my coworkers. I keep using it because it 'feels' the best overall. No magical issue will fix that, node is memory hungry as is java.
Calling an app junk to justify is argument is unconvincing. Its still a widely used app that works as good as the competition. In the case of slack, their optimisation endeavour seems to cost them quite a lot. But sure I don't have the number. If they would have start the project in Tauri or Wails at the beginning, would that saved them the refactoring? I don't now. But we will need more team using that kind of alternative to gain the knowledge and real benefit.
At this point I rewriting a toy project from electron to wails and its great. But well, it's only a toy project.
That sounds like a lot, you are probably running some heavy extensions or too many of them I guess, could you post a screenshot of the "process explorer" window for your instance of vscode?
> Calling an app junk to justify is argument is unconvincing.
I couldn't care less about what you think about Electron, that's just what I think.
That's a good point, that will save you some memory unless you happen to be in a scenario where for example you use Chrome under macOS and a single Tauri app, which would then use Safari under the hood, meaning still multiple browsers.
But I think that would save much less memory than people think. A bare-bones hello-world Electron app consumes about ~100MB of RAM (rough figure since it depends on many factors), maybe you can bring that down to ~20MB by sharing a common browser instance (I doubt it, a Chrome tab takes like ~50MB for me right now), but if your app uses 1GB+ of memory that has way more to do with how the app is coded than by having to spawn another instance of the browser. Basically you won't get a memory hungry app consuming 10x less memory by running it as a website.
Not if you take one of the biggest selling points of Electron.
Im working on something not quite the same thing but that deal with all this, and being able to ship with a web rendering engine and not using whatever its on the system is actually better giving all the power, bindings, compromise you can make that you are unable when you can only deal with a abstract wrapper to every web rendering engine out there.
Lower memory footprint but with much less features and a generic "no sir, cant do such a thing.." as a answer to users that will need important features to ship applications with this.
Of course it's less convenient for developers not to ship a rendering engine. But should developers' need always come before users' needs, especially for applications that live and run on their own PCs?
Its not also about user needs, given the final application will have access to more functionality, also guaranteeing things will work.
I agree that Electron is user hostile in the way it uses memory, but there's an answer in between the Electron and what Tauri is offering here.
Tauri could have a embedded engine and yet propose a better architecture and better use of memory in consequence. The best of both worlds.
In Chrome for instance, each tab is equivalent to a app, giving is a whole isolated process and yet it doesnt kill your machine even with many tabs open.
That's irrelevant, just because I can't do some things on iOS doesn't mean that I shouldn't do them under desktop OS' too.
Just one example: file system watching, if I need to do that with Electron I'll just use `chokidar` and have it working in no time, plus I can share whatever frontend code with the backend too, good luck doing the same with Tauri (given the current state of things anyway).
> it depends how much you respect your users
I don't know what kind of users you've got but mine care about me iterating quickly on the app, care about having new features, care about having a faster app. Most of them would consider trading any of that for ~100MB of disk space stupid.
As I said, if disk space is all you care about you might as well just ship a website.
It's about memory management more than it is binary size. Rust is notorious for being turbo-charged with every LLVM optimization on gods green earth, so much so that the actual syntax of the language is beholden to the opinion of the compiler. Either way, I see it as a great step in the right direction, and would be perfect for apps like Discord or Spotify.
> Tauri is a toolkit that helps developers make applications for the major desktop platforms - using virtually any frontend framework in existence. The core is built with Rust and the CLI leverages Node.js making Tauri a genuinely polyglot approach to creating and maintaining great apps.
Electron doesn't have an equivalent "about" page, but instead has this paragraph on its home page:
> It's easier than you think: If you can build a website, you can build a desktop app. Electron is a framework for creating native applications with web technologies like JavaScript, HTML, and CSS. It takes care of the hard parts so you can focus on the core of your application.
"virtually any frontend framework" "polyglot" vs. "takes care of the hard parts"
They don't say "JavaScript, HTML, and CSS" because it isn't just JavaScript, HTML, and CSS. It's any technology that can run in the browser, such as Yew or Maple for example. Arguably those Rust-based frontend libraries are the main focus, even, over something like React.
FLOSS also means a different thing from Open Source because of the "Libre" aspect.
I don't see why being different is considered bad here, as its whole shtick is that it's an alternative.
Exactly my thoughts. I feel like Tauri is trying to let Rust carry the project instead of writing decent marketing materials. Really the only thing I see on Tauri's site that makes me want to use it is Rust, while I can see many value props on Electron's site.
Please keep in mind that this project just reached _beta_. We are working to implement valuable feedback from the community, so please don't expect things like the landing page to be as polished as an 8 year old project.
Shout out to all of the hardworking people behind Tauri. ♥
I don't get the push for rust as a front-end language, it's very distracting with a lot of low-level features.
Can we just stick with "best tool for the job"?
Rust for performance-critical systems and, say, typescript for front-end? Using a single language for everything is a wet dream that always ends up in complexity and more work as you're fighting the "native" ecosystem.
Maybe you should spend like 5 minutes looking into the thing you're critiquing before critiquing it? Just a suggestion, given that Tauri literally uses typescript for front-end.
Normally I'm on the defensive side for the JS ecosystem on Hacker News, but not today. While it's still the best option for web app development productivity right now, there are woefully bad issues with the Node ecosystem, from poor or lack of documentation for complex build tools to zero contracts between dependencies. Rust has the advantage of being able to break if things seem to not fit together. It's a popular language for more use-cases than just performance-critical applications even if it supports that.
This is not really about JS, if I want to replace JS I'll pick a language with similar characteristics that make it successful. Similar to how you replace C++ with rust, another language that gives you control of memory. For app developments they are simplicity and a focus on domain modelling with a good type system (this is typescript teritory), NOT memory safey.
And don't tell me that rust's type system is powerful too, yes, but it's also complex and the focus isn't domain modelling. Like C++ and golang's type systems, it's there to aid the compilers/borrow checker, not developers.
Example of such language in my other comment: kotlin, F#
I think Typescript won't check that two of your dependencies are compatible with each other; it will only check that your app is compatible with dependencies. Even then, the check isn't very strong, since TypeScript operates on a "as you want it" basis, which is nice in some ways but also means you could get overly permissive behavior, especially if you're using third party typings, which is fairly common.
> the focus isn't domain modelling, like C++ and golang's type systems
Could you please explain what you mean by this? I've honestly not heard this argument before so I'd be interested what domain modeling Rust doesn't encourage/support that, e.g. Go does.
I'm not saying that go and C++ have better type systems. I'm saying like rust, their type systems are built to aid the compiler. High-level languages like ocaml or f# have type systems made for domain modeling
I would disagree. Types like `Result<T,E>` or `Option<T>` exist purely for the user; the compiler doesn't care that there is a convention for errors, nor would it be that bad for a compiler to have `nil` (there are certainly a bunch of compilers that can handle it). There are a number of convenience types available such as `Rc` which does reference counting. If `Rc` didn't exist, you could still survive and write the same applications, it's just that it would be more cumbersome.
His point is that Rust is not user-friendly with a unnecessary cognitive load for user facing applications.
I don't know why this comment section derails into the language properties and technical merits, giving its pretty simple to recognize that.
The HN crowd might be above average and might tend to think that Rust is an easy enough language, but the reality for most people is that languages with the amount of complexity of the likes of Rust, C++ and Scala are not easy for the "average programmer" and we are not even talking about the people that just don't want to deal with unnecessary complexity.
Really, almost any GC'ed language out there is a better pick for this sort of task (except the ones that are poorly designed for this, like Go).
The point is not to be "easy;" environments that value being easy are environments that encourage bugs. The whole ethos of Rust is safety and thoroughness. True, it's not as user-friendly, if your definition of user friendly is "runs at any cost." If instead however you take the definition as "allows you to easily write programs that work right," it is probably one of the easiest languages.
You speak of "unnecessary complexity" like the complexity was just pulled out of thin air for the purpose of making Rust harder; no, the complexity is inherent to building a functioning application, the difference is whether it lives in your head or it lives in the compiler. Personally I'd rather the compiler handle things like bookkeeping, moving memory around, checking that the types and cardinalities are right, and ensuring errors are handled rather than repeatedly having to debug those things at runtime in an extremely slow and punishing feedback loop.
Its unnecessary complexity for the paradigm we are talking about, that is user facing, mostly UI applications.
Its necessary for system programming, and as we can see people talk about it whenever C++, C, OSes, Browsers, Games, etc.. are being talked about because it works really well in those domains.
But when you are building a UI, C#, Kotlin, Swift, Typescript and even Java are much more productive with good speed, safe (even safer than Rust), and with language constructions that map really well to this domain.
Rust achieved a very good set of features, but unfortunately the price is its complexity, which is a burden you don't need to take when you are creating UI's.
Sure you and i (im mostly a C++ dev) can use it to make UI's, but unless you are creating something really complex that needs every drop of performance and memory, like big Games or a Photoshop, you don't need this productivity and HR tax(its much harder to find people in C++ and Rust) that languages like Rust and C++ ask of you.
There's no such a thing as one language to rule them all, and Rust will not the best candidate for domains it was not designed for. Swift for instance is much better at this and with a very good performance, where it would also be a good fit for a Photoshop clone or a browser.
It's strange that some people view UIs as being some of the simplest software. Once you've considered the state management, asynchronous nature (meaning your code could be run in many different permutations), graphical elements (graphics' complexity upper bound being equivalent to what you might see in a video game), legacy APIs (old browsers, shims, or old OSes), and IO such as network requests, it ends up being incredibly complex. The number of hours I've seen being spent fighting Webpack are uncounted. From where I'm standing, it's clear the complexity is already there, it's just totally unmanaged.
Rust will make a great UI language once the ecosystem has matured and async has gotten polished more. If upgrading the "Webpack" of the future meant just resolving compiler errors, we would be in a much better world. Same goes for upgrading dependencies on the frontend, which at my company becomes a blocker every 2 weeks or so due to the NPM security advisories being released, accompanied by the total lack of visibility into the dependencies' interplay that the Node ecosystem gives you.
I'm not saying that Rust is not a good language for UI, and im also not saying UI is simple. The problem is that you are just comparing it to JavaScript which is untyped and easy to beat.
In my case i'm comparing it with languages that are also powerful, safe, fast and more well designed for this kind of scenario, which JavaScript or Python aren't.
But if i had just two picks, between JavaScript or Rust, of course i would choose Rust without blinking. But once there is more options.. (in this case you can read my comments above).
And i agree with you, that if you sum it all, maybe you get more productive (as in ready to ship) in Rust than with JavaScript.
Note that even with Scala's complexity, the language's focus is first and foremost domain modelling & expressiveness.
Rust is first and foremost, a language for memory safety and raw performance, it just happens to have some level of expressiveness. Nothing wrong with that either.
Could you re-read my comments, I think go is a very lame language, at no point I said it would be good for anything. You're not convincing anyone by picking on low bar like C#, javascript & go to make rust seem like a good language for UI programming.
You know, there are people like me that just can't stand Javascript. TypeScript is somewhat acceptable, but knowing Rust, I just prefer to use it anyway. It is just better.
One difference is to be able to ditch Javascript and use a native language(Swift is the first one) to talk directly to webkit.
The other difference is that the apps are "managed" as Chrome manages the renderer process, so in the end you have one manager process and one service process for each app and many process for the UI apps.
The problem with Electron is that for each app, it will need many processes, and if you have more than one Electron app running, it will eat all the resources.
With the architecture proposed, it will be more light as there will be just one instance of the manager processes, and unlike Electron they would not be isolated as they are all centrally managed, also the fact that it wont need to use JS, will also put less pressure on memory resources.
It also uses RPC so that every app have a API that can be callable by others. This in turn can make it form a "network of apps" where the applications can consume the apis of the other apps installed. The RPC service is local first, but can fetch things in the "cloud" if the application needs to.
For me this is my take on what "Web 3.0" should look like.
I have a 0.1 version here and i'm just finishing the final
touches before launching it..
Edit: Also i forgot to mention that the distribution of the application and resources(database and files) is over torrent with DHT routing, so you can share a unique address and serve your own applications over internet without depending on domains or a third-party hosting it for you.
Nice! If I understand correctly, the renderer process is shared across all apps, each app is either a service or a UI process, and all of the apps export an API that's routable from the local machine. Is that right?
Its like this:
You have one manager process and one GPU process for everyone. (Mind you that this is chrome based, but its quite modified i must say).
Then for each application:
You have a "service process" which is instantiated and is always running, this process asks for the manager to create its rpc service server. Then every rpc call is routed to it.
This application service process is already coded by the developer so he defines what every api does and also how it respond to resources like pages, images, videos, etc..
(it also uses RPC by default to route resources.. but its through HTTP/2 giving its gRPC/Protobuf)
This process, totally in control of the dev code also can hijack its own application launches, so its in charge of app launching and killing (from its own scope)
Then theres the UI process which is akin to renderer and its also coded by the dev, where the renderer is in Swift so totally customizable (Imagine being able to control the C++ renderer events, lifetime, frames, etc.. of the chrome renderer process; in this case you do, with Swift), giving you have a lot of power.
The developer control, codes and ship the service and the ui app. Once its installed, even without any UI, all other applications can consume its services over its RPC api, because there is a 'service process' running and serving those requests (imagine being able to deal with twitter or a google search api (all local and with the same tech) from your app that is specialized in something else)
You've got alternatives like Flutter and ReveryUI which are both pretty solid for building cross platform applications without using web technologies or webviews.
And you can always just use some of the other GUI toolkits that have been coming out recently.
Deno is on our roadmap, but the focus right now is performance, flushing out features, and performing a security audit. As was also said, Rust is used to bundle your app.
Like Electron, with Tauri you write your GUIs with HTML, CSS, and Javascript. Electron uses Node for the client-side non-GUI functionality, while Tauri instead uses Rust binaries to accomplish same. That's the alternative part. Node is not needed at all in the final build, although it may be used to create your app before bundling for release.
Maybe we need to be more clear about how nodejs CAN be used in the construction of a Tauri app, and that it is neither a requirement to make a Tauri app nor a component that is shipped with a Tauri app.
Will FOSS and uh... indiscriminate distros face hurdles to bundling this? If this is good with interacting with CLI, Linux distros could experience a Cambrian explosion of GUIs. Ubuntu's flutter installer project could get leapfrogged.
I don't care about your YouTube videos, I don't care about your governance, I don't care about your book, tell me what it is in non-marketing speak and show me a screenshot on the front page and shut up about everything else.
Tell me what it is, show me what it looks like, provide a "Hello, World!" API example for opening a window on the front page. Stop contributing to landing pages that jerk the consumer around.
Please don't break the HN guidelines like this. Fulminating, fault-finding, blaming rants hit on everyone's indignation and attract upvotes, and when we end up being a site where this is the top comment on the top submission, and the whole place fills up with toxic fumes. This isn't the community any of us wants to have.
Yes, you're right. It's direct in an abrasive way, but I give specific actionable feedback about how to improve, and I'm not sorry.
I want people to be direct about how my projects need to improve, because I know how it doesn't meet my standards, but I don't know how it fails to meet other people's standards, which is more important if you're concerned with adoption.
> Tell me what it is, show me what it looks like, provide a "Hello, World!" API example for opening a window on the front page. Stop contributing to landing pages that jerk the consumer around.
They've got a point. Time to cut through the hype, get straight to the point and show some screenshots to catch their eyes.
If you can't manage that, the tab gets closed with in 5 seconds. Even if it has the Rust buzzword. (Because that trick always works on HN)
> ...the Tauri-team incubated and maintained WRY, which creates a unified interface to the system webview (and other goodies like Menu and Taskbar), leveraging WebKit on macOS, WebView2 on Windows and WebKitGTK on Linux.
Doesn't using the "system" webview throw out the main selling point of Electron, which is that you're shipping the browser, so you no longer need to support more than one of them?
Perhaps, but using the system webview also means that you don't have massive amounts of bloat, both in distribution and on-disk size as well as memory usage, and you have a better chance at getting better performance.
Besides, all of the relevant engines are WebKit variants, so you're not targeting Trident or Gecko or anything.
Bear in mind that a lot of popular "apps", like Slack, Discord, etc., are web apps anyway, so there's a decent chance that the "support more than one of them" problem is already solved anyway, meaning you don't have to spend any more development time but you get huge increases in performance and responsiveness.
That is very true, and it's a nice differentiator relative to Electron— you still get your own app launcher and access to system APIs, but without shipping and launching the entirety of Chromium.
Came here to say this. It's a site designed for idiots not engineers. How does rendering work? Can't even tell if it's HTML based or some hipster immediate UI toolkit nobody's heard of. What do I need to give up to get a 640kb binary? etc etc.
Answering my own question, https://github.com/tauri-apps/wry , so looks like it loses one of the advantages of Electron in that you control the exact browser in use. Maybe that's incorrect. Who knows? Web site appears to not exist to provide such important details.
Like I wrote in another response, we are due for a landing page revamp, and we'll be sure to make a "nothing but the facts" hero for people like yourself who are concerned that their time is being wasted.
It's not for "people like me," it's for everyone. In terms of volume of traffic you're going to get, no one else cares about this stuff.
Here's an example of one of my projects where I do just that: https://www.planimeter.org/grid-sdk/ Literally! I tell people what my team has built. I show them a screenshot. I then provide API examples. Mine could be better if I provided screenshots per API example, too. Everyone can improve.
Your audience is technical, they don't want a non-technical pitch. Tell me it's faster than Electron, show me RAM usage comparisons, etc.
We actually had this at an earlier stage during the alpha, but got so caught up in the alpha that we just plain forgot to put the apps for mac, win and linux back up there. We'll try to get that done this weekend. We have a full "API Explorer" app that we built...
You're going to do great. Just steer the ship back in the direction of the elevator pitch experience. After that 20-30 second experience, if people are interested in more (provide Getting Started at the end of all of that, not the beginning,) they will click on it and want to learn more about what you have to offer.
Avoid putting things in people's face before they've gotten to know you. You're not trying to be a food blog throwing pop-ups in people's faces about how they need to subscribe to your newsletter. You're trying to be a competitor to Electron.
Here's what their website tells me what they do:
> Build cross-platform desktop apps with JavaScript, HTML, and CSS
Ah! OK. I'm interested. And see how specific they are? Don't be vague. Don't say "web front-end," what do you mean? React? They then show me screenshots! Of what big companies built!
Then. They provide a Getting Started section. Not great, could be better. I want to see how it's used. But this is the bar. Be better than that bar.
Edit: Even Electron's site provides Getting Started at the end.
Having the getting started button at the end is a good idea I think, we'll look into that.
We say "web frontend" because that's as descriptive as we can be really. We support any web framework that runs in a browser. As for screenshots of big companies' apps, we don't have any major companies that have adopted Tauri yet, as we just came out of alpha, but we will add a section like that as soon as we can.
It's difficult for us to demonstrate how Tauri is used in short snippets that could fit at the beginning of the Getting Started section. Electron's site doesn't have any code snippets either, just snippets for installing via npm and some example apps.
I understand the difficulties of competing with incumbents because size and usage are not your strong points yet, sort of. You all have over 16k stars on GitHub as a proxy for interest! My team still has under 1k.
It also doesn't help that we chose a language that isn't popular. But you all need to think about how decision making like that massively effects adoption.
You won't learn these lessons quickly, they take years, so ignore people who say you need to experiment and research what works. The biggest issues you'll face is that no one will tell you what's wrong unless you're faced with it in threads like this on HN or other places where you'll meet consumers.
The worst part of it is, these are the obnoxious glaring details. There might be massive decisions you make that consumers can't pinpoint for you. Thought-leaders don't often describe those details because of survivorship bias.
What I can see this team failing at, too, is that you need an anchor client. You're spending all this time on BS that doesn't mean anything at all.
Specifically, at GitHub, they already had users using Atom, which made for a great way to advertise Electron. It was Atom!
You need to essentially find whales (Read: engineering leaders at businesses) and make the product good enough for one of them to say, yeah I'll use this over Electron, and if they're an attractive user, pump them on your front page. Find a way to make a deal with them so that you can funnel developers to their hiring channels.
The engine is multiplayer first because you don't have to write any special code to implement it. When you start a game, if you set maxplayers to something beyond 1, it's multiplayer automatically.
When you create entities in the engine, all you have to do is specify what fields you want networked, and the game engine automatically serializes deltas for you on that field as they change.
It takes care of more advanced field networking like prediction as well.
You focus on making things, not making them networkable. If you want that, you just say it's networked. That's it.
Maybe you should put that pitch up there on the starting page, because personally I find it too bland. The screenshot doesn't tell me anything, might as well not put it up there.
If you scroll down to the roadmap, you can see that system trays are supported. We don't yet support native context menus, but that would be a relatively simple addition. Our GitHub readme has a table comparing Electron's and Tauri's features, do you think it would be useful to include that on the website landing page?
I think if time on page and average session metrics suggested that's what people wanted, that's what we would see. It's like complaining about how the news reports on inane stuff.
Sounds like a case of bad metrics. Time on page when your goal is to get people to use your software/framework isn't meaningful. In fact, I suspect better communication leads to shorter times.
Similar idea with news. The objectives of profit and conveying meaningful information aren't necessarily aligned.
Disregarding the subjectivity of 'meaningful,' the advice 'know your target audience' is good from both a product design and marketing presentation stand point.
I think that for both examples, having people's attention is a precursor to doing anything else. That's just my intuition though.
Maybe it is possible to have a landing page that people leave much more quickly but that is more successful. Maybe it is possible to keep your audience informed without them watching for very long.
You are assuming they have done analysis and A/B testing. More likely they simply copied the approach of consumer products, without thinking too deeply about the fact that developers are their only users.
There's this silly game a play sometimes: I go to producthunt.com, open a bunch of links and, then, try to guess what each of them does. I fail most of the time.
Wow you're right. I thought you were exaggerating a bit because there's a "Get started" button right there. But even clicking that I had to drill down through multiple badly named pages just to find the part that describes how the Rust portion of this works. Why is the selling point of this not shoved in your face from the second you load the page.
"Tauri is a toolkit that helps developers make applications for the major desktop platforms - using virtually any frontend framework in existence. The core is built with Rust and the CLI leverages Node.js making Tauri a genuinely polyglot approach to creating and maintaining great apps."
That's the first paragraph on the About page. Landing pages have multiple purposes and need to address different types of viewers, not just the neckbeards. The marketing speak is likely more for convincing IT manages this is a legit project and does not have common "deal breakers".
> The marketing speak is likely more for convincing IT manages this is a legit project and does not have common "deal breakers".
If this is the case, it's an excellent reason to not use Tauri. Making their decisions based on what IT managers want to read rather than what developers need to do their job? Good luck with that, might work in some bubbles but the rest of the world is trying to be productive.
Nope. Landing pages have one purpose, to funnel you further down into adoption or allow you a place to access things you've already adopted. That's it. Everything else is noise.
TL;DR Build native apps from JS by wrapping in a web view. Aside from native dependencies required during development for whatever playform you're building:
I'll admit you'll probably have a couple extra configuration steps in there. But I found it much easier to get started than with Electron and the resulting app seems pretty slick.
https://dev.to/tauri/announcing-tauri-beta-more-efficient-cr...