Hacker News Reader

Comment by danpalmer | Hacker News Reader

We're moving in the direction of apps being a bit like games: a fast native core that's relatively generic and platform specific but available on major platforms, and "scripting" that's cross-platform and specific to the application and use-cases being solved.

If we agree that this is a useful approach to take for developing cross-platform applications, and I think it is for most, are web technologies the best way to achieve this or is there a better alternative?

Web tech has the advantage that when you don't have that "game engine" you can still run in a browser, but with these engines getting better, more storage, more use of app stores, and the fact that these apps are very much that, apps, and not publicly indexable web content, maybe this isn't a useful advantage anymore? Web tech also brings a number of disadvantages, such as a different security model and unnecessary legacy compatibility that holds back modernisation.

View on HN

I hope we learn the lesson of Blizzard but it doesn't seem we really are.

For the scripted part of the application, you can allow 3rd party plugins. If you do, you should keep tabs on the success of different solutions in this Marketplace of Ideas. You should absorb (probably native code) the ideas with the broadest appeal. But don't forget to find a way to compensate the person whose plugin you just deprecated.

Anything you don't know will stick, should be done on the cheap, and in a problem space where porting is expensive, scripting seems to be the winning strategy. And some commentary from various game authors suggests to me that the scripting language also opens up some development parallelism that is harder to get with an API.

We get the majority of the features of jQuery in HTML 5, and I bristle a bit when people try to act like jQuery is dumb. jQuery won. We are here now because of jQuery. It is useful even if you never use it, maybe especially so.

Web tech also means that the Tauri devs can stand on the shoulders of giants. Billions of dollars and billions of man-hours have gone into the development of web tech.

It's not perfectly aligned with the use case, and those billions have not been efficiently spent due to competing interests and design-by-comittee, but you're going to have a really hard time matching that investment.

Great observation and questions. What would you put in place of a WebView core?

I know very little about this but I assumed one advantage to doing it this way would be that browsers have to access the same web and thus conform to some kind of web standards, making your cross-platform core achievable. What else could you reliably expect to be on a Windows/Linux/MacOS install with enough shared DNA or similar feature set to build your engine?

If we're building a new cross platform engine for these sorts of applications, then we get to define those standards.

Electron essentially "bootstrapped" a standard environment from things people were already familiar with, but my point is that this may not necessarily be the best way forward in the long term because the requirements on the web don't match the requirements of desktop apps anymore.

I think a new engine here would need to provide things like a UI model, filesystem access, OS interoperability (e.g. open/save dialogs, drag and drop), maybe sound/video, things like that. Web tech gives us these things, but they were all designed to run in browsers, not app-specific instances, so they have additional security/sandboxing requirements[1], they don't necessarily expose great multi-threading primitives because JS doesn't have any concept of these, and they do have a bunch of complexity around the notion that resources all used to be served up by a remote server, but are now embedded in your application.

[1]: This means that Slack on a Mac is sandboxed at the macOS level and the Blink/Chromium level. There's no need for the latter, and it adds complexity and performance overhead.

Hi - core dev from Tauri here.

A new rendering engine is indeed one of the areas of the research at tauri. For now (and until 1.0 at least) we are sticking with the webview, because we want to have an alternative to electron that is safer and is well-known enough to be stable across platforms for the foreseeable future.

Regarding what an a new engine would have to provide, as a matter of fact, Tauri does offer cross-platform APIs for the filesystem, notifications, CLI, etc. These are all rust based, and available from JS.

I do have to disagree though, in one point, and that is that your single threading comment is only true in the webview. Technically, you have the entire strength of the underlying OS available to you from rust, and that is indeed where I recommend devs do all their heavy lifting. This is one of the benefits of using a polyglot system and an inherent security benefit.

Hi, thanks for your work, Tauri looks nice and it's good to have some competition for Electron.

My comment was quite "blue-sky", I'm not necessarily suggesting any of it for Tauri, but I think it's a useful thought experiment. If we weren't trying to be compatible with web tech (because I don't think we necessarily need to be), what would we change?

For example I think we'd probably not use JavaScript. JavaScript has improved a lot in the last 10 years, but it still has a lot of warts that are there explicitly for backwards compatibility with the web. If we're not trying to build for the web then we have so much more we can do.

While I think in Tauri pushing developers to put heavy lifting in Rust makes a lot of sense, similar to scripting a game engine we typically want to do this sort of thing as little as possible.

Without plugging away at a specific language, I'm a fan of https://github.com/hecrj/iced. It's native cross-platform (Linux/Windows/Mac) and compiles to wasm for web support. Native as in no web rendering - it renders its own widgets via wgpu - but that's the compromise for easy cross-platform support.

You use one interface for generic compatibility. This doesn't work for all cases, so you can also choose to add platform-specific code via conditional compilation to make sure that each platform's specifics are handled with intent, where you need to do so.

It's exactly what you're looking for. Early stages - file support is a little rusty (pun intended) - but it's coming along fast.

Does it have accessibility support? Generally the answer is 'no' for virtually all novel UI toolkits, especially immediate mode ones. I really love imgui but the lack of accessibility support means it can't be used on 'serious' projects that might ever be used by anyone visually impaired.

Woof yeah good point, that is a true bummer :(

We're using it for an internal prototype. It's not a great story right now: https://github.com/hecrj/iced/issues/282. But it _does_ support basics for HTML, and ARIA could be added.

Congratulations, you've reinvented Java.

Or just interpreters in general...

I disagree. If you follow the game engine analogy/thought experiment, I think there's much more that could be done.

There's a language, yes. There's also a runtime. There may be an interpreter depending on the language.

There's probably also a defined way of getting UI on to the screen in a platform independent way. There's probably also higher level concepts, maybe something that works a bit like a service worker, to use web terminology. There's likely to be a database of some sort, an app deployment system, software updates.

I'm not proposing a specific technology, but rather pointing out that there are a lot of parallels, and by realising that we're now using web technologies for shipping apps that aren't otherwise websites, maybe we could open up a lot of new potential solutions that might be even better.

There are interpreters that have offered those services for years. Hell, Didn't Visual Basic include a GUI layer 20 years ago?

I'm not arguing the utility of what your describing, just pointing out its not a new concept...

Except that you don't need to create anything new to be there. Java is already there right now. It has literally everything you listed.

Swing got an undeservedly bad reputation due to the bad default LAF. I wrote some pretty sweet stuff in Swing.

Anyway Qt is reasonably close as well, but with a compile per platform.

Games are simulations, arguably the hardest paradigm of software. Games have always included user interfaces, and in many cases they are just user interfaces. Web apps for the most part are also just user interfaces. React has basically adopted the equivalent of a game loop architecture. I guess the only thing holding back web apps becoming basically game engines are search engines like Google indexing different parts of it. In other words, search engines are better adapted to index and make sense of files on a computer, rather than a runtime simulation of some kind.

Maybe a bit off-topic for this comment but I really like (most of) the web's security model and I wish I had the same on my desktop. Specifically I'd like a strong per-program permission model, ideally in some sort of pluggable fashion (like, have a configurable chain of programs determine other programs' permissions, à la middleware).

You could take this to the extreme and have every program run in a "pure" fashion per default (i.e. no inputs other than command line args - no outputs other than the exit status).

The thing is most companies would want to have a web presence anyway. It's just easiest exposure and people have to be willing to install a software - visiting a website not so much. So if you're building these cross-platform apps on anything other than the Web stack people will still have to have different code bases for native and web which kinda defeats their purpose.

So I don't think you have any real alternatives until there's other technologies on the web or wasm can do everything.

As I kind of alluded to in my comment, I'm not sure many of these things need to be web apps. OS level sandboxing has come a long way in the last ~10 years, and need fewer of the benefits of the web (like publicly addressable resources), and more of the benefits of desktop apps (like filesystem access). Web tech is improving its support for the latter, but I think we could do better if we designed a system today, rather than using one mostly designed between 95-05.

I suspect React Native is probably the closest thing we have to this at the moment.

This.

If the web on iOS wasn't such a garbage fire, we could use React directly

Flutter?

So, like Emacs has been for decades? :-)

Yep, I think that's another pretty good example!

Reply on news.ycombinator.com