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.

https://news.ycombinator.com/newsguidelines.html

Sure thing, I'll edit the post. Edit: Oh, OK, well nevermind then.

This is unbelievably harsh, and "your landing page sucks" is the most boring comment people can make on HN posts.

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.

See my other post in this thread for an example.

> 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)

I dug around, and the only screenshots I can find are on a few project pages that use it.

But of course, there is not much to see, it's just a window with a web view inside of it.

https://guijs.dev/ https://github.com/samirdjelal/bidirectional/ https://github.com/mmpneo/simple-obs-stt

It's a webview wrapper.

> ...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.

https://github.com/tauri-apps/tauri

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.

https://github.com/tauri-apps/tauri/blob/dev/ARCHITECTURE.md could lose a few thousand words, but this seems to be the real starting off point

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.

> for people like yourself

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...

https://github.com/tauri-apps/tauri/tree/dev/examples/api

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.

Great landing page. Straight to the point. OT question: what makes the engine multiplayer-first?

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.

The page is simple, yet it doesn't even render anything but the menu without javascript.

TBH it was pretty frustrating and also for me it was a waste of time.

Even though the project itself sounds very promising, because "Rust" and "Electron alternative".

But how can I know if it really is an Electron replacement if I'm not even sure if I can create native context menus or integrate it into the SysTray?

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?

So it would make sense to split the roadmap into what already exists, and call that the feature list, and the rest can remain as the roadmap.

Then provide screenshots/code samples for each item in the feature list.

That sounds like a solution. Or just add some screenshots/code samples to what is already implemented in the roadmap.

I don't think it's so much 'nothing but the facts' but rather a little more effort to explain 'what it is'.

It's not that the site is 'marketing speak', it's just that it's a 3/10 on communications.

Even two sentences at the top would help.

I've spent a minute on it and I'm not sure what it is.

It's a way to make apps, but it doesn't have a front end? I don't even know what that means.

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.

I actually thought it wasn't that bad. Some landing pages leave me utterly bewildered, but this one didn't.

Also, I liked the way they presented their roadmap.

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.

They are nowhere near ready for pitching IT managers. The only thing that matters right now is winning developer interest.

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.

You just listed two purposes.

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:

  yarn add @tauri-apps/cli
  yarn tauri init
  yarn tauri build

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.

I came here to ask, “where is the screenshot?”