As this year reaches its end, there had been the usual flood of articles offering a glimpse into the crystal ball of the web, predicting which web design trends will become hot in 2018. Will it be CSS grids, more typographic endeavours, more videos? Nobody knows. But while all these predictions seem to be based on which trends had already peaked in the year before, none of which seems to really offer true innovations, i.e. novelties that introduce completely new ways of thinking, designing and developing websites. Don’t get me wrong, much of it is a delight to see, simplifies every day work or brings in a shift in aesthetics. But ultimately, the possibility to do that was already there.
So far, the developers’ view seems to be missed from the discussion and while I’m a bit weary of crystal ball gazing, I admit it could be fun to think of how the many great technologies that were introduced in the last months and years could finally see a more widespread or a more creative usage. This non-exhaustive list is somewhat based on how much client support has improved (as a percentage of the total population of users) and what I find exciting enough to delve into.
Technical advances
- Performance improvements
Performance had always been a key interest of web developers. How fast does a website load on a weak connection? How long does it take until the first meaningful paint? How fluid are animations? After all, these factors are key ingredients to a consistent and unimpeded user experience (read: money). Both the tech and awareness to reach this goal had already been good, and they are still getting better. 2017 saw the adoption of several new technologies and there is no sign of stopping that more developers, more websites and more users will benefit from them.
On the server side, HTTP/2 is gaining support in shared and cloud hosting, where developers rely on third-party technology and the majority of websites are distributed from. Just as SSL is basically not an option but a mandatory step to a better web now, HTTP/2 could become the de facto standard in 2018 to deliver assets significantly quicker and provide a large cut in loading time.
The WebP standard on the other hand didn’t see much adoption on smaller and medium size websites, which I believe could be because for it to be practical either the content editors need to learn about it or CMS should automatically convert images on upload. At least whenever I see a WebP in the wild, it’s on a static or very large website. In any case, client adoption picked up and the introduction of the Accept: image/webp header made it easier for developers to serve the new image format only to those browsers who can handle it. After all, the savings in bandwidth are promising and WebP could well become a new raster image standard stepping out of the shade of jpeg, png and gif.
- Offline first
Over the years, several paradigms of front-end development emerged, found advocates and critics, only to be replaced by newer, more appropriate seeming concepts: first responsive and adaptive design, then mobile-first and desktop-first, and lastly offline first (I’m sure I missed some). If there is a progress to be found in this series of principles, then it could be that of user and device inclusiveness. After all, we want our products to look good and perform well on as many devices as possible (within our budget and timeframe) and thus we have to look for more edge cases. So far, the culmination of this is in the question “what about offline users?”.
Offline first development relies heavily on the Service Workers API which had only this year got enough traction for most developers to become aware of. In short, the very powerful API offers a lot of control over the browser’s cache, even if the website in question is not running in a browser window. It can also be used for load balancing, virtual servers and, probably most excitingly: offline content. It is now possible to cache select assets and even a complete website, update them if needed and – with the online and offline event listeners – seamlessly react on a sudden connection loss. I suspect that such provisions will become standard features of any medium and large scale website in the next months and years.
- Increased use of WebGL
WebGL had not only been a keen interest of mine but also of many other developers. It brings very powerful, close to state-of-the-art image rendering and animation capabilities to the web and offers designers a completely new playground to work with. However, for a typical front-end developer the C-like language of GLSL and its parallel processing paradigm (i.e. parallel instead of serial pixel-wise operations) are not easy to pick up. Thus it was not surprising that libraries such as Three.js became popular in the last years, which abstract the browser-side negotiation into a handful of easy to understand commands and let the developers focus on the core components, the shaders and the mathematics needed.
More and more developers start to become comfortable with the (somewhat old) language, blogs, forums and StackOverflow threads pop up everywhere and thus it becomes easier for a newbie to learn the trade and create awesome stuff themselves.
- More powerful WYSIWYG user experience and designer-cum-developers
Designers and developers alike had been hoping for more flexible and modular practices that can prove themselves to work in every-day content editing. After all, on a CMS-based website what is the fanciest and most beautiful implementation worth if the content editors can’t access the full potential? Modular design had been a key interest for all parties and page builders like Visual Composer and meta data managers such as Advanced Custom Fields (both for WordPress) became the simultaneously loved and hated tools many websites seem not to be able to give up on. But while they are either too restricted or too flexible to produce consistent results with no headache, they put content editors in the spot to use the design principles presented to them to the fullest.
This leads to two important trends: the development of more refined WYSIWYG editors and the rise of the the designer-cum-developer. To keep the example of WordPress, its manufacturer Auttomatic announced to ship their own page builder “Gutenberg”out-of-the-box with the next major release, thereby bringing customisation capability to many more users than before. So far, reviews of the preliminary versions have been mixed, but the signal is clear: Design customisation will be a natural feature every developer has to face – at least in the WordPress sphere, but given its popularity other CMS will feel the pressure to close up if they don’t already have their own solutions in place. Once the technology is in place, naturally designers will feel more inclined to pick up at least basic development skills to use the tools more efficiently – perhaps even cutting out front-end developers from the easiest jobs, effectively adopting work which now the dreaded WordPress-mix-and-match-developers occupy.
Creative uses
While the aforementioned developments could affect the majority of the websites since client and/or server support is widespread, some technologies are progressing more slowly, seeing less browser support, but opening up the stage for many creative uses.
- Device APIs
There are already a wide variety of more or less powerful APIs in place that allow a closer interaction of a website and the device its running on. The spec has already been there and while in many cases browser support became widespread enough to warrant default usage, others only recently became manageable to the average developer with the help of robust and flexible libraries. The Device Orientation and the Device Motion APIs (“Gyroscope”) already see a lot of usage in more experimental websites and while the mathematics needed to produce reliable and accurate results, some libraries already provide the necessary abstraction to focus on the creative side. While the Geolocation API had been around for much longer, the position of the device in space can now be measured on an arbitrary scale.
Similarly, the Vibration API allows the control of a device’s micromotors to give haptic feedback, even allowing for complex patterns. It’s supported by many browsers, alas, iOS users are out of luck for now.
- WebAudio and WebSpeech APIs
It’s not a long time ago that unexpected audio content on the web had been frowned upon. I’d argue it still is, but more creative, experimental and unconventional websites get a pass, in fact can significantly benefit from it. When in the past this was limited to sound files being played at some point, on-the-fly synthesis of sound had by far and large been unfeasible if not outright impossible. Enter the WebAudio API. The spec is already surprisingly old, however only recently could developers draw on libraries and frameworks that offer a more flexible and elegant usage of the somewhat cumbersome API. With these it is relatively easy now to build web-based synthesizers, turn data into generative sound art, and even to compose songs.
The WebSpeech API on the other hand complements the browser’s capabilities with speech synthesis and recognition, both on a level of sophistication that allows usage for many basic purposes. A pure speech based website navigation is now as feasible as narrated content – only two applications I can well imagine seeing some use in creative and experimental websites. Also, check out the German tutorial on both APIs I published earlier.
Honourable mentions of exciting technology and features I can’t delve into for now
Some technical advances are on the horizon or are supported by very few browsers, however could become more refined over time. They could be used for many interesting projects, however they are off the table for any serious application, since one would have to target a very specific audience, but they offer enough creative potential to not at least tinker around with them.
Since I can’t go into too much detail, I’ll just name them and encourage to do your own research and see if there is some (creative) potential for your own needs:
Wrap-up
That concludes the list for now. I am sure other developers have different, perhaps even widely contradicting perspectives and I wonder what they are excited about and what they imagine for the next year to become an important tool in web development. Is it the rise of JavaScript framework x or the fall of y, is it the return to vanilla JavaScript or perhaps a shift in market and labour structures?