6 ms·

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 platform

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.

ordinaryradical 6y ago
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?
- danpalmer 6y ago
  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.
  - AnIdiotOnTheNet 6y ago
    Congratulations, you've reinvented Java.
    - mech422 6y ago
      Or just interpreters in general...
      - danpalmer 6y ago
        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.
        AnIdiotOnTheNet 6y ago
        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.
        nitrogen 6y ago
        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.
        mech422 6y ago
        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...
danpalmer 6y ago
I suspect React Native is probably the closest thing we have to this at the moment.
- k__ 6y ago
  This. If the web on iOS wasn't such a garbage fire, we could use React directly
- ci5er 6y ago
  Flutter?
quotemstr 6y ago
So, like Emacs has been for decades? :-)
- danpalmer 6y ago
  Yep, I think that's another pretty good example!
sm4sh 6y ago
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.
- danpalmer 6y ago
  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.
LeifCarrotson 6y ago
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.
hinkley 6y ago
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.
proc0 6y ago
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.
t0astbread 6y ago
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).
- baxrob 6y ago
  Somewhat related: https://github.com/webview/webview/issues/413 https://github.com/webview/webview/issues/413

ordinaryradical 6y ago

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?

danpalmer 6y ago
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.
- AnIdiotOnTheNet 6y ago
  Congratulations, you've reinvented Java.
  - mech422 6y ago
    Or just interpreters in general...
    - danpalmer 6y ago
      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.
      - AnIdiotOnTheNet 6y ago
        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.
        nitrogen 6y ago
        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.
      - mech422 6y ago
        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...

danpalmer 6y ago

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

k__ 6y ago
This. If the web on iOS wasn't such a garbage fire, we could use React directly
ci5er 6y ago
Flutter?

quotemstr 6y ago

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

danpalmer 6y ago
Yep, I think that's another pretty good example!

sm4sh 6y ago

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.

danpalmer 6y ago
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.

LeifCarrotson 6y ago

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.

hinkley 6y ago

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.

proc0 6y ago

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.

t0astbread 6y ago

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

baxrob 6y ago
Somewhat related: https://github.com/webview/webview/issues/413 https://github.com/webview/webview/issues/413