'.get_bloginfo('name').'

Andrew Hall

0 comments

Future of Web Apps – Session 7 – The Future of Web Apps – Yehuda Katz

This was live blogged

The future of web apps are in your hands

We have so much freedom to do this. When Apple or google announce a product it can feel like they have allowed us now to do this. And only happens once a year. On the web, we get lots of updates and this means that we get our hands on new things quicker

In 2004, there was one browser. IE. firefox did exist but it was in flux
The standards body were working on XHTML. these days it does better things!
Even though people weren’t doing much to progress the state of the playing field, we had been given JavaScript, which allowed us to continue to develop on the web.

In 2004, we had some basic css selectors (version 1) and if we wanted to add a new feature we had to completely reverse engineer the whole thing just to add one tiny feature.

Another example of form serialisation, when you submitted a form, it could serialise data before sending it.
If you wanted to extend this, you had to go and rewrite the entire thing to do this. It wasn’t easy.

People built lots and lots of extensions for the platform, but there are limits.
For example speed, these extensions were slow!

There are also issues with unexposed functionality. The browser could do all these things but as JavaScript developers we cannot access these.

We could get around some of these things through hacks but this clearly isn’t the right way!

Also we couldn’t work well with device capabilities. When the ipHone came out, suddenly you were using a real device with a real screen and you only do the desktop functionality.

In the past, browsers took a long time to upload. This means we were waiting a long time for features to come out on the web. Also the features that were released were too high level. They gave us a date picker on the input type, but no way to change the date format.

Around 2012, people started to address these issues. Users are good at building abstractions, so let’s give them the lower level access and let them build whatever they need. we’re still not quite there yet and there are still issues
Around a similar time, JavaScript got quicker. There was a 100x speed increase in JavaScript.

We were also given lower level access to memory. Typed arrays allow us to do much lower level things like gZip.

Asm.js is just a massive hack to make JavaScript code very close to native speed by using tweaks on the language for memory allocation.

The features that the web was lacking, like sockets, graphics libraries and storage now we do have access to but again is not perfect

Custom elements and mutations observers are on the way. Custom elements tells the browser to instead of rendering the element in the default way, run out JavaScript code.
Mutation observers fire events when the Dom changes.

the URL() API let’s us parse parts of the url exactly how we want it to instead of faking an a element and hacking it, it’s a proper way to do it.

Before we can expose new functionality we need to go back and work out what happens in the past. This is what WHATWG are doing.

Coming soon:

Service worker
This is like a proxy for your data (see Bruce’s talk from this morning)
It allows offline by default

More device capabilities
But we need to be careful here and use content security policy

Web video
The audio tag exists and web audio API let’s us do stuff. But there’s not the same thing for video

And in the future:

What is and iframe made of?
Scope
Shadow Dom
Service worker
Renderer
Event loop

Can we get rid of iframes if we had raw access to the parts?

There are also things that we don’t know how they work.
How does rendering work?
How does css work?

Let’s change how standards are written. Let’s expose lower level primitives and let users build on this!
Let’s be more open and let users experiment.

WE ARE THE FUTURE!
It’s a partnership between browser vendors and web developers

Leave a comment or tweet me