Saturday, February 28, 2015

Thursday, February 26, 2015

Version 5.0 web frameworks

Version 5.0 web frameworks

When you are reading this on a modern mobile device running Chrome, Firefox or Safari you are seeing G+ as a shiny new web app (And if you are on Desktop and read this post you know how to change your user agent :). While I don't work on the product directly, me and others have spend significant effort making the underlying infrastructure work. I'm extremely happy to see this launch and want to thank the team for pushing this through, so I have something to point at that I'm very proud of :)

Of course, I immediately got lots of questions about the underlying technology – and that is cool, I'd be wondering the same thing. The fact is that in 2015 we have so many great options available – Polymer, Angular, Ember, React, etc. will all enable you do built great products. One may have strong opinions which one is better, but one cannot argue that they aren't great for the particular use case they were designed for.

This is awesome.

On the other hand, there have been lots of discussions lately around the theme of "the DOM being slow", etc. While it can always be better, I think most of the discussion misses the point of what the real underlying problem is:

We still don't know how to make good software and if the platform doesn't particularly help everything falls apart even quicker.

But do we actually not know? Many of us building web apps have done it wrong so many times now that I would argue we have sufficient experience to finally get it right: scaling software development in the context of the web platform.

The key issues that we addressed when building out the platform underlying this launch is:

Engineers will eventually write too much code, because that is what they do. Period. How can we make sure that we only ever load the subset that we actually need, like, right now?

Related to the above, but subtly different: Given that the application is going to be big, how do we figure out what subset of it is actually, you know, still used. Sounds easy, I dare you to look at your CSS files and tell me for each line whether it actually matches anything in your app. (See Shubhie Panicker's excellent talk how we address the CSS issue https://www.youtube.com/watch?v=_MD1WQclOJM)

We know the DOM is slow. How can we make sure that we hit the best case and not regress as dozens of engineers want to animate different parts of the page at the same time. https://plus.google.com/+MalteUbl/posts/ifuDKtfCrGL explains parts of the strategy. This has worked wonders for us already. More than 1 style recalc per animation frame is almost extinct.

And finally: Isolation of complexity. Web components in part address this topic and they greatly enhance your ability to reason about side effects in the DOM. But the DOM is only part of your application. We tried to bring web component like isolation to the other parts of the stack as well: data (fetching), JS dependencies (think require), testing. This being a large topic, I'll leave more details to another post.

In summary: Yes, the platform has its quirks, but it is possible to manage the issues – and many problems are mis-attributed to general problems in software engineering and should be addressed as such.

I called this post the "version 5.0" web framework, because we basically reached a stage where almost every framework available to us is great and mature and, more importantly, we have significant experience actually using them. The next generation of frameworks will need to apply what we learned and focus on scaling the human part of the software equation.

Sunday, February 1, 2015

Retiring the awesome Burton Super Model X for a more Tahoe friendly Burton Barracuda (shorter and softer).


Retiring the awesome Burton Super Model X for a more Tahoe friendly Burton Barracuda (shorter and softer). Now where is the snow?