Where the web is going and how do we get there?

Adam Grimley
Kainos Applied Innovation
9 min readNov 21, 2017

--

Web technology is one of the fastest moving areas of software right now as we are in an era made of chromebooks and mobile focused development. As part of the Applied Innovation team at Kainos, I was given the opportunity to look more into what the next generation of Web development will be.

Users spend on average 69% of their media time on smartphones. — ComScore

One major development everyone is looking at is how to move from a web that has to be connected at all times, to a web that can be used everywhere — regardless of an internet connection. Every week there’s another version of a major browser with support for a brand new framework that is supposed to revolutionise the web. More often than not they solve a single one of the many issues at the time, only to be replaced with a different framework a few years later.

One of the major movers in this space is Google with their chrome developer team. Several years ago the team began work on one of the most revolutionary pieces of web technology: the service worker. What followed was the progressive web app movement.

Progressive web apps

A PWA (progressive web application) is in essence a website that is able to be fully functional while offline or on a very slow network. To do this, a service worker script will load the website and all necessary resources into your local cache then intercept your network requests if not network is found. The service worker’s end goal is to allow users to save a webpage to our desktop or home screen and use them as we use any other application. We can already do this with many sites on mobile, with desktop support coming in 2018.

I’ll refrain from going into too much detail on this as I feel like there are better people to explain everything about the service worker who I doubt I could match, such as Jake Archibald from the Google chrome developer team.

Cloudflare workers

While on the topic of service workers, it would be remiss of me to ignore cloudflare workers. This is a system built by cloudflare based on the service worker API which uses the exact same syntax as a normal service worker to interact directly with cloudflare’s edge network (not to be confused with the browser). For users of cloudflare, this means you can write a custom HTTP interception service to

  • Respond accordingly to HTTP requests to your domain
  • Improve the performance of the domain by splitting the request across multiple edge servers
  • Implement custom security rules and filters on top of cloudflares already extensive security suite
  • Respond reliably when the origin server is unavailable (a server side version of the regular SW which responds when a network is unavailable)

For users of cloudflare this allows more customisation than ever in your service. The downside to this is that because it is a large change in how cloudflare operates, it is being rolled out slowly. Definitely a service to keep your eye on if you use Cloudflare in any capacity.

You can sign up for the cloudflare worker beta here.

Web Assembly

Although service workers are the frontline forces in terms of the direction of the web, it’s not the only thing out there. Web assembly (often shortened to WASM online) is an emerging technology, supported by the W3C and all major browsers that allows developers to run low-level code, targeted at C/C++ currently, running at near-native speeds. It is able to do this by taking advantage of common modern hardware capabilities.

Based on asm.js, WASM runs in the exact same space as javascript in relation to your browser. This has many advantages, such as:

  • Allowing apps that use native languages to access web APIs.
  • An additional security in the form of an extra sandbox to run within.

It does not support languages with garbage collection as of writing, however support for this is coming soon and should be released in 2018. The end goal is to give developers the ability to develop and run languages in a web browser that were previously restricted to running in standalone applications.

WASM has great potential in the games industry and with a reported revenue of $101.1bn in the UK alone, and the online games industry is poised to push PC games onto WASM in the near future. Imagine that rather than downloading the steam desktop app then downloading the 30GB game, you can just head to a website with a unique key, sign in, then play the game there. Obviously large AAA games are a long way off this sort of distribution however we are already seeing independent games developers making use of the technology with the Construct 3 game engine now able to be used completely in the browser using WASM.

Last month at Google’s chrome developer summit Alex Danilo and Deepti Gandluri gave an excellent talk on where web assembly is and is going and is worth a look for more examples of the sheer power that WASM is capable of.

WebVR

Alongside WASM, there is another emerging technology that will be of use, not just by the games industry but by the web community in general: Web VR.

Konterball from Google’s WebVR experiments

WebVR is a technology that has been in a trial basis for a year or so now but currently (in the past 2 months) all major browsers have officially added native support for WebVR in its current form. This framework allows the execution of VR applications through a browser window at 60fps standard on all modern hardware. This is still experimental and does still have a few bugs however it is stable enough to have many uses already.

As we look for new ways move away from static videos or presentations, the opportunity is there for VR to make a move into the marketing space. WebVR already has frameworks such as a-frame which allow people with basic html knowledge to quickly create a 3D space and populate it with whatever they wish, giving the audience :

  • A space to explore visualised data
  • A memorable experience

This technology allows the development community to move away from standalone VR applications and will allow a more accessible entry for developers into the 3D VR space. Combined with the lowering cost of VR technology, now with google cardboard and Samsung GearVR both being available at a relatively low cost, it gives us cause to invest in unique VR spaces in both advertising and marketing.

In another way, imagine as an investor in technology you are going into your 4th pitch of the day, each previous pitch being around the same topic, all using the same powerpoint template and giving another pitch about a new tourism application or product they have developed for Belfast. Then you go into this 4th pitch and they simply hand you a gear VR instead of sitting at a table in front of a projector. You are then able to see a 3D model of the project, where it will be used and are walked through the presentation in a custom build 3D world. What pitch are you going to remember?

Web Bluetooth

Web Bluetooth is currently a set of APIs developed by google that allow web developers to detect and connect to Bluetooth 4.0 devices that are in range are in pairing mode. To pair to a device you need both permission from the browser and the device through it being in pairing mode.

Evidently there are some security concerns here however due to the connection between the devices currently, the site will only have access to devices a user grants access to, preventing those sites from messing with extra devices. For some context, web Bluetooth has more warnings to users before connecting to a device than both android and iOS apps.

Use cases are almost limitless with this technology. For instance say you have an application based on the (rather slow) MOT system in NI. Using new Bluetooth enabled tools, we would be able to connect to each tool and take live readings on each tool. As a mechanic, currently you have to do the test and manually input the results in a web system that will pass/fail the car and print out the certificates. What if, instead, the tools would be able to automatically log each test into the system so that at the end of the test, the mechanic no longer has to spend 5–10 minutes inputting details and printing each form. This removes a lot of the time spent both as a mechanic and as a customer at each test, increasing customer satisfaction while also increasing efficiency. Even if the connected tools only shave 3–4 minutes off each test, that added up to around 2 more appointments per day per mechanic.

Online payments

Google have released a new standard (which is now a W3C candidate to replace checkouts) called the credential management API. This would allow any vendor to request payment through a global payment API, leveraging several different types of payments. Using this service, the checkout process is much faster due to the browser storing credentials for a global one click checkout.

taken from the google developer payments page

This API is designed to be vendor agnostic, meaning it’s built as a cross-platform API that can be used by all web developers. This API from google also takes away all the issues of actually buying and places it into what is essentially an autofill box that will do everything for you. Rather than going through 8 forms, 5 capatchas and a new account for some service you’ll only ever use once (we’ve all been there), you just press a single button.

Not to become a google advertisement but Sam Dutton and Rowan Merewood gave a talk on e-commerce last week at the chrome developer summit which is worth a look for the statistics behind this API.

HTTP/2

Thought I had forgotten about this?

When people think about new web technologies that will increase performance or do that one amazing thing they need to finish their billion dollar idea, everyone looks to HTTP/2. Please excuse me while I put a cap on your expectations.

For those who don’t know, HTTP/2 is a rewrite of the common HTTP protocol we all use, expanding on it’s features and fixing a few problems along the way. The 4 main differences it professes to have are:

  • Use binary to transfer data, not text
  • Use header compression to reduce overhead
  • Multiplexed to allow parallelism
  • Allow servers to proactively push to clients

As it stands, HTTP/2 can only be used over a TLS secured website, is completely backwards compatible and is fully supported by all major browsers. This is all well and good when it works, and to its credit usually does. It’s the most revolutionary function that is iffy at best right now: the push function.

This would theoretically allow browsers to have all resources needed in one connection request instead of getting HTML, then request the CSS, etc. This saves both time and network traffic. When it works. It’s still in development and the bugs are getting ironed out as we speak (or as you read) but don’t hold your breath just yet for that silver bullet that will save all your website ideas from certain doom… or an archived git repo.

https://xkcd.com/927/

In Conclusion, all of these technologies I have listed are very easy to start implementing today in whatever way you see fit. They are all now supported by all major browsers along with W3C, with documentation on MDN. There’s nothing stopping you from getting ahead of the game in terms of web technology today, it won’t be long until we are looking at frameworks that build upon these technologies so why not get your foot in the door now so you can rack up those stack overflow points later.

--

--