HTTP/2, smaller is better
The new protocol is the bees knees. The browser vendors obviously think so, they’ve all gone and implemented it. Grid layout is obviously too much to ask for. Some of the new features in HTTP/2 like multi tenancy and header compression are really nice, even considering the tradeoffs they might have. For me the idea of loading smaller modules instead of larger bundles because it is faster is great news. Loading only those modules you need is faster again. The performance gain alone makes the modular approach the way all large sites will be built and http/2 they way they’re delivered.
ECMAScript 2015 (aka ES6)
Loads and
loads of new features that
have been a long time coming and modules being one of my favourites. A shame objects didn’t
get much love but more is coming. Also
fetch and
async would be improvements over
XMLHttpRequest when dealing dynamic code and content. Especially with the rising
popularity of API architectures.
Normally a web site/application would be built in three silos. HTML is usually some kind of server side template and is ironically the last thing a front-ender gets to control and CSS is purely a browser driven affaire with application developers viewing it as a black box. JavaScript would often live in both html on the server and in the browser and this duality has only gotten more pronounced over time. More JavaScript in the browser and more presence on the server with nodejs and vert.x. JavaScript is the front-end King and it has taken the reigns of where the web is going. If you as front-ender or as a web developer haven’t joined the JavaScript bandwagon by now you may want to reconsider as both CSS and application logic are moving to the JavaScript domain in either the control of assets or even, to the extreme, in code. Yes, CSS and HTML in JavaScript, and developers are doing this and they’re loving it. I have my reservations but the horse has left the barn.
A trait of modular web development is that a module wants to contain the markup, styling, UI behaviour, business logic, tests and documentation. A good module should be easy to build, easy to change and easy to throw away. This, to me, doesn’t sound anything like the traditional three silo approach of the web stack which is really easy to build, parts are usually somewhat changeable but most of the site is near impossible to remove. Legacy code is a major bugbear for any site above a certain size and a modular approach makes this less painful. Not pain free, but the opportunity for incremental change is a reality.
The full stack developer (formerly known as a unicorn) or, more likely, an (agile) development team ought to be able to take full ownership of a number of modules. This is an ideal situation for any team. The modular web is here to stay and will become how we think of the web, how we build it and how we change it. More performance, more control, well, I’m all in. Except for the CSS in JavaScript bit, that’s just silly.