Evolution of the Web towards Web 3.0
The real modern Web — I guess we’ll call that ‘Web 3.0’ — is really getting closer and closer and guess what? It’s also up to you to make it real.
Since my last Web development project (2012), many things have changed and evolved on the Web; its evolution pace is simply astonishing. HTML5, CSS3 and many WhatWG specifications are now pretty well supported by major browsers. You could say that we currently live the Web 2.5 era.
The real game changer now is that Microsoft has finally decided to retire IE and introduce Spartan, a legacy-free modern Web browser.
When you take a look at what Microsoft has announced for Spartan and their roadmap, you can only feel GOOD if you’re a Web enthusiast.
Nearly gone are the days where you had to play around IE’s quirks, battle against box model issues, resort to IE-specific conditional tags, use X-UA-Compatible and all that crap just to get a WORKING application/design across browsers. Nearly gone are the days where you had to manually add 36000 browser-specific prefixes to your CSS stylesheets just to get a gradient and whatnot, …
We’re getting closer to a state of the Web browser landscape where we’ll finally be able to think less about browser compatibility issues and concentrate our efforts on actually creating useful and/or beautiful things that simply work everywhere. OK I’m getting a ahead of myself, but still there’s more hope today than there was back in 2012 ;-)
Just take a look at this list. Of course there could be more green stuff but it’s already pretty damn cool.
Who needs native applications?
Some people already think about the next step, the ‘Ambient Web Era’, an era where the Web will actually be everywhere. You could say that we’re already there, but I don’t agree. I think that we’ll only reach that state after the real boom of the Internet of Things, when the Web will really be on par with native applications, when I’ll be easily able to create a Web interface for managing my heating system using nothing but Web technologies (i.e., without all the current hoops that we need to get through to reach that point).
Adapting to the mobile world
I hear and read more and more about such ideas as mobile first, responsive web design, client-side UIs, offline first, … The modern Web standards and browser vendors try to cater for all those things that we’ve missed for so long: means to actually create engaging user experiences across devices. For example, with standards such as IndexedDB, File API and Local Storage, we’ll be able to save/load/cache data at the client side to allow our applications to work offline. WebGL and soon WebGL 2.0 allow us to take advantage of all the graphics chip horsepower while the canvas element and associated API allow us to draw in 2D. WebRTC enable real-time audio/video communications, then there are also WebSockets, etc. These are but a few out of many specs that we can actually leverage TODAY across modern Web browsers!
As far as I’m concerned, mobile first is already a reality, it’s just a question of time for awareness and maturity to rise among the Web developers crowd. CSS3 media queries and tons of CSS frameworks make it much easier to adapt our Web UIs to different device sizes and responsive Web design principles are now pretty clearly laid out.
But for me, mobile first is not enough; we need to care about and build application for people who live in the mobile world but don’t necessarily have fast/consistent connectivity (or simply choose to stay offline in some circumstances). We need to consider offline first as well. For example, although we’re in 2015, I’m still disconnected every 5 minutes or so while I’m on the train for my daily commute (though I live in Western Europe).
We must ensure that our Web applications handle disconnections gracefully. One way to do this is for example to cache data once we’ve loaded it or batch load stuff in advance (e.g., blog posts from the last two months). The term offline first is pretty well chosen because, just like security, it’s difficult to add that as an afterthought. When your application tries to interact with the server side (and those interactions should be well thought/limited/optimized) it needs to check the connectivity state first, maybe evaluate the connection speed and adapt to the current network conditions. For example you might choose to load a smaller/lighter version of some resource if the connection is slow.
Offline first ideas have been floating around for a while but I think that browser vendors can help us much more than they currently do. The offline first approach is still very immature and it’ll take time for the Web development community to discover and describe best practices as well as relevant UX principles and design patterns. Keep an eye on https://github.com/offlinefirst.
Application Cache can help in some regards but there are also many pitfalls to be aware of; I won’t delve into that, there’s already a great article about it over at A List Apart.
Service Workers will help us A LOT (background sync, push notifications, …). Unfortunately, even though there are some polyfills available, I’m not sure that they are production ready just yet.
There are also online/offline events which are already better supported and can help you detect the current browser connectivity status.
The device’s battery status might also need to be considered, but the overall browser support for the Battery Status API isn’t all that great for now.
In my new project, I’ll certainly try and create an offline-first experience. I think that I’ll mostly rely on LocalStorage, but I’d also like to integrate visual indications/user control regarding what is online/offline.
Client-side UIs – Why not earlier?
One thing I’ve mentioned at the beginning of the post is fact that client-side UIs gain more and more momentum and rightfully so. I believe that UIs will progressively shift towards the client side for multiple reasons, but first let’s review a bit of IT history :)
Historically, Web application architectures have been focusing on the server side of things, considering the client-side as nothing more than a dumb renderer. There were many important and obvious reasons for this.
Client-side UIs – Why now?
Today we are living in a world where mobile devices are everywhere. You don’t want to depend on the server for every interaction between the user and your application. What you want is for the application to run on the user’s device as independently as possible and only interact with the server if and when it’s really needed. Also, when interaction is needed, you only want useful data to be exchanged because mobile data plans cost $$$.
We have a gazillion JS libraries, JS frameworks, better developer tools included in modern browsers, we have better IDE support and even dedicated IDEs (e.g., Jetbrain’s WebStorm). And it all just keeps getting better and better.
Okay where was I headed? Ok I remember: server-side vs client-side. I think that given the above, we can probably agree that the client-side development world is much more mature today than it was at the beginning of the Web 2.0 and that client-side UIs make a hell of a lot more sense in today’s world.
My view of a modern Web application architecture is as follows; it might indeed not be applicable to all use cases but in many cases it certainly can:
- Client-side UI with HTML, CSS, JS, JS libs and a JS framework to keep the code base manageable/maintainable
- Server-side responsible exposing RESTful Web Services adapting the data representations to the specific clients
- Server-side responsible for enforcing the business rules and interacting with the rest of the infrastructure pieces
The benefits of this approach are multiple. Since the UI is fully managed on the client-side:
- only the necessary data needs to be exchanged between the client and the server (i.e., JSON vs full HTML page)
- the server-side can (and should) become stateless
- it can more easily adapt to the needs of the mobile-first & offline-first approaches
- the UI can be much more responsive and thus more ‘native-like’
- Since the UI is completely separated from the back-end, it can more easily be replaced
If you care for the Web even just a bit then you know this is the model we need to go towards.
You could say that ES6 hasn’t landed yet, but what prevents you from using it already?
If you work in a Java or .NET shop and don’t have actual Web developers at your disposal, then you might not be able to follow that path easily. It all depends on your organization’s culture and your people willingness/capability to learn new things and adapt.
I often like to compare the Web technology stack to the *NIX world: as an IT professional, what do you prefer? Learning stuff that’ll remain useful and beneficial to you for many years to come or learning stuff that you know will only be true/valid for a 3-4 years period? Or even worse yet: ignore market trends and market evolution? At some point you’ll have to adapt anyway and that’ll cost you.
Technology will always evolve but some technologies have much less interest for your professional career. If someone fresh out of school asked me today what to learn/what to focus on, I certainly would recommend learning as much as possible about the Web.
Here I’m not saying that the server-side is doomed, far from it. You just can’t expose your everything directly to the client-side. You need to place security boundaries somewhere. If you’re comfortable writing server-side code in Java, C#, PHP or whatever, then continue to do so, nothing forces you to switch to Go, NodeJS or anything else on that side of the fence. What I’m saying is that if you create a Web application, then you need to consider shifting the UI towards the client and if you’re serious about it, you must create a clear separation between both sides; to each its own responsibilities.
Another technology that I think will help us transition UIs towards the client side are Web components. The more I read about these, the more I think that they’re going to represent the next big thing (TM) in Web development. It’s unfortunate that we currently still need to resort to polyfills to be able to use these, but hopefully that won’t last too long. Browser vendors should finally agree upon a set of primitives/APIs to support that we can use (e.g., will HTML imports prevail?). I can’t expand much more on this because I haven’t played much with them yet, but they’re on my radar ^^.
Conclusion & my current plans
This post represents my current vision of the Web as it stands, its future and why I believe that it’s time to seriously consider shifting the UI towards the client-side (let’s hope that time will prove me right). This was a pretty long one but I think that sometimes it makes for a good exercise to try and articulate a vision.
As I’ve mentioned in a previous post, I’ve started a new personal project to replace this now dated Website with a more modern version.
Now that I’ve shared my vision for the future of the Web, I can expand a bit more on my plans for this new project. Rather than re-creating a full blown WordPress theme, I intend to use WordPress as a simple CMS without a frond-end of its own: I’ll keep using the administration space to manage the content but I’ll extract the data (posts, comments, pages, tags, etc) through the WP REST API (which will soon become part of WordPress’s core).
My goal is to create a modern, responsive, mobile-first, offline-first and (hopefully) good looking web front-end. Why? Because we can, today! :)
Also, I want to leverage multiple data sources:
On the technical side of things, I plan to use HTML5/CSS3 (haha), AngularJS and/or Meteor and/or Polymer (I haven’t chosen yet).
For the CSS part I intend to use SASS and I think that I’ll use Pure.CSS or Foundation. I might also take a peek at Foundation for Apps.. Finally, I’ll try and play with ES6 (through ES 6TO5).
For now I’ve only created a build based on Googles Web Starter Kit to make my life a bit easier, using NPM and Gulp. I’ve also added basic Docker support (though there’s much room for improvement there).
Well that’s it for today; please don’t hesitate to share your thoughts! ;-)