Posts Tagged ‘mobile web’


React Native – When the Mobile Web Isn’t Enough

by Joe Stanton

Back in January, a few Red Badgers were lucky enough to be sent to React.js Conf at Facebook HQ. We’re huge fans of React and have been using it to great effect on every project since we discovered it in early 2014.

There were many excellent talks at the conference, and it was staggering to see just how much adoption React has gained in such a short space of time, especially by some huge players in web technology (anyone heard of Netflix, AirBnB or Yahoo?).

There was one very significant announcement that overshadowed the other talks, though. Tom Occhino took to the stage in the first keynote and delivered a Steve Jobs-esque announcement of React Native. As a bonus, all conference attendees were given early access to the project, now open source.

Tom Occhino

After experimenting with, and contributing to React Native during its private beta phase, I’ve formed an opinion on what it might mean for Web developers like us, and our clients. And it’s exciting.

The Present

Red Badger are rather good at building responsive websites. Our clients love them because they deliver a fantastic experience for their customers on all kinds of devices. These sites feel better, convert better, and look great. They also don’t cost significantly more to build than traditional websites, when developed with responsive in mind from the beginning.

They are the 80% solution, though. They don’t solve everything. The last 20% has proven to be a problem. This elusive 20% sometimes means we have to say no to projects where the mobile web is not yet a good fit, and we hate it.

So what is the missing 20%? Or rather, what’s wrong with the current state of the mobile web?

What’s wrong with the Mobile Web?

  • Real performance problems – The DOM is just slow. The weight of the DOM feels much worse on mobile, where resources are constrained. Attaining the 60fps necessary for a smooth experience can be very difficult when images are being decoded whilst scrolling, for example.
  • Poor gesture support – This is a huge part of why native apps feel more intuitive and higher quality. I frankly had no idea just how much control was given to native developers in dealing with gestures correctly until researching it, and it shows. Simple things like not accidentally clicking a link whilst scrolling, responding to sliding events with velocity etc. are much harder to deal with on the web.
  • Many Native API’s are still not exposed for web – So we simply can’t take advantage of them (Push Notifications, iBeacons, Vibration, TouchID to name a few). This is a major cause of us saying “no” to a requirement. This can be somewhat addressed by a framework like PhoneGap, which comes with its own set of negatives.
  • Half baked features that don’t really work as intended eg. offline support with AppCache.
  • Years of legacy browser support – A huge productivity killer.

Perhaps the biggest problem of all, though, is the glacial rate at which these problems are being addressed. We’re die-hard advocates of the web, but we can’t wait forever. Exciting new web standards such as ServiceWorker (bringing Push Notifications, much better offline support etc.) are still a way off, and Apple have no publicly announced plans to adopt this standard at all for Safari.

Web apps still don’t feel as good as native apps, and it’s a shame. We’ve been saying they’ll catch up for a while now (Facebook famously went native in 2012) and they aren’t.

So how do you avoid the unreasonable cost of native development, of running separate teams with separate tech stacks, with no code reuse, limited shared knowledge, and their minds on technology instead of the product?

React Native

After using React Native for a few weeks, I’m convinced. I’ve distilled my feelings into a list of benefits:

  • It’s Real, Native UI – With great performance, animations and gesture control, that blend effortlessly into the platform. This means you’ll still have different Web, iOS and Android implementations, but they’ll provide a great experience that’s tailored to each platform. It’s nothing like a WebView.
  • It’s React, a technology we already love – it’s fast, it’s familiar and we write far less bugs in it thanks to its functional properties.
  • It’s the same tech stack – modern JavaScript (ES6), the good parts of CSS (Flexbox) and the same tools for building, packaging (NPM), linting (eslint), testing (jasmine/jest) etc.

    This means the same team can develop the Web, iOS and Android versions of an app, using technologies they’re already comfortable with. The developers best placed to build a product are the ones that understand it the best, not those segregated into different teams based entirely on technology.

  • Speed of Iteration – Changes in the UI are reflected immediately via Live Reload. There is no lengthy recompilation step, and most changes appear within a few seconds. This is what we’re used to on the web, but something very new to Native development. It leads to happier, more productive development sessions, and a willingness to experiment without frustration.
  • A simple JS->Native Bridge – So you can use libraries written in Obj-C/Java when you need to. It’s possible to build both native libraries (eg. bridging the TouchID service on iPhone) and native UI components, such as a switch, or slider. You can create nice, declarative API’s for these libraries and distribute them on NPM.
  • It works on iOS and Android (coming soon) – There’s no reason it can’t work on other platforms too.
  • It’s even possible to hot-load new JavaScript code, thanks to this recent (extremely significant) relaxation of App Store rules:


These benefits boil down to enormous workflow and productivity gains over traditional native development, making that last 20% much more bearable and potentially a lot less expensive, too.

The Future

The most promising part of React Native is not the code itself, but the ideas. Facebook core contributors have regularly stated that they see it as a testbed for new ideas. These ideas can lead us to better abstractions and solve real problems before being implemented within browsers. More eloquently put:


We need better primitives for building performant and native feeling UI within mobile browsers, and this shouldn’t start as a draft from a standards body, perhaps React Native can help lead us there.


Full Frontal 2013

by Stephen Fulljames


When assessing conferences for myself, I tend to break them down in to “doing conferences” and “thinking conferences”. The former being skewed more towards picking up practical tips for day-to-day work and the latter being more thought provoking, bigger picture, ‘I want to try that’ kind of inspiration.

Despite being pitched as a tech-heavy event for Javascript developers, Remy and Julie Sharp’s Full Frontal held at the wonderful Duke of Yorks cinema in Brighton has always felt like more of the latter. That’s not to say the practical content isn’t very good. It is, very very good, and naturally the balance has ebbed and flowed over the event’s five year history, but the general feeling I get when I walk out at the end of the day is always ‘Yeah, let’s do more of that!’ It’s been that way right from the start, in 2009, when Simon Willison ditched his prepared talk at a few days notice to speak about a new language in its infancy – a little thing called Node. So I was hopeful that this year’s conference would provoke similar enthusiasm.

High expectations, then, and a promising start with Angus Croll taking us through some of the new features in EcmaScript 6 (ES6), aka “the next version of Javascript”. Presenting a series of common JS patterns as they currently are in ES5, and how they will be improved in ES6, Angus made the point that we should be trying this stuff out and experimenting with it, even before the specification is eventually finalised and brower support fully implemented, as David commented that if you’ve done Coffeescript you’re probably well prepared for ES6, and really one of the aims of Coffeescript was to plug the gap and drive the evolution of the language, so its hopefully something I will be able to pick up fairly easily.

This was followed by Andrew Nesbitt, organiser of the recent Great British Node Conference, demonstrating the scope of hardware hacking that is now becoming possible using Javascript. As well as the now-obligatory attempt to crash a Node-controlled AR drone into the audience, Andrew also explained that “pretty much every bit of hardware you can plug into USB has a node module these days” and demonstrated a robotic rabbit food dispenser using the latest generation of Lego Mindstorms. Being able to use Javascript in hardware control really lowers the barrier to entry, and the talk only reinforced the feeling I got after the Node Conf that I need to try this (and ideally stop procrastinating and just get on with it).

Joe McCann of Mother New York gave a high-level view on how mobile is increasingly reshaping how we interact with the web, with the world and with each other. Use of phones as payment methods in Africa, where availability of bank accounts is challenging, has reached around 80% of the population with systems such as M-Pesa. And SMS, the bedrock of mobile network operators’ revenue since the early 90s, is being disrupted by what are known as “over the top” messaging services that use devices’ data connections. These are familiar to us as iMessage and Whatsapp, but also growing at a phenomenal scale in the far east with services such as Line which is offering payment, gaming and even embedded applications within its own platform. Joe’s insight from a statistical point of view was fascinating, but it didn’t really feel like many conclusions were drawn from the talk overall.

Andrew Grieve and Kenneth Auchenberg then got down to more development-focussed matters with their talks. The former, drawn from Andrew’s experience working on mobile versions of Google’s productivity apps, was a great explanation of the current state of mobile performance. It turns out that a lot of the things we often take for granted, such as trying to load Javascript as required, aren’t as important now as perhaps they were a couple of years ago. Mobile devices are now able to parse JS and selectively execute it, so putting more effort in to minimising DOM repaints, using event delegation, and taking advantage of incremental results from XHR calls and progress events are likely to be better bets for improving performance.

Kenneth spoke about the web development workflow, a subject he blogged about earlier in the year. His premise was that the increasing complexity of browser-based debug tools, while helpful in their purpose, are only really fixing the symptoms of wider problems by adding more tools. We should be able to debug any browser in the environment of our choice, and he demonstrated this by showing early work on RemoteDebug which aims to make browsers and debuggers more interoperable – shown by debugging Firefox from Chrome’s dev tools. By working together a community on projects like this we can continue to improve our workflows.

My brain, I have to admit, was fairly fried in the early afternoon after an epic burger for lunch from the barbeque guys at The World’s End, a spit-and-sawdust boozer round the corner from the conference venue. So the finer points of Ana Tudor’s talk on some of the more advanced effects you can do purely with CSS animation were lost to struggling grey matter. Suffice it to say, you can do some amazing stuff in only a few lines of CSS, in modern browser, and the adoption of SASS as a pre-processor with its functional abilities makes the process much easier. It’s also brilliant that Ana came on-board as a speaker after impressing Remy in the JSBin birthday competition, and a perfect demonstration that participating in the web community can have a great pay off.

The last development-orientated session was from Angelina Fabbro, on Web Components and the Brick library. Web Components are a combination of new technologies which will allow us to define our own custom, reusable HTML elements to achieve specific purposes – for example a robust date-picker that is native to the page rather than relying on third party Javascript. This is naturally quite a large subject, and it felt like the talk only really skimmed the surface of it, but it was intriguing enough to make me want to dig further.

The finale of the day, and a great note to finish on, was Jeremy Keith speaking about “Time”. Not really a talk on development, or at least not the nuts and bolts of it, but more of a musing about the permanence of the web (if indeed it will be so) interspersed with clips from Charles and Ray Eames’ incredible short film, Powers of Ten – which if you haven’t seen it is a sure-fire way to get some perspective on the size of your influence in the universe.

Definitely a thought-provoking end to the day. As someone who has done their time in, effectively, the advertising industry working on short-lived campaign sites that evaporate after a few months (coincidentally Jeremy mentioned that the average lifetime of a web page is 100 days) it has bothered me that a sizeable chunk of the work I’ve done is no longer visible to anyone. On the other hand I have worked on projects that have been around for a long time, and are likely to remain so, and I suppose in the end its up to each of us to focus our efforts and invest our time in the things that we ourselves consider worthwhile.

(Photo: Jeremy Keith recreating the opening scene of Powers of Ten on a visit to Chicago)


Something about the Quirky World of Mobile Web Apps

by Haro Lee

On a recent mobile-focused project we ran into a few challenges over getting what turned out to be a fairly complex layout working smoothly and responsively over a range of target devices. It also highlighted a number of real edge-case quirks in how different phones and browsers deal with modern web technologies such as the audio element, and even how ‘shake to undo’ can affect a form that the UI hid several transitions ago.



(There was a time mobile phones were simpler… or not…)



To help with the total payload of the project we chose to use the Zepto library rather than jQuery. This has an API very similar to jQuery’s and the advantage of size but is focussed on modern, mobile browsers so drops support for IE and – significantly – doesn’t cover Windows Phone. That wasn’t a problem on this particular project but worth bearing in mind for the future.

We found a couple of niggles in the Zepto API, mainly related to our own coding styles and the requirements of the project. We missed jQuery’s ability to set a hash of functions against AJAX http response codes, for example.

In the end, given the eventual size of the rest of the application’s payload, the filesize saving of Zepto over jQuery probably didn’t make a whole lot of difference.


How to be responsive

The biggest problem encountered while implementing a responsive layout with the given design was how the DOM flow needed to change depending on whether the screen is portrait or landscape. It would have been ideal if we’d had the option to change the design and eliminate the worst of the problems, but once we realised how complicated it would be it was already too late. So a lesson learned…

One of the big problems in trying to fit a fairly fixed size application design to a phone screen is orientation. Fine in a native app; you can just specify if the app fits to portrait or landscape, or both, but in a browser that level of control is not available.

Fitting the level of interaction we needed, responsively, into a landscape phone viewport meant quite a lot of juggling of DOM elements and events when switching from and to portrait layout. This was particularly tricky on iPhones as Safari in landscape orientation has three different possible sizes (address bar visible, address bar hidden, fullscreen) and generally smaller screen sizes than our target Android devices. The eventual experience in landscape wasn’t as satisfying as in portrait but we did manage to make it work.

Because of all the complexities that are not possible to handle only with CSS and media queries, we heavily depended on a Javascript layout manager to handle resize events and orientation changes, calculating available screen estate and rearranging elements.

A simpler way to get around this, although perhaps a cheeky one, would be to use the ‘orientationchange’ or window’s ‘resize’ event to effectively hide the main app with a “please turn your phone round” message. Unfortunately the ‘orientationchange’ event is not available on older Android devices.



The procedure we used to preload assets for our single page web app was to have separate CSS files for the preloading/splash screen and for the main app.

The splash page was part of the app, so we didn’t want users to proceed from here and start using the main app until all the assets were loaded. To achieve this, we made one stylesheet for the splash screen with all the generic styles that didn’t require any images and another for the main app which referenced all images and assets (i.e. icons and background images) and only linked the splash stylesheet to the HTML page. We then used a Javascript preloader which requested all the image assets and the main stylesheet, attached this CSS file to the HTML page once everything was loaded and ready.

This method could also be used to load different stylesheets and assets depending on the screen size or device, if required.



A new technology for us on this project was the Web Audio API which is a programmatic way of cuing and playing sound files rather than relying on a DOM element such as <audio>. Support is limited for now with only modern desktop browsers, and Safari in iOS 6, able to use it, but it looks to be a great way of adding spot effects to browser games and other interactions.

We used the Howler library to add sound to the application, with the expectation that we would use its fallback methods to increase support across devices and browsers. In the end due to other technical constraints (see ‘Device Quirks’ at the end of this post) we chose to only play sound through the Web Audio API, so if we were to refactor here we could have removed Howler (not that there’s anything wrong with it) and go direct to the API.


Jam off the boil

We’ve used the Jam package manager on a few projects now, and while it does have some advantages in dependency management and compilation it also uses its own module install system. So it relies on package owners keeping the versions that are published in Jam (rather than their main Github, etc, repo) up to date. We’ve had a few cases where the version of a library we needed isn’t available yet in Jam.

Jam interface with the browser is a modified version of Require, which we like for its clean module loading mechanism. So for future projects we’d look to dropping back to regular Require and find something else, perhaps a Grunt task, to handle the file concatenation and minification which Jam also offers.


App logic

The application logic required a fairly complex state to be maintained, and for these we used our old friend Knockout. We did consider lighter MV* libraries but ultimately felt that with Knockout’s very comprehensive view binding built-in we would save ourselves a lot of trouble. The other main aspect of the Javascript architecture was the use of a PubSub (publish-subscribe) library to communicate between the various parts of the app. So for example the AJAX API methods were fairly isolated – to enable their easy reuse – with their success states publishing the returned data for the viewmodels to pick up.

This decoupling did present a few edge case bugs around timing issues later on in development, but overall the ability to have communication, view state, preloading, sound and so on implemented independently and talking to each other via PubSub suited the Require modular loading we used as well as resulting in cleaner code.

This complexity of the application was borne out in the eventual size of the DOM, as we had several ‘pages’ within one document which were hidden and shown as required. For smoothness of experience this was useful, but retrospectively we’ve wondered if it might have been better to have a minimal HTML document with more extensive use of Javascript templating through Backbone or similar. Ultimately its hard to tell without implementing, but at least we have a steer for future iterations in this programme of projects.


Phonegap and other gotchas

It is well known that the performance of a web app wrapped in the Phonegap library is not as good as a native application.

Our previous Phonegap projects had a lot more DOM elements involved than this one so we hoped for better performance, but there were still a few performance issues on older iOS devices. Aside from that the Phonegap wrapping was pretty straightforward with minimal changes needed.

In the end perhaps the weirdest problem we discovered was that mobile service providers such as T-Mobile and Virgin appear to strip comments in HTML when sending data to mobile devices. This caused failures in our Knockout implementation, which used the library’s containerless control flow (i.e. specially formatted comments) to reduce the number of DOM elements – a very unexpected surprise. We ended up replacing all comment bindings with regular DOM bindings.


Device quirks – iOS[I] vs Android[A] vs Blackberry Z10[B]

– on-screen keyboard

[I] no viewport size change when hiding/showing the keyboard

[A, B] viewport size changes when keyboard is showing

[older A] even when the form page is hidden, the on-screen keyboard will not be dismissed unless the focus on the textfeld is forcibly removed.

– in-page scrolling

[A] even with overflow settings its still very buggy on the stock browser but Chrome doesn’t have problems.

– overflow: hidden

[older A] cannot interact with elements inside of “overflow: hidden” even if they are visible

– shake to undo (only on iOS)

[I] we found a filled-in form which was subsequently hidden triggered the iOS ‘shake to undo’ event. Unfortunately there was no known way for users to disable this feature easily but having an iframe somewhere in the DOM and changing its src (to anything) disables the “feature”. This hack doesn’t work if the app is wrapped in Phonegap but you can explicitly turn off shake to undo here.

– <audio> elements

[A] when a sound clip plays in an audio element it stops other background music from other apps

[B] the sound clip files are added to system playlist and so become accessible through its music player

– ‘devicemotion’ event

[A] on Android Chrome browser the ‘devicemotion’ event is not supported, although it is available on the stock browser. Future Chrome updates should add support.

– ‘orientationchange’ event

[older A] not supported


co-written by Stephen Fulljames



Device Independent Web – All For One, One For All

by Haro Lee

“All For One, One For All!”


What Happened…

A few days ago, I got an email with a url to an article on a website.
I clicked it without giving it much thought and the page opened on my web browser and for a moment I was puzzled as it looked quite not what I expected.

The font size was unnecessarily big, the paragraphs filled the entire width of the window, images were stretched, and I scrolled down and on the bottom of the pages there were several huge buttons filling all the available width.

At first I thought ‘what a badly designed website’ and then realised something was not right (other than it looked bad…).

I checked the url and it started with “mobile”.

Yes, it was the mobile version of the webpage.

I removed the “mobile” bit and it reopened the normal desktop version of the webpage now with a lot more comfortable look.

I figured out what happened there. The colleague was looking the webpage on his mobile phone and shared it by sending the url.

I’m sure many of you have the same experience.



I don’t want to start yet another debate what should a mobile internet be like or even the point of the existence of mobile internet (such as “There is no mobile internet” debates). There are plenty of other people talking about it with probably more knowledge than I have.

This post is not to argue or teach others what to do but just to talk about a little detail seems to be forgotten sometimes.

I appreciate the extra effort the people pour in to make their website look better on mobile devices or smaller screens.
Most of the times, it really helps my browsing experience.

But sometimes they seem to forget how advanced the mobile and web technology is becoming.

One example is Chrome browser on all the different devices.
As far as you are logged in, your browsing history and bookmarks are shared between devices. It knows what were the webpages you were looking on your phone so you can open them again on your desktop and vice versa.

It’s not just the browsers.

There are many many chances that you send an email with a link to somebody or even to yourself while browsing on your mobile phone and the recipients may open it on their desktop exactly like my experience above.  

That brings forward the importance of being versatile between devices.

In many cases if you open a webpage saved or sent from desktop on your mobile web browser, it correctly shows the mobile version of the page.

What it seems to be often forgotten is the opposite case.

Even a big company like BBC ( has forgotten it.

Maybe it’s like that so the developers can check the mobile version of website easily on their developing process, or just a simple memory loss, or hasn’t been considered at all, I am not sure.


A Little Thought…

One way to fix this quickly is just not to forget to check what device the webpage is opened on even on the mobile version of the website.

However, if you can afford to re-make the website, probably one of the most manageable ways of ensuring cross device experience will be using responsive web design. This may bring another good old everyone’s favourite debate of what and how responsive design should work but that is another story.

May your tool be Twitter Bootstrap (, Skeleton (, or HTML KickStart ( or whatever you choose to work with for an easier start, or even your own creation.

Responsive web design lifts at least the burden of managing two or more different versions of the same page or template for different devices and it comes with an extra peace of mind that you don’t have to worry about the different devices and screens available on the wild all the time.

Another side effect of responsive design I like is that it makes the user experience less cluttered by forcing the designers and developers to think more about what and how to show and not, of course that’s if they are bothered to be bothered…


Functions to consider for Mobile testing

by Samera Butt

Having a mobile version of an application has now become a must. With mobile devices ranging from different OS platforms and tabletdevices – as testers, we have a lot on our plate!!

However, there are key points that we must consider whilst drafting out test plans and scripts for any mobile device. In this blog I attempt to cover some of the key points along with functional testing we should consider for mobile testing…

User Interface

Unlike our desktops, mobile devices come with various interfaces, from small screens that can be re-orientated when the device is physically rotated, touchscreen only devices to those which allow a combination of touchscreen and hard keypads, soft keypad only and not forgetting the various navigation methods such as hard keys and trackballs.

Being familiar with the device you are/will be testing on is important, if you are not, ensure you have a play around with it before testing. Check for the following:

  • Check for overall colour scheme/themes of the device. For example, Windows phone allow you to change the accent colour and background colours.
  • Style and colour of icons
  • Progress indicators when pages are loaded
  • Menu’s – how they are invoked and typical items they contain
  • Overall responsiveness of the application on the device

Screen Orientation/resolution: Applications should be tested in portrait and landscape view. Rotating the device fast, and checking to see the application’s response and errors

Touchscreens: Things to consider when testing touch screens are:

  • Multi-touch such as : pinch to zoom and single touch.
  • Long touch and short touch. For example, on some phones, pressing and holding an item will bring up a context menu, or a secondary function of a button.

Button Size & Position: Buttons and icons should be large enough to be seen clearly and be clickable by a fingertip.

Workflow: Use of radio buttons and checkboxes to minimize the amount of typing required, as this can be time consuming.

External Factors

Factors such as interaction with other devices and interruptions from the devices own functions such as incoming phone calls should be considered.

Factors to consider are:

  • Loss of Network Connections
  • Memory Card usage
  • 3G Network, 4G network, 2G network
  • No SIM card in the device
  • In airplane mode
  • Test intermittent network scenarios that a user might encounter in the real world such as:
    • Walk out of Wi-Fi range so the connection automatically switches to 3G/2G (for example, in a large building like a hospital or airport, or outdoors)
    • Ride in a lift or on a train where the network connection may go up and down
    • No network connection available at all

Device Options such as Screen Timeout/Auto on/off: Is your application subject to screen dimming or automatically turning off even when it is actually busy? For example, you wouldn’t want your screen to dim or turn off while watching a slideshow of your photos.

Screen orientation: You may be able to enable/disable automatic orientation switches when the device is rotated. Does your application apply the setting set on the device?

Font: Does choosing a different font family, size, or style affect the appearance and usability of your application?

Connections: Using one of the connections on a device, such as Bluetooth or Microsoft Direct Push (only on Windows Phone devices), could have adverse effects on your application. How does enabling/disabling Bluetooth or other connection types affect your applications behaviour?

Emulator Use

Can be a great way to achieve testing coverage across multiple devices, but it is not safe to assume that just because your application works on an emulator, it will work on the actual device itself. When using Emulators, it is important to consider the following points:

  • Not all activities can be realistically emulated, like switching network connections, or taking a picture or video.
  • Some activities don’t work at all on emulators, like streaming video on a Blackberry emulator.
  • Due to lower device power and memory, the application could exhibit slower performance overall when run on an actual device (versus in an emulator on your powerful desktop computer).
  • If the emulator and actual device have different resolutions, your screens may not display as you expect.

Stress Testing

Mobile device applications have much less memory and power available than PC’s

Security Testing

This applies to applications which require sensitive data storage such as banking applications, and how the application behaves under various device permission schemes.

Mobile devices will no doubt continue to grow, and as testers we will need to keep up to date with the latest gadgets out there to keep on top of the latest changes in OS and functions belonging to a gadget. No doubt the device functions discussed in this blog will continue to grow.



QCon Notes Part 2: The Future Application Platform

by Can Gencer

Unsurprisingly, there were several talks about the web and JavaScript at QCon. There is no doubt about the meteoric rise of JavaScript in the recent years, and it’s hard to imagine that this will not continue. Web browsers have been powered by JavaScript for years and more and more desktop applications are moving to the web. Node.js proved that JavaScript is as good as any other language for building a framework for web applications. Mobile web seems to be the next frontier and where progress seems to be among the fastest.

JavaScript Today and Tomorrow: Evolving the Ambient Language of the Ambient Computing Era

Allen Wirfs-Brock (Mozilla)

Download Slides

Allen is a Mozilla Research Fellow and was the project editor for the ECMAScript 5/5.1 standard.

Allen started off his talk by illustrating the two major eras in computing, the corporate computing era and the personal computing era. A major shift in computing happened in the late 70s and early 80s, where the shift to personal computers radically changed the nature of computing. Currently, we are undergoing another significant shift to what could be called the “ambient computing” era. Ambient computing has the characteristics of being device based rather than computers and being ubiquitous.

Every computing era had a dominant application platform. The dominant platform emerged as the winner through a combination of market demand, good enough technical foundation and superior business execution. The dominant platform for the corporate computing era was IBM mainframes. In the personal computing era, the dominant platform was the combination of Microsoft Windows and Intel PC (much lovingly called Wintel). In the emerging ambient computing era, it is becoming clear that the new application platform will be the web.

Each computing era also had a canonical programming language – COBOL/Fortran for mainframes and C/C++ for personal computing. The canonical language for the web and thus the ambient computing era appears to be JavaScript. Allen brought up the interesting question about what could replace JavaScript and how that could happen. JavaScript, even with it’s quirks is “good enough” and there doesn’t seem to be any apparent way that it would be replaced by anything else. As such, his claim that “JavaScript will be the next canonical language for the next 20 years” seems spot on.

After the ECMAScript 4 fiasco, TC-39, the committee responsible for deciding the future of JavaScript, is moving a lot faster and is more driven and organized to improve the language. There are a lot of improvements to the JavaScript language coming with ECMAScript Harmony, which represents ECMAScript post version 5. Some might be considered controversial, such as the inclusion of classes, and are ongoing current discussion. Considering the slow browser adoption rate, even ES5 is not yet mainstream and will not be for a couple of years more. This unfortunately seems to be one of the biggest bottlenecks in moving the new ambient computing platform forward.

The Future of the Mobile Web Platform

Tobie Langel (Facebook)

Tobie is currently the chair of the Core Mobile Web Platform Community Group which is dedicated to accelerating the adoption of the Mobile Web as a platform for developing mobile applications. Tobie and his team at Facebook put a lot of effort into analysing the most popular native applications and finding out what capabilities were missing in web applications to make them on par with native applications in terms of user experience.

Facebook recently launched ringmark, a test suite aimed to accelerate the adoption of HTML5 across mobile devices and provide a common bar for implementations of the mobile web standards. Ringmark provides a series of concentric rings, where each ring is a suite of tests for testing mobile web app capabilities. There are currently three rings, however the intention is to continue the project by adding more rings as the capabilities of mobile devices increase.

Ring 0 is designed as the intersection of the current state of iOS and Android and 30% of the top 100 native mobile applications can be implemented using ring 0 capabilities.

Ring 1 includes features such as image capture, indexDB and AppCache. Browsers implementing ring 1 should be able to cater to 90% of the most popular native applications, most of which actually don’t or need utilize advanced device capabilities such as 3D. Tobie highlighted that getting ubiquitous ring 1 support should be the short term goal for mobile browser vendors and developers to drive mobile web adoption.

Ring 2 will fill the gap with the final 10% of applications, with things like WebGL, Web Intents and permissions. Ring 2 is aimed to be a longer term goal.

Mobile Web should also be able to achieve beyond 100% of the native apps, with capabilities such as hyperlocal applications (e.g. an application tailored to a certain local event) and deep linking.

Lack of standards for mobile web applications when it comes discoverability or manifest files was also mentioned as one of the hurdles that mobile web needs to overcome. It will be exciting to see how fast we will be able to reach there.

The Future Is Integrated: A Coherent Vision For Web API Evolution

Alex Russell (Google)

Slides (Built with HTML5!)

Alex is a TC-39 representative for Google and is also a member of the Chrome team. One of Alex’s missions has been to drive the web platform forward. He is as frustrated as the rest of us developers with the current state of fragmented support and slow progress.

WebIDL and JavaScript have a cognitive dissonance problem. DOM was specified as an API for the browser programmers rather than the actual consumers of the API who are the JavaScript/web developers. It was also devised at a time where there were expectations that other languages than JavaScript would be consuming it, and artifacts of such an ideal still persist in the API. Moreover, DOM does not conform to normal JavaScript rules. The DOM types cannot be extended or constructured. It is not possible to do a new HTMLElement() whereas it would be very useful for many scenarios.

As web applications have increased in complexity, the disconnect between application data and the browser model has grown making web development painful. The developers have been trying to solve this using frameworks such as Backbone.js, however they are not perfect. Alex outlined two proposals to W3C that seek to make web development easier.

Shadow DOM is a way to create web components by a browser provided API. Modern browsers include native controls, such as the standard HTML form components. These built in controls are isolated from the rest of the page and are only accessible through whatever API they expose. There is currently no API to create third party components with the same strong encapsulation enjoyed by the native components.

The other proposal is Model-driven Views which reminded me a lot of how Knockout.js works. MDV provides a way to build data driven, dynamic web pages through data binding and templating via native browser support.


Also interesting, but didn’t get the chance to attend:

Mobile, HTML5 and the cross-platform promise

Maximiliano Firtman

Download Slides

Wrap Up

The various efforts around HTML 5, JavaScript and the mobile web all point to an improved developer experience. The question is how soon will this future will arrive? Combined with browser vendors pushing updates aggressively and consumers changing mobile phones every 1-2 years, it might not be as far as it seems. Listening to the talks also confirmed my opinion that native mobile apps are only a stopgap solution and the future lies in HTML 5+ and JavaScript as the platform that will power applications in the future.