Stop pushing the web forward

"Native apps will always be much better at native than a browser. Instead, we should focus on the web’s strengths: simplicity, URLs and reach."

For me, the web's main strength is that you have to write your application only once. I don't have to think about redesigning the UI because "that's not the iOS way" or "that's not the Android way." I don't have switch between different languages and write the same damn thing one more time. I don't have to hire a whole team to have an idea see the light of day and be accessible to the great majority of people. And if my idea is a little idea, I don't have to struggle so much to get people to check it out, given that installing an app is a much bigger barrier than clicking a link.

I understand that if I want to be on the bleeding edge, and I want it to be optimal whether it runs on a phone, a tablet, or a computer-proper, browser dev can be challenging. But I don't always have to be on the bleeding edge.

Still, it's nice to know that browsers are becoming more and more capable, so there isn't quite as huge a chasm between native apps and something that runs in a browser. That's an artificial distinction.

The cool thing about many of these features is that I can push out some code that I can share with a hyperlink and other people can run it without installing anything other than a browser.

The authoring experience is still terrible. And the user experience still requires hopping over the secret, invisible wall into developer-tools land... but the potential is there. If you're savvy enough to open your web console and view source you can mess around with some code I wrote to demonstrate some fundamental procedural algorithms[0].

I chose Javascript and because everyone has a Javascript interpreter and most browsers today support . If I had chosen to demonstrate these algorithms in Python, for example, I'd have to expect my reader to download and install a Python interpreter for their system, download or copy/paste my examples, and load them into their REPL before they could start playing around. The browser experience requires fewer steps.

A moratorium would be a welcome change of pace, IMO. It'd be nice to close the gap between the user and the developer and between document, code, and media. It'd be nice if authoring tools for these environments could catch up with the available features.

On the other side of the coin the proposed common byte-code format is really exciting and practical for all sorts of reasons -- in the case of my aforementioned blog post I think there are better languages to teach with than Javascript and having that language be available as a first-class citizen in any web document would be a boon.

I think some features would still be worth pursuing in favor of others.

[0] http://agentultra.com/2015/06/24/introduction-to-procedural-...

We need a viewport-size-agnostic graphical native sandbox that works on x86_64 and ARM, and can be reasonably sure is escape-proof. Which is hard to do if you let it have multitasking and access to graphics drivers.

Then we need a means of letting it have just enough network access to be useful but not enough to exploit the rest of your system, bearing in mind the discussion of WebRTC going on at the moment.

The cross platform experience will never match the native experience. Think about on the desktop. The only cross platform apps that behave natively on Mac, Windows, GNOME (and derivatives) and KDE are apps tha have completely separate front-ends for every platform. Firefox is an ok example of this, although it in a way forms its own platform rather than integrating with its host, still it pulls it off better than other cross-platform apps. The Transmission bittorrent client is perhaps a better example, it has at least 4 mature front ends: gtk, qt, cli and os x. This is only feasible for a little free software project like Transmission because its UI is fairly simple, it has a list of torrents, a settings dialog and a properties panel.

Most apps that try to be cross platform just use a UI toolkit that acts as a cross platform compatability layer. Qt, GTK, Swing, WxWidgets and Tk all fit the bill. The result is that the app doesn't look good or integrate especially deeply into any platform, except sometimes with the platform the the developers personally use.

There are few exceptions to this rule. One is Sublime Text 2+ which is built on Qt. Without any customization, its theme looks OK, but doesn't match the design language of any platform, and its integration with its host platform is non-existant, everything happens within the sublime text window (no notifications or system tray/menubar widgets, no quick-view previews in Finder or Nautilus, etc). It's possible to improve integration by intstalling a custom theme which lets the user override a lot of the UI design, including the margins and padding, and plugins are written in python and can access a lot of host platform features.

If you want a native experience, you have to write a native app. You can share your business logic by linking to the same C++ code or in the future maybe by using react native and sharing the same non-view code. But your UI-layer has to be tailored specifically to the host platform in order to look good.

Probably will be more like a URL link aware VNC viewer. That has some interesting implications for the back end WRT emulation.