[hartmel]

Am I the only one who see the same story repeated again ?

We have now Facebook, a major actor on the web, who is developping a cross-platform toolkit for application development, using OS native widgets. XUL, I miss you :) And now others try support different OS.

Mozilla created everything and they just failed to "market" it. It s at the same time a pain and a joice to see real JS applications, shadow dom, custom components, CSS based styling being the core of a toolkit while we saw XUL/XBL/CSS/native calls from Mozilla be killed a few months ago. It had its flaws, but it s a serious (but really difficult) way to go : Qt did it, Gnome did it, Microsoft did it, even Adobe tried to do. Mozilla and people involved in previous ideas and implementations deserve a special mention for their work.

We really need such technologies, and that Mozilla killed theirs was a really sad choice for me. Creating software with "simple" markup, "simple" styling rules, "simple" event/user interaction handling should be a concrete goal of decades of languages/compilers/interpreters researches.

It has a price : performance, sometimes native look&feel not perfectly accurate, supported platform must have similarities. We may hopefully reach a level where a <button> tag will cost 1% of overhead against a native call and this will be a great day. I hope these new implementations will succeed, and that the actual overcomplexity in the web developpement will not land in though.

[Tloewald]

This is just another example illustrating Joel's "Strategy Letter V":

http://www.joelonsoftware.com/articles/StrategyLetterV.html

Facebook is an application / services company, so it wants its competitors to be non-existent or expensive (luckily, so far, it's more the first than the second), and its complements to be free / cheap and ubiquitous. Hardware / software / networks are its complements so it tries to make them free (give away internet access, build open source servers and routers, make cross-platform libraries, and so on).

Google is in much the same boat, and does much the same kinds of thing.

Apple is the reverse, so it wants its platform to be anything but a commodity, but apps to be free / cheap and ubiquitous (hence the App Store). Similarly, insofar as it creates differentiating development tools, it would prefer they be platform exclusive. (Swift isn't a positive differentiator; it mostly addresses a platform disadvantage, so it's free and open source.)

[pjmlp]

> We may hopefully reach a level where a <button> tag will cost 1% of overhead against a native call and this will be a great day.

Also known as XAML and QML.

[hartmel]

I wish it to be true :)

Disclaimer: I didn't feel the user experience you described. (and have a lot more experience with XUL than QML)

What I experienced is that actual performances of crossplatform "runtimed" toolkits are enough for desktops and acceptable for mobile devices, but the global overhead (compared to a binary using native OS widgets) exists, beginning with startup cost, memory consumption, i/o latency. In fact, the same constraints that VM-based languages have. And even more : the underlying GUI toolkit may be used in an unexpected way, strange GPU driver behaviours may pop up, how not to be bothered by OS fragmentation. And then an application may run flawlessly on a device with a given OS while on another it performs not that good.

While I think it's correct to say that VM-based languages does not have to blush in front of compiled programs when talking about raw computing performance, my experience (as an ex XUL-lover, I may be biased) make me think that this is still not true when UI is involved. Java has maybe the oldest (and most optimized ?) runtimed UI, and it does not convince me. OK, this may be a bad example : Java UIs are "runtimed" at a different layer. but seeing the length of the QML performance wiki page is a bit scary :)

Maybe the "1% overhead" is an unreachable dream, and maybe the native apps will become deprecated, but I think there are a place for improvements. How many attempts of crossplatform UI runtime exists ? Not that much. With hardware improvements, the overhead will be more and more acceptable. It s a huge work, and previous errors should be looked at (rant time : Mozilla: you should not have stopped to use native widgets - Adobe: Flex - QML: mimicking web dev like XUL did is nice !).

Though, I am really impressed by Qt and .Net SDKs and I would really love to see more free software and linux surprises from Microsoft with the Xamarin acquisition.

And, let's be utopic, the future is maybe about a standard API à-la POSIX for end-user applications, where OS vendors will agree on an app, and natively implement their own <button>, their own <menu>, their own <video>. They do if for the browser, for the "webassembly", why not for the OS ? Or the browser will be deeply integrated in OS and the "web" apps will replace all native applications. Or they'll still coexist for years.

OK, anything but embedding a webview would please me :)

[pjmlp]

I got lost at the VM references.

XAML engine is native C++ code, no VM. Since Windows 8 there isn't also a VM as such on the .NET side, given the AOT compilation support.

Similarly QML is only interpreted in the free version. Commercial Qt compiles QML into native code.

[hartmel]

Yes, the java comparison is not really good, I wanted to make a "runtime" analogy. I didn't know for compiled QML.

[pjmlp]

You can read about the QML compiler here

http://doc.qt.io/QtQuickCompiler/

[cheez]

I believe it's more correct to say that the creation of the QML object tree is compiled to C++. The rest of it is byte compiled JavaScript.

[pjmlp]

"Compiled Qt Quick is an elegant solution to these problems: .qml files as well as accompanying .js files can be translated into intermediate C++ source code. After compilation with a traditional compiler, the code is linked into the application binary. This entirely eliminates the need of deploying QML source code, it reduces the application startup time and allows for a much faster execution on platforms that do not permit Just-in-time compilation."

http://doc.qt.io/QtQuickCompiler/

[cheez]

So the JavaScript is compiled to C++? They implemented emscripten?

[pax_americana]

I find it amusing that those two mirror XML and JSON respectively.

[pjmlp]

We could have had XAML for the web if XHTML had been successful.

It is a pleasure not having to deal with HTML + CSS + JavScript tricks to bend the DOM to fake UI widgets.

[Tloewald]

What really bugs me is that the browser keeps failing to step up to the plate. Despite everything, browsers still don't come close to supporting a first class user interface Why can't web apps have proper (native) toolbars, menus, etc. instead of "the best half-assed simulacrum you can make out of divs, css, pngs, svg, and javascript? This was the single glaring deficiency of Hypercard back in the day, and it's been faithfully replicated by the W3C et al for over twenty years now.

Sure, this would all need to be reasoned about carefully to avoid visual security loopholes, but it's not like we didn't live through Flash and Java.

[Aleman360]

cough XAML cough

Fast enough to be used by the Windows Shell, Office, Edge, HoloLens, and Xbox.

[jimbokun]

"It has a price : performance, sometimes native look&feel not perfectly accurate, supported platform must have similarities."

This is what makes the whole idea a complete non-starter. Users want apps without perceptible latency for their interactions, that look and (more importantly) work like the other apps they are used to. Hard to come up with more important criteria for a successful end user application than these.

[hartmel]

I really agree. I described the current state. As my next comment explain it more, there is room for improvements. Is the "write once run everywhere" paradigm a realistic goal, would it be achieved at runtime or at code generation/compilation, without an unbearable cost for users ? I want to believe.

W3C made it possible for web.

[cleversoap]

> Is the "write once run everywhere" paradigm a realistic goal

A part of me sees react-native adding another option here - "write once, tailor anywhere"

While it's always been possible to have common core logic and then tweak your frontend for each platform as a separate project to get a slightly closer to actual native experience, react-native makes it significantly easier to do so and I think it's that one+ standard deviation away ease that makes all the difference.

I don't think we'll see a lot of successful react-native cross platform that goes for the one-size-fits-all approach but rather, with the same (probably even less) effort, we'll see react-native apps that target the UX of a platform rather than just the UI elements.

[jakevn]

> W3C made it possible for web

W3C provided what might be akin to C compiler standards which are only partly followed by implementors.

The rest is handled by libraries/frameworks/polyfills that get you 80% of the way there.

[kevando]

If you look at Apple, Google, and Facebook as competitors - I think it's clear that Facebook feels vulnerable that it does not own a programming language. I see RN as their push to create a unique "language" that people build apps in.

[woogley]

That seems unrelated. It's not like Go lets you build GUI Android/iOS apps. Also Facebook has http://hacklang.org/

[jmhobbs]

It does with caveats;

https://talks.golang.org/2015/gophercon-go-on-mobile.slide#1

[kevando]

Sorry I misspoke calling it a programming language. I am referring to Android/Chrome/iOS/OSX so Facebook is likely trying to get into the OS game.