Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
Start a free Basic trial
to watch this video
Components and Modules for Front End Sanity at Scale
35:22 with Andrew BettsWe seem to keep learning the same lesson about monolithic things being bad, and modular things being good. It’s time to learn that lesson for web UI. With web components on the horizon, at the FT we set out to completely redesign our strategy for developing websites. Totally modular, with the strength of package management, strict versioning and standard build processes at its core, we’re building with ultimate flexibility in mind. We can no longer afford to build complex pieces of UI for only one website, as the number of web products also increases (we have 600 domains) we need to spend less time on each one and yet increase performance and improve user experience across the board. Our answer is a standard called Origami, which we’re working on in public. Come and hear about it!
-
0:00
[MUSIC]
-
0:05
[SOUND] Okay.
-
0:11
Is this gonna work?
-
0:15
Great.
-
0:16
[SOUND] Hi, so my name is Andrew Betts this
-
0:18
talk is about the FT's journey to web components.
-
0:21
It turns that basing your whole architecture on
-
0:24
components means changing not just a lot of
-
0:26
your development practice, but also the way that
-
0:29
we do design and product development as well.
-
0:33
I realized actually there's a chance that this talk will make me look like the
-
0:38
kind of guy who kind of hangs out in parks shouting crazily at birds.
-
0:46
And that always reminds me of this guy.
-
0:49
so, I'm hoping not to come across like Bill O'Reilly on Fox News.
-
0:54
But I have to admit I am the guy who made a
-
0:56
comment to our internal development standards
-
0:59
that banned our developers from using jQuery.
-
1:01
[LAUGH] So, I'm gonna look in more
-
1:07
detail later on about why jQuery and other general purpose toolkits and frameworks.
-
1:12
Because it's not about jQuery specifically.
-
1:15
May not make sense necessarily in a component-sized world.
-
1:20
And I also had a lot of chocolate at lunchtime.
-
1:22
And I'm feeling really sugar high right now.
-
1:23
[NOISE] So excuse all the shaking.
-
1:26
So let's start at the beginning.
-
1:30
Where do we start today, and why are components the way forward?
-
1:33
Each web project we do at the FT, is
-
1:36
becoming more complex, more complicated than the last one.
-
1:39
Our brand is increasingly digital.
-
1:42
And people are interacting with us on a
-
1:45
broader range of devices and browsers than ever before.
-
1:50
So that means that the cost of achieving a good user experience for
-
1:54
every user is increasing and the cost of testing is increasing all the time.
-
1:58
And this is a big problem.
-
2:01
It's a problem we need to solve because for 124 years we were a
-
2:06
newspaper, and for the last ten years of that we've had a website as well.
-
2:13
But for the last two years, we're a website that also prints a newspaper.
-
2:18
So that really is completely changing the way we look at digital.
-
2:24
So if you look at what we have today, you could quite easily just say well
-
2:27
you don't have a responsive site the Guardian
-
2:29
has a responsive site you should do that.
-
2:32
And many media companies already have responsive websites the BBC does
-
2:35
as well the Boston Globe well said on a very good job.
-
2:37
And the Guardian is a great example of responsive done
-
2:39
really well, but being responsive is not our biggest challenge.
-
2:45
There are far more important things to establish
-
2:48
what we think of a healthy web development ecosystem.
-
2:51
Something that we can use as the foundation
-
2:53
to build not just one responsive product, but hundreds.
-
2:58
So, what we have today is a collection of bits.
-
3:03
You know, you have some advertising, some
-
3:07
navigation membership bits, content bits, various sharing tools.
-
3:13
And all of these things come together on a
-
3:15
page in a way that is not very well coordinated.
-
3:19
A lot of them are built by different people, working
-
3:20
in different teams, that don't really talk to one another.
-
3:22
They're not really, even very well encapsulated.
-
3:25
They can be coded very defensively to prevent
-
3:28
interference from other things that might be on
-
3:30
the page, even though all those things are also built by people at the same company.
-
3:35
You get things, the resistance integration,
-
3:38
and also, too limited in scope.
-
3:41
So, the range of of stuff that you can do with them, the amount of
-
3:44
value you can get from all that work you put in is actually fairly limited.
-
3:48
Now this is exemplified by some of the, the kind of work
-
3:53
that we've had to do to create the same product more than once.
-
3:57
so, on the right here, you've
-
3:58
got marketslifeseat.com, which is a Desktop website
-
4:01
and on the left you have Markets Data in the FT web app.
-
4:05
So that seems a bit mad obviously there are companies that build the
-
4:09
same products in iOS and Android and Blackberry and Windows and on the Web.
-
4:14
We've built it twice using the same technologies
-
4:17
in both cases which seems a little strange.
-
4:20
Bt when you look at the FT web app and the way that was
-
4:22
built and the way it was designed,
-
4:25
it's resistant to integrating with other things easily.
-
4:29
So,
-
4:32
we see responsive as a feature.
-
4:34
But anyone can do that.
-
4:35
It's about how you approach building things
-
4:37
with Web technologies that we're trying to change.
-
4:40
There's a senior product executive at the FT who said to
-
4:42
me recently, you guys have been talking about components for years.
-
4:46
I remember people talking to me about components in 2005.
-
4:48
What's so special about components now?
-
4:51
And I think she's right.
-
4:54
Components are evolving and have been evolving for quiet sometime.
-
4:58
We've now reached a point where we can do really powerful things with them.
-
5:02
If you look back at the history of components,
-
5:05
you can trace it back to things like identity guidelines.
-
5:09
Big chunky documents like this one from Apple
-
5:11
which appears only appropriate for Apple certified individuals.
-
5:17
Which is a very big, thick flat document that just tells you what things
-
5:21
should look like, and doesn't give you any indication of how that should happen.
-
5:26
So, you can evolve from here to something like a living style
-
5:30
guide, which not just, doesn't just tell you what something should look like.
-
5:33
It gives you a reference implementation of how to do it.
-
5:36
So you then have the the origins of a standard component sized UI.
-
5:42
Because you have a piece of UI and you have lots
-
5:44
of websites to implement that UI in exactly the same way.
-
5:48
This actually is a really good living style guide
-
5:50
for Code for America made by Clearleft in Brighton.
-
5:55
So, this is a great start but what you don't realize
-
5:59
you need is a way of putting logic around those components.
-
6:04
A way of instantiating them, tearing them down, templating them.
-
6:08
Rendering them into the dorm and all of those things need
-
6:11
to be done in the same way for all those components.
-
6:14
And you really want a way of encapsulating those things, so
-
6:16
they can't interfere with other components that might be on the page.
-
6:19
So that's where you evolve again, and produce things like component frameworks.
-
6:25
Facebook produced a component framework very
-
6:27
popular one at the moment called Reacts.
-
6:29
We actually made something very similar called Fruit Machine, and our
-
6:34
Fruit Machine and Facebook's React actually came out roughly the same time.
-
6:37
And when you take a fairly simple example and you produce it using
-
6:43
Fruit Machine and using React, it's
-
6:44
astonishingly similar what you end up with.
-
6:47
So, that's a really positive indication for us.
-
6:50
It tells us well, Facebook and the F2 are very different companies.
-
6:53
But we had a very similar technology problem,
-
6:56
and we solved it in almost an identical way.
-
6:59
And that tells me well, we probably have our eyes on the same goal.
-
7:02
And that is the next step in the evolution
-
7:05
of components, which is to take it to web clients.
-
7:08
When we reach the point where we can use Web components.
-
7:12
We no longer have to opinionated about how we
-
7:14
wrap those components and put them in the browser.
-
7:17
So, you no longer have to be running React or running Fruit Machine.
-
7:20
You'll just make use of the components in the browser.
-
7:23
And components is something I've become completely
-
7:26
obsessed about because I think with the
-
7:28
number of websites that we have, the number of things that we're trying to do.
-
7:32
You can't always think about the tiny details every time
-
7:36
and you want to build something really good every time.
-
7:40
So, to try and build something really good
-
7:42
really quickly, you need to build with bigger bricks.
-
7:45
And so the analogy I always make to people internally is well, I want
-
7:48
to build a house, but I don't want to build a house using bricks.
-
7:50
I want to build a house using rooms because they I can put
-
7:53
a house together in a day and that's a really powerful thing to do.
-
7:58
So our objectives are these sort of things.
-
8:01
We want components standards more collaboration better
-
8:04
encapsulation and everything needs to be composable.
-
8:08
We wanted to go a little bit further than this.
-
8:10
Because we, we identified things that we
-
8:13
didn't think other people were doing so well.
-
8:14
And we wanted to try and come up with a solution that would take us there too.
-
8:18
So first of all, I asked a
-
8:20
domain administrator, how many websites do we have?
-
8:23
I thought, I'll go through them all, I'll
-
8:25
figure out what the commonalities are between them.
-
8:28
So it turns out we have 600 domain names.
-
8:32
And I took one of those ft.com and it turns out we have 800 sub-domains of that.
-
8:38
So I didn't look at how many sub-domains we have at the other 599 domains.
-
8:43
I didn't order all those work sites.
-
8:46
But, a lot of people still use them, you know,
-
8:49
millions of readers actually find a lot of these websites.
-
8:53
Very useful and they read them everyday, and we don't want to have to
-
8:56
rebuild them all, we don't have time, we don't have money to rebuild them all.
-
9:01
So, when we build components, we really need to
-
9:03
get value from those components on these existing websites.
-
9:06
And there are two big problems with this.
-
9:09
First of all these sites don't have bill, a bill process.
-
9:12
There's build process that I can insert dependencies
-
9:15
into, and build them into a front-end build.
-
9:18
In fact, a lot of these sites were
-
9:19
built before the idea of a front-end build existed.
-
9:24
And secondly, there's no foundation.
-
9:25
There's no common library or framework for running components on
-
9:30
the page, or if there is one, it's, it's obsolete.
-
9:33
So we need to be able to work around those
-
9:35
things without having to make major changes to existing sites.
-
9:39
Second thing is, I don't like monoliths.
-
9:42
I don't things that become a dependency of every single other thing that you build.
-
9:47
Because when you do that, at some point you will hate that thing.
-
9:50
And, you'll want to get rid of it.
-
9:51
And it will be a liability.
-
9:52
But the more things depend on it.
-
9:54
The more difficult it would to get rid of.
-
9:56
So the easiest thing to, the easiest way to avoid having to get rid of
-
10:01
something that's really difficult to remove is
-
10:03
not to build it in the first place.
-
10:06
The third thing is, we want to raise the bar.
-
10:08
This is a beautiful graphic that Google came up with years ago to
-
10:12
show the progression of web technologies and
-
10:14
basically it's all happening at this end.
-
10:17
These browsers on the other hand, continue to exist.
-
10:19
And I think there's a sort of
-
10:22
unasked question always, in, in progressive enhancement.
-
10:26
Which is where are you progressively enhancing from?
-
10:29
You know, the idea being that you, you serve a good basic experience that
-
10:33
works everywhere and then you enhance as
-
10:34
new technologies are detected in the browser.
-
10:37
But you're bound to have, have set a cutoff like we don't
-
10:40
care about browsers older than this because, you know, no one's using those.
-
10:44
And actually there is a native, there is
-
10:47
native support for doing that in the browser.
-
10:49
The problem is it was fixed to a
-
10:51
particular cutoff point which is the existence of JavaScript.
-
10:56
So the no script tag offered us an ability to
-
10:58
serve alternative content to browsers that didn't meet a quality threshold.
-
11:02
The problem is we couldn't move that quality threshold.
-
11:05
So, and that quality threshold is now in a position that's completely useless to us.
-
11:09
So I'd really like to have that kind of no script
-
11:12
capability but to be able to put it wherever I want.
-
11:15
So that we can decide what browsers meet
-
11:18
our quality bar and what don't, and which don't.
-
11:21
And finally, we want to make something that is so easy, that we
-
11:25
can hand it to an agency to build a website for the FT.
-
11:29
They've never worked with us before, and then they
-
11:32
can use it within an hour without talking to us.
-
11:36
Which is quite an ambitious target for ease of use.
-
11:40
So we took all these things and we made something that we call Origami.
-
11:46
So Origami isn't a framework because that would be to create something monolithic.
-
11:50
So it's a specification.
-
11:52
It's a document that describes the best practices that we've agreed to to share.
-
11:58
And, it's a suite of tools, that help us to stick to those best practices.
-
12:04
And, it's a whole load of components that
-
12:05
we've built using that, that, those best practice guides.
-
12:09
So, I'm going to dive into the spec, first of all, and talk
-
12:12
about a few of the the, the highlights from the decisions that we've taken.
-
12:16
And then give you a demo of some of the tools that we've built.
-
12:20
So first of all we have rules to deal with the weight of ease language and syntax.
-
12:27
So in JavaScript for example, we have
-
12:28
rules around Not using globals, not modifying the
-
12:32
DOM on parse and outside of areas that you expect that model to be responsible for.
-
12:38
So if I use a component that's built by a colleague and I
-
12:41
haven't spoke to them about, you know, to make sure they did it well.
-
12:46
I can be confident, that putting that code into my bundle, won't slow down my pace
-
12:51
load and the it won't interfere with anything on, on the page unexpectedly.
-
12:59
We also name space for our events so that we can be
-
13:03
sure that two developers building components
-
13:05
won't name their events the same thing.
-
13:07
And of course we have standards for things
-
13:09
like static code and analysis tools like jsHint.
-
13:12
CSS is actually a little more interesting.
-
13:15
Because CSS doesn't really have scope in the same way
-
13:17
that JavaScript does, we have to do a lot more namespacing.
-
13:21
So we care about adding namespace prefixes who are like classes.
-
13:25
And we have rules about not styling out of namespace.
-
13:29
So, for example, if you have a
-
13:31
gallery component that requires a basic box component.
-
13:34
The gallery is not allowed to re-style the box.
-
13:37
It can take the boxes styles, mix them into its own classes, and re-style those.
-
13:43
But it is not allowed to, to re-define the definition of box.
-
13:48
Because the box might be used by another component.
-
13:52
Specificity is another thing that we need to be very careful about.
-
13:55
And if you look at some of the legacy products that we have to support you find
-
13:59
you know the usual problems with specificity wars, where
-
14:02
things are fixed simply by making them more specific.
-
14:06
So, in starting this project we try to set up
-
14:10
rules that will try to ensure that that doesn't happen.
-
14:13
So using them, lock in a modifier syntax to
-
14:18
reduce our CSS selectors to one single token where possible.
-
14:23
And where we're using raw HTML tag selectors, we'll generally use them with
-
14:29
a descender operator to make sure that we don't target more than we intend to.
-
14:35
We have a list of states that we we consider when we are designing.
-
14:39
So this has been really helpful for
-
14:41
collaboration between the developers and the design team.
-
14:44
Because we now have agreed exactly what we mean by active, and
-
14:47
selected and focused and busy and disabled and invalid and so on.
-
14:53
And these are the interaction states that we care about.
-
14:57
And when we, when we implement those interaction states,
-
15:00
we use the correct ARIA roles to describe them.
-
15:04
And finally another thing I thought I'd
-
15:06
mention about CSS is how to do responsiveness.
-
15:09
Because components and component authors can't tell.
-
15:13
Where that component is gonna be used in the page.
-
15:15
There's no point in, in putting media queries into a component.
-
15:19
Because I could have a component that might be
-
15:23
on the, the, the full width of the page.
-
15:25
But equally, the developer of the page that's using my component might put
-
15:28
it in a box that only occupies a small part of the page.
-
15:32
So the media query if it's inside the component isn't necessarily gonna work.
-
15:37
So instead, components export mix ins that allow you to restyle the
-
15:42
component in a number of different visual styles that are generally different sizes.
-
15:47
And then, the developer of the product that is
-
15:50
embedding the component can write their own media queries.
-
15:53
And can select the different visual styles of
-
15:56
all the components on the page that they want.
-
15:59
And that's a little bit of work for the product developer,
-
16:01
but it means they get same breakpoints that exist at consistent
-
16:05
locations, and that they can control exactly what the behavior of
-
16:09
the components on the page is when they hit those breakpoints.
-
16:13
We also have a standard build pattern.
-
16:16
And this is really important because it means that we can consume,
-
16:19
large dependency trees of components and build them all in one build step.
-
16:24
It means that we don't, ever have, repeated
-
16:27
code within our, our built JavaScript little CSS bundles.
-
16:32
Everything is, is guaranteed to only be included once.
-
16:34
And this pattern consists on the JavaScript side
-
16:38
of using common JS for our module format.
-
16:42
Browserify to convert those modules for use in the
-
16:45
browser and Closure Compiler too produce minified concatenated bundles.
-
16:50
And on the CSS side we use SASS which does all of the above, and we're using Bower to
-
16:56
require all of those modules into a a flat
-
17:02
components directory which we can easily deal with to produce those bundles.
-
17:09
And the final point on the spec that I want
-
17:11
to talk about is the cut, the cuts the mustard technique.
-
17:14
This is a term that the BBC responsive news team came up with to describe the
-
17:19
idea of running a very simple test in
-
17:22
JavaScript to determine how good the browser is.
-
17:25
And this is where we bring in this new quality threshold.
-
17:28
Rather than just does this browser support JavaScript?
-
17:31
We now care about whether the browser supports enough
-
17:34
JavaScript to make sense for us to run it.
-
17:38
So if it doesn't we actually run no JavaScript at all.
-
17:41
And that leaves us with a website that we describe as core experience.
-
17:46
Something which works.
-
17:48
It provides basic you know, pipe link based navigations through everything.
-
17:53
And its a great fall back for all the browsers, for search engine crawlers
-
18:01
for users who use JavaScript doesn't work for some reason.
-
18:05
Maybe they've had a firewall or
-
18:09
Misbehaving network operator interfere with it.
-
18:13
So, there's a lot of cases that are covered
-
18:15
by having a decent core experience that works without JavaScript.
-
18:18
And then, for those browsers that do pass
-
18:20
our test, we can progressively enhance within what
-
18:23
we call the primary experience to provide different
-
18:26
levels of experience for, for different qualities of browser.
-
18:29
But fundamentally we acknowledge that we are progressively
-
18:32
enhancing from a point, and that we can
-
18:34
move that point as browsers become less popular,
-
18:38
and we can drop them in to core experience.
-
18:41
So an example of how cutting the mustard works,
-
18:45
is oh, okay, this doesn't navigate with onJSDown, sorry.
-
18:50
[INAUDIBLE] Okay, so an example of how cuts TheMustard works is simp, as simple
-
18:55
as this, you literally write something incredibly
-
18:58
simple that will return a true or false.
-
19:01
And you want it to be incredibly simple because you want it
-
19:04
to not crash or become a problem in very, very old user agents.
-
19:11
This is something that you want to work absolutely everywhere.
-
19:16
So, those are the harlots of the spec.
-
19:19
There's a ton more content to it, and
-
19:21
you're very welcome to read the whole thing.
-
19:23
It's origami.ft.com.
-
19:26
So I thought I would also show you some of the tools
-
19:28
that we've made to help us implement components that are spec compliant.
-
19:33
And this is that these tools are really critical to the whole thing.
-
19:37
Because if you produce a big document of rules and
-
19:39
you say, you know, thou shalt stick to these rules.
-
19:42
That actually is quite difficult to enforce.
-
19:45
So, the easiest thing to do is to make some tools
-
19:47
that make it easiest to do that than to do anything else.
-
19:50
Because if you make it easier for someone to do what you want them to
-
19:52
do, what you don't want then I like you to do what you want anyway.
-
19:57
So the first tool is the registry, this is a,
-
19:59
a website that lists all components that we have it is.
-
20:04
A self-discovery mechanism so you don't have
-
20:06
to register your component with the registry.
-
20:08
It will go and scan all of our GIT
-
20:10
locations and it will find things that look like components.
-
20:14
And then when it finds them it will test them, and
-
20:16
if they are valid components it will list them in the directory.
-
20:19
Which provides a huge incentive for component developers
-
20:22
to stick to the letter of the spec.
-
20:24
Because if they don't there's a good chance the registry
-
20:26
will kick out your component and say this is not valid.
-
20:31
The best way actually of showing the registry is just to, to demo it.
-
20:35
It is a public website so you can look at this as well.
-
20:39
[BLANK_AUDIO]
-
20:44
Hopefully the WiFi will work.
-
20:47
Okay, so this is the Origami registry.
-
20:49
You can see we've got a fair number of components in here already.
-
20:53
And I can show you some examples that we've made.
-
20:57
So let's have a look at gallery for examples.
-
21:01
okay.
-
21:02
That didn't work.
-
21:05
Maybe it hasn't loaded yet.
-
21:06
[BLANK_AUDIO]
-
21:08
Should chose a simpler one really.
-
21:11
These will also expand when they finish loading to exactly
-
21:14
the right size but, let's load it in a new tab.
-
21:18
Okay ,so we have a gallery component fairly straight
-
21:21
forward most media companies will have a gallery component.
-
21:23
In fact they'll be lucky if they have less then five.
-
21:28
And we've got a nice time line down here and it's also touch friendly, as well.
-
21:34
So, this is a great example of where, if you hadn't built as
-
21:38
a component, and you needed slide show functionality as part of a product.
-
21:41
You probably wouldn't have bothered to put the touch support in, if tablets and
-
21:46
phones weren't your, your sort of key
-
21:48
audience for that, for that particular product.
-
21:50
So, by using a component where we thought about all of
-
21:53
these best practices, and encapsulated them all in something that's reusable.
-
21:57
We can provide a great experience a great gallery experience everywhere.
-
22:02
This is of course seeing you believe galleries
-
22:05
are a good idea in the first place.
-
22:07
So slow [SOUND] let me show you a slightly simpler component.
-
22:14
[SOUND] Let's have a look at buttons.
-
22:19
So as well as giving us rich UI components that we would use for very specific
-
22:25
purposes, but we also have much lower level
-
22:28
components and even more lower level than this.
-
22:32
But this is an example of a component
-
22:34
which gives us our, our standard FT-buttons styles.
-
22:38
So let's say I wanted to generate the CSS and markup that, that does this right now.
-
22:46
I would need to go find the buttons component, check it out.
-
22:52
Well, I'd have, first I have to install NPN
-
22:55
in Bower, and then I have to Bower install.
-
22:57
The buttons component, then that would go and
-
23:01
fetch all the dependencies of the buttons component.
-
23:03
Then I'd have to run a browser file.
-
23:06
I'd probably have to set up the Grunts or Gulp
-
23:07
first to make sure I can do all of those steps.
-
23:10
And then that would produce me a bundle, which I would then
-
23:12
have to cash and serve through a web server of some kind.
-
23:15
And that sounds like a lot of work!
-
23:19
alternatively, we could use our other tool that we've word got at [INAUDIBLE].
-
23:23
So, I'm gonna take this code which is the mark up
-
23:26
that produces these buttons and pop it into a JS bin.
-
23:29
If I can make JS bin work.
-
23:36
Huh, that's interesting, don't know what that's there.
-
23:39
Probably not the worst things that could have come up in JS bin.
-
23:41
[LAUGH]
-
23:43
>> okay, so, by default, this is gonna give me some standard browser buttons.
-
23:48
So this is not very exciting so far.
-
23:51
But if I go down a little bit further on this page, the next
-
23:55
section I see is a quick start section, and it gives me a link tag.
-
23:58
And let's copy the link tag.
-
24:00
[BLANK_AUDIO]
-
24:07
And we get our solid buttons, magic.
-
24:09
So, what happened there?
-
24:12
Let's go out to the notation and I'll talk about it.
-
24:14
[BLANK_AUDIO]
-
24:18
So, what you just saw was something called the Build Service.
-
24:21
And it is a node application that will take on
-
24:25
the query strain, a list of modules that you would like.
-
24:29
And it will go away and do all of that, all of that process that I just described.
-
24:34
It will use bower to install the module,
-
24:35
it will install all the dependencies, it will run
-
24:38
it through browser fight, it will do all of
-
24:39
the best practices that we've put into the spec.
-
24:42
And then it will serve it either on HTTP or ACPS
-
24:45
as you like and it will push it through a CDN.
-
24:50
So everything that you could want from something
-
24:54
that would build your front end dependencies for you.
-
24:57
And another great thing about this is you can
-
24:59
specify the version of the module that you want.
-
25:03
So in this case I'm saying I want version
-
25:05
one three seven of Header, but I prefixed the version
-
25:09
version number with a carrot which means that I'm
-
25:11
prepared to accept any version up to 3.9 including two.
-
25:16
So you can be very flexible about exactly how risk averse you are.
-
25:22
If you're building a product that's, let's say a stand alone
-
25:25
interactive graphic site and you want to freeze it in time.
-
25:29
And, you want to make sure that it never changes, never breaks.
-
25:32
You can specify the exact version.
-
25:34
And, even when later versions of this component are released, the build Service
-
25:38
will always be able to build
-
25:39
that particular version or that particular module.
-
25:42
Alternatively, you can leave the suffix completely blank.
-
25:47
Like, I've done in our Tweet.
-
25:49
And that's saying well, I don't care.
-
25:51
I'll take major version updates, that's fine.
-
25:54
So that's fairly risky.
-
25:55
It could be break the API completely but you,
-
25:58
it might be something you wanna do safe analytics.
-
26:00
Where you're are intending to interact with the modules API at all.
-
26:04
You're just gonna let it do it's thing.
-
26:06
So in that case maybe a major version update is gonna be fine.
-
26:09
So you can choose and it, it gets
-
26:11
you started with new projects very, very easily.
-
26:14
This instantly is also a great way
-
26:16
to retrofit components to existing websites that don't
-
26:19
have a build process because you can very quickly just slot in a, a built code.
-
26:24
I'm gonna use the last section.
-
26:29
Of my talk to talk about some of
-
26:30
the tricks we've developed as part of this project.
-
26:34
So we actually found, we have to resolve some problems that we already thought
-
26:39
we had solutions for, because in a
-
26:41
component world those solutions no longer make sense.
-
26:44
And the first example of this is Polyfills.
-
26:47
We go.
-
26:48
Back to full screen cuz I moved [UNKNOWN] okay.
-
26:55
So components are developed independently.
-
26:57
We can't make assumptions about what else might be
-
26:59
on the page that that component will ultimately be on.
-
27:02
So if the component requires a Polyfill.
-
27:04
Let's say the J sub t polyfill or the query select polyfill.
-
27:09
Should it shit with that polyfill?
-
27:11
Well if it does that than presumably other components might
-
27:14
also include the same one, and then we've got co duplication.
-
27:17
Or we could create a module that contains
-
27:19
that polyfill and express a dependency on it.
-
27:22
But if we do that, than we won't get the
-
27:25
co duplication, but we will get the polyfill come or may.
-
27:28
And actually, we'd really rather only serve
-
27:30
that polyfill to browsers that need it.
-
27:32
Don't really want to serve it to browsers that already have that feature.
-
27:35
So we decided to create a metadata file for each component.
-
27:40
And one of the things in that mass
-
27:41
data file is a list of required browser features.
-
27:44
So, this particular component is saying, I need post message and local storage.
-
27:47
Otherwise, I won't work.
-
27:49
I'll just break.
-
27:51
So it's then up to the website, that
-
27:53
integrates, that integrates that component to provide those features.
-
27:57
Either by not running the JavaScript in
-
27:59
browsers that don't have them, or polyfilling.
-
28:03
We express those requirements instantly as Modernizr test names so they're
-
28:07
not just random strings, they actually link to something that mean something.
-
28:11
And that means also that we can use
-
28:12
Modernizr when we write our cuts the Mustard test.
-
28:16
So here's an example of a cuts the Mustard Test that includes polyfill fallback.
-
28:20
So first when we run our basic cuts the Mustard
-
28:23
expression and we conclude that this browser, yes, is good enough.
-
28:27
So then we can test for other things that the browser
-
28:30
may not have despite having passed the cuts the Mustard Test.
-
28:33
And if those things fail, we can load some
-
28:35
polyfills before we then load the main application JavaScript.
-
28:41
I did say that I, I thought that there might be a few things in here that seemed
-
28:45
a bit crazy, one of the other ways that
-
28:47
you can do this is with service-side feature detection.
-
28:51
That's a very neat, I think a service called polyfill.io.
-
28:55
Which will, which has a very big index of user
-
28:58
agent strings, and it will deliver to you exactly the
-
29:01
polyfills that are required in that browser, which is quite
-
29:05
neat and it means that your front-end code is very small.
-
29:10
So, yeah, you could do that.
-
29:15
So, that's polyfill fallback.
-
29:18
Like, you know, we, we don't have a feature so
-
29:19
one of the things we could do is polyfill it.
-
29:22
Another thing you could do is fallback.
-
29:25
And that's split into two.
-
29:27
You could feature gate something so if, if you can't do it
-
29:30
then just make it appear that that feature doesn't exist at all.
-
29:34
Or you can do feature alternation i.e.
-
29:37
you can't do something, so you do something else instead.
-
29:41
So, the last approach is what you want to use a lot of the time.
-
29:44
So, for example, if you have an article with comments at the end, it might
-
29:49
be that we don't want to be able to accept new comments in core experience.
-
29:53
Because it's a fairly complicated piece of functionality.
-
29:56
We don't really want to support that for all the browsers.
-
29:59
So how do we display something else to browsers that don't cut the mustard?
-
30:06
You can't use NOSCRIPT because it's hard coded to
-
30:09
a different quality threshold to the one we want.
-
30:12
So instead we use a div with a class and we will
-
30:15
add or remove a JS class on our document element the HTML tag.
-
30:19
To hide or show you that content.
-
30:22
This actually a pretty reliable method that
-
30:25
works even in very, very old browsers.
-
30:32
What am I going to do next?
-
30:33
Oh, yes, so another thing we see sort of related to this is feature flagging.
-
30:38
So we want to.
-
30:40
Be able to turn various on or off depending on conditions in the browser.
-
30:44
One of those things is hover state.
-
30:47
Hover state only makes sense if you have a hoverable pointer.
-
30:50
Actually it was one of Paul Lewis' HTML5 rocks articles that put that sort of, got
-
30:57
me thinking about this and that was to
-
30:59
do with disabling hover effects while scrolling for performance.
-
31:03
But actually we're sort of slightly more interested in using it
-
31:07
to disable hover effects on devices that don't have a hoverable pointer.
-
31:12
Because if you don't have a hoverable pointer then you can actually
-
31:16
activate the hover effects by touch and you generally don't want that.
-
31:20
So, iOS, for example, has emulated touch.
-
31:23
Sorry, yeah, emulated hover, sorry.
-
31:26
Which exists because some websites require you
-
31:29
to hover in order to use the navigation.
-
31:32
You can't actually navigate the website unless you can hover over a menu.
-
31:35
Now we don't have any menus that are like that.
-
31:37
So, it makes sense that we disable hover on touch screens.
-
31:43
Or at least we disable hover on touch screens
-
31:45
that don't have a mouse, and there's massive crossover and
-
31:50
confusion here because f course there are lots of devices
-
31:54
that have both mouse and track pad and touch screen.
-
31:58
Or they don't have a mouse but maybe you
-
31:59
plug one in while you've got the page open.
-
32:02
All these kinds of scenarios we need to take count of so that
-
32:04
we don't just annoy the user by assuming something that's not actually true.
-
32:11
So, yes this requires detecting touch or,
-
32:14
more accurately, it requires detecting a mouse.
-
32:18
But we find that provided that you do that in
-
32:20
a sensible way, it can actually be a great user experience.
-
32:26
And finally how do we do asset loading?
-
32:28
So this is one of those things where is
-
32:30
just a no brainer if you not using components.
-
32:33
Let's say you have a share widget and the share widget has a swisser logo on it.
-
32:38
So where are you going to get that Twitter logo from?
-
32:40
Well you'll load it from your web server obviously.
-
32:42
But if that share widget is a component
-
32:45
and, that Twitter logo exists in the component compository.
-
32:50
What URL will that image exist at when it comes to be loaded from your website.
-
32:55
And, that's something that might vary from
-
32:58
one website to another, that contains this component.
-
33:00
So, when we write the component, we don't actually
-
33:03
know where we're going to get that asset from.
-
33:07
So, we have an assets module that helps us to resolve these URLs.
-
33:11
First we pass in the the path within the repository.
-
33:15
And, the name of the repository we'd want to get the file from.
-
33:19
And, we just assume that there is the the return value from that is a value URL.
-
33:23
And, you use it like you would any other.
-
33:26
And then when the component is integrated into a site, we can set
-
33:29
various configuration that allow us to
-
33:30
control exactly what happens to those URLs.
-
33:33
So we can say for example, well I put all my components in
-
33:36
the results directory, and I put this particular one in the web sub directory.
-
33:40
And that will then allow the assets module to resolve what the full URL is.
-
33:45
And that means that as component developers we are not penated
-
33:48
about how you as a, a product developer craft your URLs.
-
33:54
You can create whatever URL scheme you
-
33:56
like, and the components are, are fine with
-
34:01
that.
-
34:02
So, in summary, I'm actually ahead of time, which is amazing.
-
34:07
We have some pretty cool stuff at the FT.
-
34:10
In fact, the web app won best news app in the Newspaper Awards
-
34:14
in the paper a few weeks ago, so we were very proud about that.
-
34:17
Some of it isn't very consistent and isn't very well integrated.
-
34:21
We see web components as very much the future of the way that we build
-
34:26
websites, and also part of the solution to the sort of problems that we have.
-
34:32
So we set out to build a spec and some tools to try and
-
34:35
fix those problems and to get us ready for web components when they arrive.
-
34:41
We have lots of interesting challenges, and
-
34:44
working in public has been really interesting,
-
34:46
because it's enabled us to get a lot of feedback from developers outside of EFT.
-
34:51
It's also meant, interestingly, that other media
-
34:55
companies that also have these same problems are
-
34:57
very much more willing to talk to us
-
34:59
and explain how they're solving the same thing.
-
35:02
So I think ultimately
-
35:10
that means
-
35:15
that we will end up with a, a much better product.
-
35:19
So that is all I have to say.
-
35:20
Thank you very much.
-
35:21
[SOUND]
You need to sign up for Treehouse in order to download course files.
Sign up