In 2015, there was an amazing amount of innovation related to the web platform. The following sections describe six technologies that I find exciting:
This blog post is a loose follow-up to “Web platform: five technologies to look forward to in 2014”, which I wrote in early 2014.
Electron (by GitHub) lets you build cross-platform desktop apps with web technologies. Its features include:
Electron was initially created for GitHub’s editor Atom and is now used by various companies, including Microsoft (Visual Studio Code, see below), Slack and Docker.
Architecturally, Electron contains both a Node.js runtime and a minimal embedded Chromium browser. Electron apps run in several processes: A main process runs the
main script specified by the app’s
package.json file. To display a user interface, that script can open windows. Each of those windows runs in a separate process (a so-called renderer process), just like a tab in a web browser.
With React Native, you can build native apps for iOS and Android via React. The virtual DOM is still there and you still use JSX to create it, but the actual UI is built with native components such as UITabBar on iOS and Drawer on Android. You lay out those native components via Flexbox.
On one hand that means that each of the following platforms has a slightly different UI layer now: the web, iOS, Android. On the other hand, you’ll be able to reuse much of your code, while having a native experience on each platform.
Usually I’m skeptical of solutions that try to transplant a language that is native on one platform to another one. But a few months ago, an iOS developer evaluated React Native and stated:
I may never write an iOS app in Objective-C or Swift again.
Another interesting quote, by Andy Matuschak (who “helped build iOS 4.1–8 on the UIKit team”):
I say with confidence as a former UIKit author: React's model for the UI layer is vastly better than UIKit's. React Native is a *huge* deal.
There are areas, where native apps have caught up with the web (deep linking, indexing). Progressive web apps are not really a technology, but rather an umbrella term for characteristics of modern web apps. These mean that web apps are catching up with native apps in some areas and moving ahead of them in others:
Progressive enhancement: The app runs in as many environments as possible. If it needs a service, it should use whatever is available and degrade gracefully if nothing is there.
Responsive user interface: The app adapts to various input methods (touch, speech, etc.) and output methods (different screen sizes, vibration, audio, braille displays, etc.).
Connectivity-independence: The app works well offline and with intermittent or low-bandwith connectivity.
App-like UI: The app adopts UI elements of native platforms, including a fast-loading user interface (which can be achieved by caching important assets via service workers).
Continuous updates (“freshness”): The service worker API defines a process for automatically updating apps to new versions.
Secure communication: The app is served and communicates via HTTPS, to prevent snooping and attacks.
App discovery: Meta-data such as W3C web app manfests enables search engines to find web apps.
Push interaction (“re-engagement”): Features such as push notifications actively keep users up-to-date.
Natively installable: On some platforms, you can install a web app so that it feels like a native app (icon on home screen, separate entry in app switcher, browser chrome optional). All without going through a native app store.
Linkability: Easily share apps via URLs and run them without installation.
I’m mentioning progressive web apps here, because I like all of the aforementioned techniques and technologies. But I’m not sure how much “progressive web apps” are different from simply “modern web apps”. One idea I oppose is giving web apps install banners (their killer feature is, after all, that they don’t need those).
The bundle it outputs only includes those exports that are actually used, via a technique called “tree-shaking”. Three-shaking crucially depends on the static structure of ES6 modules. “Static structure” means that they are analyzable at compile time, without executing any of their code. Having this kind of dead code elimination is great, because we are now free to make modules as big or as tiny as makes sense, without having to worry about the sizes of bundles.
It demonstrates that ES6 modules are a viable bundle format for ES6 modules (obviating the need for any kind of custom loading).