There are three main reasons for this:
First, trying to coordinate applications across multiple platforms and devices is extremely time-consuming. Generating and managing the shared and platform-specific code for an app is relatively straightforward, however it is the management of all the different installers, digital certificates and signings that seems to take an unreasonable amount of time. A simple iterative update - which I seem to do a lot - involves rebuilding, re-signing and zipping a Windows setup.exe file, regenerating an OSX package file, rebuilding and gzipping both 32-bit and 64-bit Linux installers, then rebuilding and re-signing an Android APK file. Not to even mention iOS, where you can only develop on specific registered devices and have to physically lend your own hardware to anyone you might want to review or beta-test your app. Maybe someone else could turn all this into a nice simple script, but for me getting it right typically involves several different applications on multiple operating systems and lots of mindlessly repetitive steps. With a web-based application, you simply FTP the new files to the server and then get people to hit ‘Refresh’ in the browser of their choice on any device they want - pure unadulterated pleasure in comparison.
Third, Safari 8 for OSX Yosemite and iOS 8.3 now both fully support WebGL by default - so no more trying to explain to people how to manually enable it. As browsers for Linux, Android and Windows have supported WebGL for some time, this represents a bit of a tipping point as now up-to-date versions of browsers for all the commonly used desktop and mobile platforms now have good, reliable support for HTML5 and WebGL.
All That Wasted Effort…
One really good thing that has made this process a whole lot more enjoyable is my discovery of Knockout. I first started out using React and Angular, but the learning curve and organisational structure they impose just didn’t sit right for the types of small web apps I was doing. Then I finally found Knockout and the way it did things just seemed so much more logical and intuitive to me. Obviously this is a purely personal preference, but a few days spent learning Knockout is so worth it in the long run as it makes dynamic interaction within web pages an absolute breeze.
15 October, 2015 - 00:29Dr. Andrew Marsh
Some Browser/Platform Issues
In my testing of several different devices and browsers, I have found the following ‘idiosyncrasies’:
Chrome on Android has recently changed to require support for the GL_EXT_robustness extension before it will run WebGL on a device. Unfortunately even though they are perfectly WebGL capable, most Samsung Galaxy tabs/phones and some Nexus don’t support this particular extension so WebGL is automatically disabled regardless of your settings in chrome://flags (see: https://code.google.com/p/chromium/issues/detail?id=306938).
There are three possible workarounds for this.
You can simply use Firefox or the native Android browser that came with your device instead.
You can install the developer version of Chrome on Android as this issue is resolved there (see: https://play.google.com/store/apps/details?id=com.chrome.dev&hl=en).
You can try going to chrome://flags in the address bar and then turning on “Override software rendering list” at the top of the displayed options. This has worked for some people but not all.
Chrome in iOS 8 seems to implement the devicePixelRatio weirdly for Retina screens, at least it does on my iPad 3. This means that it reports a devicePixelRatio of 2 (which is right) but then seems to display the WebGL canvas at double the required size (as if assuming a devicePixelRatio of 1). The same app works fine in Safari so I’ll have to look into this to see if it’s something I am doing or if I have to specifically detect for Chrome.
The latest Samsung phones with hi-res screens seem to report a ridiculously low resolution to the browser when rendering a page (something like 360x640 when the screen itself is actually 1440x2560) but does show a devicePixelRatio of 3. This makes all the buttons and UI elements far too large relative to the screen, so I will have to do some experimentation with scaling on devices with that kind of configuration and post an update.