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!
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!
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
We were also given lower level access to memory. Typed arrays allow us to do much lower level things like gZip.
The features that the web was lacking, like sockets, graphics libraries and storage now we do have access to but again is not perfect
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.
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
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?
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