“I rest my case”

So there it was tonight. Some criticism on my talk/slides called “Let’s live inside the browser”. In a tweet Ivo Jansch, a well known and respected person in the PHP community, expressed how the lack of cross-browser compatibility of my slides proves why “living in the browser” is not gonna happen. Or well, that’s more or less what i think his tweet implies.
In this specific case i think the reasoning is unjustified as i didn’t program mouse control, although that’s a good idea! But of course it’s ironic that my presentation about living inside the browser lacks support for convenient input (you have to use the keyboard left/right arrows).

Anyway, this is a discussion i was hoping to start with my presentation. The discussion about if and how we will end up living inside the browser. And for obvious reasons the native vs. web apps thing is a big part of the discussion.
I have already posted my thoughts on why i think the web is suitable as an application platform a couple of days ago, but i feel that post is not comprehensive enough, so i’ll add some more thoughts.

Web apps vs. native apps
This is an interesting one. If you’re thinking mobile then, as for now, native apps win in terms of functionality and possibly user experience. Simple.

However i don’t think that the web as an application platform becoming more common will rule out native applications per se. Maybe eventually, but that takes years, maybe even decades. If it is at all.

Choosing the web as an application platform is choosing for an easy way to deliver to every device with a browser, instead of limiting to a certain vendor.
However if you choose web, you limit yourself to the use of API’s available through the browser or web services. This is a limitation that should not be underestimated, and is where native applications win big time

Of course, there are these hybrid solutions like the awesome PhoneGap. These enable you to write applications using web standards, and abstract the device specific API’s so you can still develop for cross-platform solutions, but deploy to multiple ones.
I guess this is okay solution, but it shows there’s still lots of work to do regarding web standards. And even then, web standards will always be behind the features “native” API’s provide.

Other concerns
Without a doubt, choosing between the web or native platform for a project is also dependent on the business model behind of your project.
I’d say the web provides more freedom for implementations, which encourages innovation. On the other side, native platforms, and especially mobile platforms have built-in mechanisms to monetize through your application.

Another big thing is the capability difference between desktop and mobile browsers. Mobile browsers, and especially the Android browser are lacking (draft) standard support already, which slow the large adoption of the web as an application platform. But although the mobile browsers seem to be behind on functionality, web developers have always been inventive in finding work-arounds for these issues.

So.. the web huh?
Yeah, i still believe there is a big future for the web as an application platform. And even though native apps are really powerful, the reach of applications is obviously a lot bigger.
With the web standards always in development the web will slowly become more and more suitable for deploying and distributing applications.

Although i feel this post is still not comprehensive enough, i hope i expressed my point of view of this topic.

In the end of the discussion Ivo mentioned the idea of a “web vs native bar fight” with presentations with the standpoints of each camp.
While this sounds like a whole lot fun (i’m definitely up for it!), i’m feeling more for an open discussion with the aim to share thoughts. It’s an interesting but also really important topic to share thoughts on. Preferably with people from different backgrounds.

Anyone want to help set up a meeting for it? I’m not so familiar with it..

How HTML5 Web Workers make unicorns run

A unicornOne of the things that HTML5 brings us is Web Workers. These things are great for enhancing user experience in webapplications or javascripts that contain heavy computations or other sort of long running scripts.

Web Workers are like threads, which you might know from other development platforms. The definition of threading is the following according to Wikipedia:

“The threaded programming model provides developers with a useful abstraction of concurrent execution.”

Let’s start with identifying the problem.
For the working example for this post, check out this page and hit the ‘Freeze’ button. Under this freeze button there is a function that does a huge secret calculation that is supposed to use a lot of your CPU’s time. Actually it’s not that secret, see code sample 1 for the code. Notice that the unicorn stops moving for a while when you press that button. The freeze function is freezing the UI while executing. (Thank you Captain Obvious). See diagram 1.

// Code sample 1 - Secret freeze function
function freeze() {
    var total = 0;
    for (var i = 0; i < 100000; i++)
        for (var k = 0; k < 20000; k++) total++;
    return total;

Diagram 1 - Single threaded script execution

Obviously, this causes the user to wait, and that’s bad practice. Nobody likes to wait.
Web Workers enable you to start another thread that can process computations parallel to the browser’s so-called UI thread. (That executes your “normal” javascript)
With the result of not blocking the user interface.
Simply put; you delegate your heavy computations to another process, which, when ready, will send the result back to your UI thread. This is visualized in diagram 2.

Diagram 2 - Multi threaded script execution

Delegating the long running function to another thread leaves computing space in the UI thread open for other computations. UI computations of course, as it is the UI thread.
Doing this is actually quite simple, and requires to put your code in a new javascript file that will  execute in the worker’s context. Running a script in the worker context means that the script does not have access to the DOM or anything else that is not thread-safe.

Exchanging data between the UI and Worker is being done by the Worker.postMessage method. This method requires one parameter, the data you want to send.
This data is internally serialized as JSON by most browsers to prevent callbacks or other pointers being passed (which would potentially cause cross thread errors). (source)
Code example 2 demonstrates how to create a worker in javascript, and code example 3 demonstrates how the worker script itself should be defined. Notice that event handlers/callbacks are used to start and communicate between the Worker and the UI thread.

// Code example 2 - Creating the Worker and listen to onmessage
var worker = new Worker('webworker.js');
worker.addEventListener('message', function (event) {
    document.getElementById('calculation').textContent = event.data;
}, false);
// Code example 3 - webworker.js
self.addEventListener('message', function(event) {
    var total = 0;
    for (var i = 0; i < 100000; i++) {
        for (var k = 0; k < 30000; k++) {
}, false);

Inside webworker.js, the self keyword is used to approach the Worker’s API. In here you also see that we add a listener to the onmessage event, and use the Worker.postMessage method to send the output back to the UI thread.
You can start the worker from the UI thread (your normal HTML page or javascript) by using the Worker.postMessage method, as seen in code example 4.

// Code example 4 - Starting the worker
var worker = new Worker('webworker.js');
worker.addEventListener('message', function (event) {
    document.getElementById('calculation').textContent = event.data;
}, false);

worker.postMessage(null); // postMessage parameter accepts everything that’s serializable.

Obviously, you don’t want to stop a unicorn from running across your screen. So if you delegate the freeze function to a Web Worker, you get the result as in diagram 3.

Diagram 3 - Delegate the big calculation to another thread/worker, so the unicorn can keep running

Now click the “Via worker” button in the working example page.
Yay awesome, the unicorn can continue to run across your screen in the meantime! So yes, that’s what Web Workers are good for, making unicorns run across your screen.

No but seriously, i couldn’t think of a more interesting use-case.. But you can fill in your own use-case for a long running function that causes the UI thread to block.

Of course, you want to know in which browsers Web Workers are supported. Fortunately, on desktop browsers the Web Workers are widely supported (although, IE10+). A bit less fortunate is the support on mobile browsers, with the exception of Opera Mobile 11 no mobile browser supports Web Workers. For a comprehensive overview of supported browsers, take a look at the MDN page “Using web workers”.

A more in-depth explanation of HTML5 Web Workers can be found at the HTML5 Rocks website.

Why i think the web as a platform is the future

Lately i have found myself thinking about why applications built on web standards are becoming more and more common. What is it that draws us all to this amazing place called the web? And why are more and more companies investing in applications based on web standards?
Personally i am really enthusiastic about the direction the “applicationscape” is heading and i  think web applications have the potential to go a (really) long way.

But seriously, why?

I think the answer lies in how people consume information. It seems we have this (subconcious?) urge to find and use information as effective as possible. And the technology of today has brought us to the point that we want this information anywhere, and we want it NOW.

There are a lot of ways to consume information in modern (internet) times: PC’s, laptops, tablets, smartphones and what not. Each of them having their own vendors and platforms but they also have their own distinctive level of speed, mobility and have different input mechanisms. Each device is used different.
However, important to note is that all these devices serve the same purpose: to serve information.

There is an important thing that, nowadays, all of these devices have in common, and that is that they have a web browser. So all of these devices have access to the web.
That is what makes the web so interesting as a platform. The reach is enormous.
Online, offline, anywhere and any time, on any device. The world wide web is a shared platform across devices already. Regardless of operating system.

An important downside of developing applications for multiple platforms is that it is time consuming. Another downside is that, for various reasons, the different applications you end up with do not always contain the same functionality. Now i can see sometimes this is because the project is on a time constraint, but an often heard reason is that to offer users of different devices the best user experience.
Now there is a big difference between offering a different user experience based on certain context parameters and designing an different application for each platform possibly limiting users access to certain functionality of your original product.

Now this is where i think the web as a platform has it’s potential and can offer more for both end-users and developers. Of course, web applications do not offer the same functionality as native applications at this time, but i think this is a matter of time. The open web standards have become really mature at present time, and i think it is time that we start embracing the web as a platform.

And what about you? I would love to hear your thoughts about the web as a platform in the comments and get some discussion going around this…

On September 17th i am speaking at the PFcongres (in dutch) about the web as a platform and what technologies you can use today to develop for it as such. If you are interested in this topic, or even if you are not (the other speakers on schedule cover amazing subjects!!) PFcongres is the place to be in Utrecht this saturday!