Hacker News Reader

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

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

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

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.

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

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.

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

You can read about the QML compiler here

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

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.

"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/

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

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.

cough XAML cough

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

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

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.

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

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

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.

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

It does with caveats;

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

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.