This content originally appeared on Modern Web Development with Chrome and was authored by Paul Kinlan
<p>There have been a lot of conversation about all the issues of the web over the
last couple of weeks and they broadly group themselves into the following
categories:</p>
<ul>
<li>Performance</li>
<li><a href="https://paul.kinlan.me/the-lumpy-web/">Lumpy</a> inconsistent browsers</li>
<li>Rapidly expanding feature landscape.</li>
</ul>
<p>I want to put these to the side for a couple of minutes to quickly talk about
one of terms that we have used in Google to quickly describe the positive
aspects of the web as a platform for users and developers: <strong>SLICE</strong>.</p>
<p>I can't find an original reference for it, but the underlying points that I will
go into are well known. <strong>SLICE</strong> was mentioned at the first <a href="https://developer.chrome.com/devsummit">Chrome Dev
Summit</a> by Linus Upson in the 2013
keynote. When Linus talked about the properties of the web it wasn't in the
correct order for naming but I do encourage you to watch this video. <em>Note</em>:
Brett Cannon, a Microsofter (formerly a Googler) also recently mentioned it and
it's a <a href="http://nothingbutsnark.svbtle.com/going-allin-on-the-mobile-web">good
read</a> and has
broadly similar conclusions to my post about <a href="https://paul.kinlan.me/living-with-web-apps/">Living with Web
Apps</a></p>
<div class="yt-embed" style="position:relative;padding-bottom: 56.25%; padding-top: 25px; height: 0;">
<iframe
data-src="//www.youtube-nocookie.com/embed/20fGtfnxJuo?autoplay=1"
style="position: absolute; left: 0; top: 0; width: 100%; height: 100%; border:0;"
allowfullscreen
title="YouTube Video"></iframe>
</div>
<br>
<p>I think it covers a lot of good points:</p>
<ul>
<li><strong>S</strong>ecure - All domains are sand-boxed from each other and sites are
sand-boxed away from the users machine. The user can go to any site and know
they are safe.</li>
<li><strong>L</strong>inkable - You can point to any page or piece of content just by sharing a
URL</li>
<li><strong>I</strong>ndexable - Because you can link to anything, if public it can be
discovered by any person or machine that can index it to make it universally
discoverable to everyone.</li>
<li><strong>C</strong>omposable - Iframes and JavaScript allow us to quickly compose and embed
new sites, apps and services just by dropping in some JS and hooking things
together.</li>
<li><strong>E</strong>phemeral - There is nothing to install, you go to the page and interact
with it, leave the page and when you do it stops taking up resources.</li>
</ul>
<p><strong>SLICE</strong>.</p>
<p>As a set of abilities that the web encapsulates SLICE principles are well known
yet frequently forgotten when considering the competition of native platforms.</p>
<p>As a term, I find that <strong>SLICE</strong> is a great way to quickly address benefits of
the web today. It misses out a couple of major benefits of the web such as the
ability to deploy updates instantly — <strong>SLUICE</strong> isn't a great acronym
— but that is ok, <strong>SLICE</strong> as an acronym works well.</p>
<p>I use the <strong>SLICE</strong> model as a baseline for where we are going with the <em>future
of the web</em> and the challenges we face and need to overcome to get there.</p>
<ul>
<li><strong>S</strong>ecure - The web should remain sand-boxed and it should be end-to-end encrypted.
We also need to work out what the model is for ensuring the user is in control and aware
of how permissions to advanced API's.. For example, we recently started to ship a
<a href="https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web?hl=en">Bluetooth API</a>
how do you give users the confidence that it is safe and secure to use.</li>
<li><strong>L</strong>inkable - I started this with Web Intents and although it ended early, I believe we are due
for another generation of linking content, sites, apps and native experiences. Some of it requires
new technology some of it requires education.
<ul>
<li>Linking in to Web Apps: I am going to dive in to this another time. TL;DR - product landing pages and log in pages
don't help us link to web apps.</li>
<li>Deep linking into media: browsers for a long time have been able to link to any part of a file
yet no one seems to do it.</li>
<li>Deeper linking in to text: The first time I saw this was Dave Winer's blog where you could link to
any paragraph, more recently Medium are giving every paragraph a deep link.</li>
<li>Linking Real world Objects: <a href="https://google.github.io/physical-web/">The physical web</a> for discovery of "things" around us,
and new API's for talking to these "things" will reduce the friction in our every day lives.</li>
</ul>
</li>
<li><strong>I</strong>ndexable - The headless web, i.e, parsers and indexers are getting more advanced allowing us to understand
more about the content that is on the web, they will run JS and understand visually how the page renders
but there are a lot of issues still:
<ul>
<li>Embedded Schema.org can't describe semantically correctly (hence JSON+LD)</li>
<li>Media does not have a huge amount of meta data exposed in a public format.</li>
<li>Apps: Web Intent's tried to be a way that described what a web app could do. We don't have that any more
and we are missing a massive way to describe the capabilities of what a web app can do. Take my
<a href="https://airhorner.com/">airhorn app</a> as an example, even though I expect no one to need horn
functionality in their app, there is no way to find it other than to search for meta-data and it is one
of the reasons why we have product landing pages on the web.</li>
<li>Internet Connected devices aren't being indexed and they don't describe what they can do. It's a missing
piece for my in the Physical Web story, discovering capabilities. I feel like we need a Web Intents for
IoT.</li>
</ul>
</li>
<li><strong>C</strong>omposable - It would be easy to mention just only mention Web Components, but really we are talking
about the broader ecosystem of reusable tools, libraries and frameworks:
<ul>
<li>There are massive issues of interop at the moment as frameworks try to own the entire stack.</li>
<li>We need to solve client-side delegated functionality. Web Intents tried this, but much of it is possible still
on the web today but we don't do it. i.e, I have created a QR code snapper web app, why do you need to build
one yourself to integrate it in to your own app, just use mine or any other pre-existing service.</li>
</ul>
</li>
<li><strong>E</strong>phemeral - Two words: Service Worker.
<ul>
<li>Installability is the antithesis of Emphemerality. By it's very definition, when you install something it
becomes a long running and integrated part of the device. Service Worker can give use the best of both worlds:
a middle ground letting you choose how and when the site should be integrated deeper into the device. Combine
this with the manifest and the user now has the choice of installing the "web app" or keeping it as an
as-needed interaction.</li>
</ul>
</li>
</ul>
<p><strong>So what are we missing?</strong> I am going to leave that for you to tell me, I suspect I am missing a lot. I do have a
set of follow up posts where I will talk about how native platforms are taking a
piece out of <strong>SLICE</strong> model for themselves as a way to entrench native apps further in to the
everyday lives of users and how the web can differentiate even further.</p>
<p>Image Credit: <a href="https://commons.wikimedia.org/wiki/File:The_Big_Slice_-_Rome,_Italy.jpg">Justus Hayes</a></p>
This content originally appeared on Modern Web Development with Chrome and was authored by Paul Kinlan
