Today's schedule – "Cutting the mustard"

View Github Repository Open presentation in a new window

triblondon

See all presentation from triblondon

Today's schedule – "Cutting the mustard"

2 4

talk-components-origami

On Github triblondon / talk-components-origami

Today's schedule

1500 Origami Overview Andrew 1540 UI components Alberto 1620 Web services Sam 1640 Hands-on workshops Andrew, Alberto, Sam, Kaelig

Origami workshop

A practical journey to Web Components

by Andrew Betts, FT Labs (trib.tv / @triblondon)

This talk is about the FT's journey to web components. It turns out that basing your whole architecture on components means changing not just a lot of your development practice, but also the way that we do design and product development too. I realised there's a chance that this talk will make me look like the kind of guy that shouts randomly at birds in the park.

Challenges

Building websites is harder today than ever before. Why?

Multiple formats

Anyway, let's start with where we stand today and figure out why components are the way forward. Each web project is becoming more complex, our brand is increasingly a digital one, and people are interacting with it on a greater range of devices, increasing our testing cost.

Multiple formats

Responsive.

Many media companies already have responsive websites, Guardian a great example. But being responsive is not our biggest challenge. There are far more important things to establish a healthy web development ecosystem.

Better usability

We are not here to do easy things for people who are like us Alice Bartlett

Problems at FT

Meeting the challenges of modern front end development can lead to problems

Problems

  • Repeating work
  • Unable to let go of old tech
  • Experts needed everywhere
  • Square pegs, round holes
  • Learning 'cliff'

Goals

What should we be aiming for?

Consistent brand experience

Not just about being responsive

(we have lots of websites to make responsive)

Many media companies already have responsive websites, Guardian a great example. But being responsive is not our biggest challenge. There are far more important things to establish a healthy web development ecosystem.

Living style guides

Living style guides provide reference implementations of UI designs so everyone is using the same code. Already moving in the right direction. (Code for America design by ClearLeft)

Objectives

Components

Standards

Collaboration

Encapsulation

But not frameworks

Works with the old stuff

We have 600 domains, 800 subdomains of ft.com. We have millions of readers who like those sites, so we should be able to apply the benefits of the new stuff to those older sites.

Don't build a monolith

A lot of things we looked at were big, centralised solutions. I've learned over the years that if you make a 'core' thing and make it a dependency of everything you do, it becomes a liability.

Raise the bar

Current bar: noscript. Progressive enhance, from where? Choose a new baseline a few years old. Rolling window of support for primary functionality.

Make it easy

Hate: frameworks, opinionated solutions, 'beautiful' things. Love: Tools to support standards. Make it push-button easy to use the standard stuff

Full set of principles available at origami.ft.com/docs/overview/principles

The Origami way

How does Origami meet these goals?

Origami is...

  • A Specification (origami.ft.com)
  • Tools
    • Registry
    • Build service
  • Components!
    • Modules (installable packages)
    • Web services (APIs)

The spec

Agree a standard for building modules and services

Module build pattern

Bower because does not require package to be aware of it, does not require registry (and still supports semver) and dedupes deps by default. CommonJS+browserify because we have a preference for bundles over incremental loading, atomic runtime code, works offline. SASS simply due to overwhelming popularity.

"Cutting the mustard"

A simple logical test that sets a movable bar for running application JavaScript

Set a CTM test for each product, above is primary, below is core.
if ('querySelector' in document && 'localStorage' in window && 'addEventListener' in window) { ... }

Syntax and encapsulation (JS)

  • No globals
  • No modifying DOM on parse (or outside of owned DOM)
  • Namespace events
  • jsHint

Syntax and encapsulation (CSS)

  • Namespace prefixes for classes
    • No styling out of namespace
  • No IDs, ever
  • Minimise specificity. Use BEM or descendent selectors
    • o-tweet__avatar--verified
    • o-tweet > p
  • Consider states (use ARIA):
    • hover, focus, busy, selected, disabled, active, invalid, pressed, expanded
  • Express responsive behaviours by exposing mixins, not using media queries:
    • o-tweet--large, o-tweet--small

The tools

Make it easy to comply with the spec requirements

Build tool

> origami-build-tools install

Build modules in your own product

Serve them locally

Compile as part of your own JavaScript and CSS bundles

Auto-install all dependencies, tools, linters etc.

Registry

Scan known git servers

Index version tags

Build every version of every module

Collect all the info on one page

Act as a directory of web services

Origami registry is public on the web so anyone can collaborate with us

Move into demo - colors, header, tweet, responsive image service

Build service

http://build.origami.ft.com/bundles/js?modules=o-tweet,o-ft-header@^1.3.7,o-hoverable@2

Build any combination of modules on demand

Build, bundle, compress, optimise, serve through CDN (gzipped)

Lock to a version or automatically upgrade with semver-compliant versioning

Allow developers to work without a build step

Build process walkthrough

Build a page using Origami components

That's it!

Contact me:

For jobs in London, visit labs.ft.com/jobs