Cupertino in China Syndrome meltdown

China selfie revolution

Responding to concern that its Safari browser’s defense against malicious websites may reveal the IP addresses of some users’ devices to China-based Tencent, Apple insists that Safari doesn’t reveal a different bit of information, the webpages Safari users visit.

Apple may deny users in China VPN protection, it may deny Hong Kong democracy protesters an app used to avoid police, and it may remove references to Taiwan in localized versions of iOS 13 for the Chinese-controlled Hong Kong and Macau.

But it’s not giving up website visits – readily available to authorities by monitoring ISPs, DNS, and reportedly by backdooring Android apps [PDF] like the Communist Party of China’s “Study the Great Nation” – through browser telemetry.

Since February at least and perhaps longer, Safari’s Safe Browsing framework has been receiving hash prefixes of known malware sites from Google Safe Browsing database, or for users in mainland China, Tencent’s Safe Browsing database.

A 32-bit hash prefix like “ba7816bf” would represent the first eight characters of a 256-bit, 64-character SHA256 digest of a full URL.

Before it loads a requested website, Safari, like other browsers that implement a safe browsing lookup system, will hash the URL of the website to be visited and compare its hash prefix to the received hash segments of malicious sites.

In the event of a match – and there may be several given that hash prefixes aren’t necessarily unique, Safari asks the API provider – Google or Tencent – for all the URLs that match the hash prefix.

Using that fetched list, Safari can then determine whether the intended destination matches anything on the list of malicious websites and present a warning if necessary. And it will do so unless the on-by-default “Fraudulent Website Warning” is disabled using the appropriate iOS or macOS settings menu.

Nothing to see here

And this, Apple contends, is nothing to worry about. In a statement emailed to The Register (!), an Apple spokesperson said:

“Apple protects user privacy and safeguards your data with Safari Fraudulent Website Warning, a security feature that flags websites known to be malicious in nature,” it commented.

“When the feature is enabled, Safari checks the website URL against lists of known websites and displays a warning if the URL the user is visiting is suspected of fraudulent conduct like phishing. To accomplish this task, Safari receives a list of websites known to be malicious from Google, and for devices with their region code set to mainland China, it receives a list from Tencent.”

Tim Cook, photo2 by JStone via Shutterstock

In a touching show of solidarity with the NBA and Blizzard, Apple completely caves to China on HK protest app


“The actual URL of a website you visit is never shared with a safe browsing provider and the feature can be turned off.”

That said, there’s still the issue of user IP addresses, which Tencent would see for those using devices with mainland China settings. That’s a privacy concern, but its one among many given that other Chinese internet companies – ISPs, app providers, cloud service providers, and the like – can be assumed to collect that information and provide it to the Chinese surveillance state on demand.

In a blog post on Sunday, Matthew Green, associate professor of computer science at the Johns Hopkins Information Security Institute, pointed out some potential privacy problems in safe browsing APIs like Google’s.

The privacy community, he said, has mostly come to terms with the privacy trade-off that comes with Google’s Safe Browsing API, figuring the security gains are worth the risk.

“But Tencent isn’t Google,” he said. “While they may be just as trustworthy, we deserve to be informed about this kind of change and to make choices about it. At very least, users should learn about these changes before Apple pushes the feature into production, and thus asks millions of their customers to trust them.” ®

How to Process, Wrangle, Analyze and Visualize your Data with Three Complementary Tools


Mark Mitchell

Our design system is helping us build the next generation of digital products

A workspace in Sketch, a graphic editor, displaying user interface components

A workspace in Sketch, a graphic editor, displaying user interface components

At The Economist, we’re building a new generation of digital products. We’re investing in teams of designers, developers and researchers to create apps, websites, newsletters and more that better showcase our world-class journalism.

Our legacy products were designed and built by disparate teams over the course of many years, without a holistic view of the experience. Technological obsolescence complicated efforts to update and align our products. If they are to feel purposeful and connected, they need a consistent user experience, unified by a familiar visual language.

We’re creating a design system to establish this visual language. Here’s how we’re doing it, and what we’ve learned so far.

Documenting our visual language has historically been done with branding guidelines. These define our values and tone of voice; explain our use of colour and typography; demonstrate graphic devices and brand identity; and set out the rules of application.

Our guidelines are static documents, largely focused on the brand and its application in print. With any type of branding guidelines, there are challenges to distribution and adoption. It is difficult to maintain consistency across products and ensure changes are synchronised. This is especially pronounced in digital design where iterations are frequent and far-reaching.

Screenshots of our digital product offering:, The Economist Group, Audio and The Economist Store

Screenshots of our digital product offering:, The Economist Group, Audio and The Economist Store

Examples of inconsistencies in our digital visual language

Similarly, developing products independent of one another increases the likelihood that engineering approaches and quality of code will splinter. As teams may not have a way of sharing their code base, common components may be repeatedly rebuilt, without a guarantee of uniformity.

A design system is a living document in software and code. It is always up to date and new releases are immediately available to other products; a so-called “single source of truth”. As well as including all brand attributes and interface components, a design system contains the principles, standards and best practices to deliver a consistent user experience.

We talk about our design system as a singular product, but it is a sum of parts: a toolkit for designers to help craft the user interface; a component library for developers to utilise and contribute to; and a public-facing website where anyone can easily browse the system.

UI kit

To help designers achieve consistency across our products, we’ve created what is known as a UI kit: a graphic file containing user interface (UI) components and patterns. We use Sketch, an application for designers, to build the kit and synchronise a library of resources across computers. The UI kit defines our digital colour palette, typographic scales, grid layouts — and our design principles. These principles clarify our aims and guide our decision-making.

By working from a shared UI kit, designers and researchers can quickly mock up ideas and prototype features using established patterns. Having transparency on agreed solutions avoids reinventing the wheel every time, allows early input from developers and cuts down on variations in style. For quality-assurance teams, the kit is a reliable metric for testing.

Component library

Components are the basic building blocks of our design system. They are completely modular and independent of pages, groups or context until combined, when they begin to form patterns and a meaningful interface. For example: a button isn’t useful on its own, but join it with a text input, headline and description and you create a pattern for a signup form.

We’re building a centralised code repository for all our designed components. Each component in the library includes all of the necessary markup, styling, scripts and tests needed to use it in a product. A product team can import the components they need, and contribute their own components to the system. Our colour, grid and typography values are stored in a set of named variables called design tokens, accessible by all teams.

With a component library, it is simpler to maintain code consistency and avoid duplication of work. A library provides a practical way of naming and organising components that extends from the design files, and includes front-end guidelines and accessibility standards.


While these are practical tools for designers and developers, it’s not as straightforward for someone who, for example, needs to refer to our brand identity, or quickly browse the library of components. We’ve set up interim solutions, but our long-term goal is a public-facing website that anyone can visit — whether that’s internal stakeholders, marketing, third-party vendors or simply someone interested in our work. Watch this space.

Over the past few years, design systems have come into their own and most organisations now recognise the need for one. Some of the best known examples have come from business (Google, IBM, Salesforce, Shopify, Atlassian) and from government departments in America and Britain.

These organisations, and others, have documented their successes and failures in books, articles and talks, building up a wealth of advice for others to follow. Although the process is unique to the structure, size and culture of your organisation, there are common recommendations for making it a success, and we’ve seen these reflected in our experience. Here are some lessons we’ve benefited from:

Get stakeholder buy-in

From the outset, it’s essential to get buy-in from the people who will create and use the design system: designers, developers, content and product owners. There is a trade-off with a design system. It requires a considerable amount of effort at the beginning, but that cost is outweighed by the long-term benefits. It is hard to quantify the success of a design system immediately, and having a store of good faith can keep it going as it inevitably competes for resources with consumer-facing products focused on revenue and engagement.

It’s also important to have an advocate for your design system. When ours was still just an idea, I spoke with teams across the organisation to explain why we needed a design system and the steps we’d need to take to realise it. In each meeting, I listened to the team’s needs and discussed how we could work together. Crucially, I was given the support I needed by management to plan the system architecture and build out the UI kit, which kept up momentum until we were in a position to start on the code repository.

Dedicate a team

Once I had stakeholder buy-in, our product leadership agreed to recognise the design system as a product in its own right: a product for products. This enabled us to set up a dedicated team with the expertise to understand who the product is for and how they’ll use it. Time is budgeted so that team members (who also have commitments on other products) are not overburdened with work.

A design system is as much an engineering project as design: our team is supported by a tech lead, a delivery lead, and a rotating cast of engineers. And as with our other products, the team follows an agile process, regularly refining priorities along a road map.

Find pilot projects

With both our UI kit and the component library, we found pilot projects where we could test patterns and behaviours early and often. This set up a feedback loop, enabling quick iteration and a method for validation.

Screenshots of our upcoming product offering: The Economist Store, and My Account

Screenshots of our upcoming product offering: The Economist Store, and My Account

Prototype products using the design system

Our first trials were with the account-management area of, followed by our customer store. Both helped us identify gaps in our library and allowed us to test emerging patterns, such as form elements and interactive controls. By putting components together in context, we discovered issues we couldn’t have anticipated when designing them independently.

As we started building the design system, some of our product teams were well into their design and development cycle, and weren’t able to immediately start using it. We’ve discussed ways to manage integration in respect of their road map, and encouraged each team to begin contributing directly to the design system.

Agree governance

A design system requires collaboration and contribution. In order to build out at scale and encourage adoption across products, a design system needs governance: a team with clearly defined roles and responsibilities, supported by documents that explain how to use the design system and contribute to it.

Our governance is centralised, in part because our product and design teams are small and cross-discipline, but also because our designers are together in one place, under the guidance of the art director. As we expand the design system, we will establish a working group to manage the new platforms and channels that join.

We found that getting a process in place of contributing to the design system took longer than we expected, and caused disruption for the first team trying to fully incorporate their product with the component library. That experience helped us to understand the complexities of integration and that a design system, as a product closely joined with other products, needs to anticipate and adapt to the sometimes unpredictable realities of product development.

We’ve created a system to unify our visual language and give readers an outstanding product experience. Within the organisation, we’ve had positive feedback and teams are genuinely eager to get involved.

We haven’t always been able to meet expectations. We’ve made great progress but it’s taken nearly a year to get to where we are, which delayed access to the component library.

However, we’re confident our work will mean a better result in the end for all of our products. And we’re beginning to see a return on our effort: the forthcoming release of, our iOS and Android apps, store and newsletters all use the design system. We’ve found that having something that others can start using, even if all of the finer details haven’t been worked out, is better than being held up by the particulars of a long-term strategy.

As more teams adopt the design system, they bring their own expertise and contributions, which helps us improve the product and scale it to meet organisational needs. From our flagship consumer products and sibling publications, to our corporate channels and third-party platforms, we’re starting to roll out a unified visual language.

Our next step is to launch the design system website, where anyone who is interested can delve deeper. We look forward to sharing our work and hearing our readers’ feedback.

Mark Mitchell is Digital Design Lead at The Economist.


Adam Lisagor

We used to be Sandwich Video. In fact, we’ve been Sandwich Video since 2010, officially. But today, I’m so proud to announce our new name. A shorter name. Leaner, more agile. Why? Just feels right.

See, back in 2010 when it was time to name a company, I thought it would be kind of funny to take my online moniker (short for @lonelysandwich) and slap “Video” on it in a slightly confusing way. I like things that are named like other things. A restaurant named like a power tool. A band named like a cereal. Like, is Sandwich Video a deli or a rental store? Do those even still exist? (There were still some kicking around in 2010, which I know because I did a signage study of LA video stores and mocked this up as an early logo concept.)

Eventually the ambiguity wore off and Sandwich Video had established itself as the upstart little production company for hot new tech companies to get great bespoke videos. We called them “videos” then because what else could they be? Demos? Promos? Probably not “commercials” and definitely not “content”. We made videos for clients, and our output had its own built-in subgenre: if you went to Sandwich Video, you ended up with a Sandwich video. And our style was distinct, so everybody knew it was a Sandwich video. Video video video.

So what gives? Why no more Video? Is video dead? I mean, we still make videos, so video is not dead. Video: now more than ever. But we mostly make commercials these days. We took the format we pioneered on the web and transposed it over to TV, and now, we do “advertising”. We make “creative” which is not something you would have gotten me to say out loud before around ~2016. And if you make creative, you are an agency.

And an agency should be called something short and punchy. An agency needs a new logo and a cool new website. So about a year and a half ago, we started talking to a branding agency that mostly works with space companies, called Cosma Schema. And we worked with them (them being Andrew Sloan and Bob Lenz) to figure out who we are, design a brilliant new logo that looks great on a hat, and develop a very good new website.

That is our brilliant new logo. When this one popped up in a concept review session somewhere in the middle of the second round under the name “Flavor Town”, our jaws dropped to the floor and we all fell instantly in love because it is just so Sandwich.

So, what is Sandwich? When people ask me why the company is called Sandwich, I can’t just say I thought it was a funny name, I can’t say I named my company after myself, or even that I have always been fascinated by the image of a person eating a sandwich while sitting alone, so instead I say this: a sandwich is the perfect content delivery device. It is a whole meal, and you eat the packaging. It is infinitely extensible. People love sandwiches.

(be sure to try Agency Mode)

And as for our website, you have to see it to believe it. To me, it’s a masterpiece. It’s the thoughtful culmination of nearly ten years of hard work making videos and commercials for some of the world’s most interesting companies. It encapsulates our brand and our culture and our whole body of work, and oh the colors. Please visit our new website, and let us know what you think.


Sorry I missed JAMstack_conf London 2019 ?. Here’s my talk here instead.

View a YouTube video of the talk I recorded in my booth.

   (it probably has some nuance and enthusiasm that
the paragraphs below lack.)

? I’ve spent my whole career self-identifying as a
front-end developer and trying to help others become
better at it.

and boy are my arms tired

Screenshots of CSS-Tricks and CodePen homepages

I run the site
CSS-Tricks (which recently had
12th birthday), a resource site all about building websites.

I also co-founded the site CodePen,
a social coding platform all about building things with front-end

I also co-host a podcast called
ShopTalk Show which is going
on 400 episodes.

I’m sure I’ve talked to thousands of other developers over the
years, which has helped me understand the industry and the spectrum
of work it takes to make websites happen.

What is a front-end developer?

  • It’s a job and a common job title.

This is important because it’s not just semantics. It’s a job that
people are hired to do, and it is their job title at work. Nothing
more personal than money.

How we define what this job is and what the expectations are
is personal.

Look at any job board that has technology jobs on it and you’ll see
postings for front-end developers.

What is a front-end developer?

  • It’s a job and a common job title.
  • It deals very directly with the browser, devices, and users.

Everybody that works on websites probably has their browser open all
day, but front-end developers live in there. They have
DevTools open. They have multiple browsers open and test across
versions and platforms.

Crucially, they care about the users that interact with those
browsers and assistive technology.

Mina Markham explains what a front-end developers is at a high

There is a distinction from back-end developers. Its not that
back-end developers don’t care about users, it’s just that
responsibility is delegated.

Monica Dinculescu puts it well:

The browser is at the heart of the job of front-end development.
Whatever you are doing, if your concern is how things ultimately
look and work in a browser, that’s front-end development.

It’s harder than it gets credit for.

What is a front-end developer?

  • It’s a job and a common job title.
  • It deals very directly with the browser, devices, and users.
  • There are loads of tools involved, but ultimately it comes down to
    HTML, CSS, and JavaScript.

Those are the languages that browsers speak. Yes yes, there is SVG
and PNG and whatever else also, but you know what I mean.

Whatever other tooling you use, it all comes down to what ships to
the browser, and front-end developers are responsible for that.

HTML CSS JSThey are gonna come up at work.

Not all front-end developers know all the languages equally well. In
fact, there are lots of developers out there who hardly write any
JavaScript at all, but who are otherwise very successful front-end
developers. And there are also a lot of front-end developers who
write almost nothing
but JavaScript. ?

My article
The Great Divide
digs into the split between front-end developers who are deeply into
JavaScript and those who are not.

It’s not just my thoughts, but a collection of quotes from many
others who feel the divide.

Brad Frost coins the terms “Front of the Front” and “Back of the
Front” as a way to describe another sort of divide. He points out
that it’s not a weakness, but a strength in putting those different
people together.

At Google we have Front End Software Engineers and UX Engineers to
attempt to address these differences. The two career ladders are
very different with different expectations and different criteria
for advancement.

— Steve Paulo (@StevePaulo)
January 21, 2019

At Google, the divide is recognized and split by job title. Plus,
those two career ladders
get paid the same.

There is no doubt about it. Particularly since about 2015,
JavaScript has exploded as a language.

If you need to look at these bigger, use DevTools or whatever. C’mon
you’re front-end developers right?

Our jobs are already facinating! So we all deal with browsers and
users and devices. That’s core. But we all know different stuff, and
actually put that knowledge to work.

Some of us are designers. Some of us are photographers. Some of us
know the law really well. Some of us are way into performance. Some
of us specialize in accessibility. Some of us embrace social media.

Metaphorically, you could map us like this tree.

This metaphor probably doesn’t hold up quite perfectly, but the
divide looks a little something like this. We still share some
fundamentals, and we still branch out and know lots of different
stuff, but one side is heavily focused on JavaScript and “Back of
the Front” type work and the other is not.

Since this talk is about the slow morphing of front-end developers
starting to do more full-stack work and having that role grow wider
and wider, let’s just assume we’re talking about front-end
developers who go down the heavier JavaScript road.

A bunch of stuff you need to do to build websites has sort of
moved stacks.

Back End → JavaScript

That is, from more of a back-end-and-friends skillset to a
front-end-and-friends skillset.

Component-Driven Design & Development

Thanks, Obama JavaScript.

It seems to me non-JavaScript server-side rendered projects never
really embraced components. (There are examples, don’t @ me, but I
mean across the gigantic PHP CMS landscape and Ruby on Rails and
huge players like that.) You had templates and includes, but they
are a pale comparison to real component-driven development.

It’s facinating to see that while there is a wide variety of
JavaScript-based frameworks that all disagree on plenty of things,
one thing they all agree on is the idea of components. Even native
web components… it’s right in the name.

Let’s take a quick look at CodePen, which is a
React powered site (mostly) these

Even this tiny little SVG icon? It’s a component. We call it an
component because it nicely abstracts
away a few things that are useful to us.

Pairing an icon with a number is another component, because it is
another repeated pattern and might have additional responsiblity,
like being clicked.

That whole row of MetaItem components might become a component,
along with other aspects of an Item’s display

So of course the whole Item itself becomes a component.

These are visual and functional abstractions of what we need to
build the UIs. There is semantic HTML underneath, but the
abstractions are building blocks of our own devise.

Larger and larger areas become components. In this case, it makes
sense that a grid of items becomes a component, so that it can
handle that layout and things like pagination.

It’s true! Not only are components capable of being intellegent
building block abstractions for UIs for front-end developers,
designers are largely already working this way. Tools like Figma,
Sketch, and Adobe XD tout things like “symbols” which are
spiritually connected.

I find other developers are like “cool, components, I get it”.

Site-Level Architecture / Routing

Back End → JavaScript

OK I guess this is my job now. It makes sense and I like the
control, but it’s a big serious job.

Dealing with URLs and overall site structure used to feel primarily
like a back end concern. These days, “routing” is becoming more and
more a front-end concern.


Looking back at the CodePen UI, the components don’t stop at the
grid. Literally everything becomes a component. The tabs, the
titles, the buttons…

… the forms, the menus, the sidebar…

Ultimately the whole gosh-darned page becomes a component.

Once the whole page is a component, what you’ve really done is
turned the the URL into a component.

And now that the URL is a component, all the URLs are components,
and you’re controlling the whole site.

You’ve become an architect of the entire site, in a sense.

That’s… a lot. Think of all the work you already have to do as a
front-end developer. None of that goes away. You’re just responsible
for a lot more now. It’s no wonder that front-end developers are
feeling more and more full-stack-y.

State Management Getting & Mutating Data

Back End → JavaScript

Another thing that has fallen into the hands of front-end developers
is state management. Now that’s kind of at the core of most
JavaScript frameworks and it’s a pretty great concept that wipes
away a lot of front-end spaghetti problems of the past.

But state is often filled from getting data, and that’s now
often on our shoulders as well.

Even more complicated is changing that data when necessary and
sending data back to servers when required.

GraphQL is a pretty great answer
to some of this. GraphQL is a lot of things and meaningful to
different people in different ways. But to me, it’s about

With a strong GraphQL endpoint in place, and tools like
Apollo giving me tools
to use in my JavaScript framework, I can, as a front-end developer,
get my hands on any data I need to build UI.

import gql from "graphql-tag";
import { Query } from "react-apollo";

const GET_DOGS = gql`
    dogs {

const Dogs = () => (
    {({ loading, error, data }) => {
      if (loading) return `Loading...`;
      if (error) return `Error`;

      return (
        { => (
))} ); }}

Note that not only am I getting all my own data, I’m managing the
asyncronous nature of the component. Should I show a skeleton right
away? A spinner? Should I delay rendering until the data is ready?
What happens if it times out or there is another error?

Not only can I get data, but it’s on me update
that data and send it back through GraphQL in the form of mutations.

import gql from "graphql-tag";
import { Mutation } from "react-apollo";

const ADD_TODO = gql`
  mutation AddTodo($type: String!) {
    addTodo(type: $type) {

const AddTodo = () => {
  let input;

  return (
      {(addTodo, { data }) => (
{ e.preventDefault(); addTodo({ variables: { type: input.value } }); input.value = ""; }} > { input = node; }} />
); };

Mutations aren’t terribly more complicated than queries, but it’s
all the more work that is on my plate as a front-end developer. Work
that was almost surely in the realm of back-end development before.

Note that the above examples were illustrative of GraphQL, but done
Apollo Client implemented in React.

While we’re talking about components, queries, and mutations, let’s
throw one more thing on the pile: styling.

Front-end developers have always been in charge of styling, but in a
land of components that are self-contained in so many other ways, it
starts to make sense to co-locate the styling information as well.

Here we’re using
CSS modules
to scope the styles to a specific component. We can and do still
have global styles, and we even continue to use
Sass for useful global

.root {
  display: grid;
@import styles from './styles.scss';

The result of this componentization and co-locating is nice little
folders that have everything from logic, to view templates, to
queries and mutations, to styling all together.

It’s convenient, but it has cool interesting side effects. For
example, JavaScript bundles may contain what they need (code
splitting). Styling doesn’t get
because when components stop being used because their styles leave
with them. Not to mention naming things is a lot less stressful
since the naming is file-scoped.

The GraphQL documentary is kinda fun. I like what Kyle Mathews says
(about 20:24) about React wiping away a whole class of front-end
development problems, and how GraphQL does a similar sort of thing.

For every project? Of course not. But for the somewhat large and
complex apps that we’re so often expected to build and maintain:

All the very huge responsibilities front-end developers already

  • Pulling of the design
  • Making the design part of a system
  • Making sure it is accessible
  • Worrying about the performance
  • Testing things across browsers
  • Testing things across devices
  • Sweating the UX

Oh hello, big pile of new responsibilities

  • Component-driven design, designing our own abstractions
  • Site-level architecture
  • Routing
  • Fetching our own data
  • Talking to APIs
  • Mutating data
  • State management

The haystack of responsibilities grows and grows and grows.

That’s not to say that all of us need to know every single part of
this and do it perfectly well, but it is to say that these are tasks
that fall within the realm of front-end web development.

Peggy Rayzis talks about how wide the term front-end developer has
gotten and that it’s likely we’re specializing.

Again, a bunch of tasks have sort of moved stacks. From what used to
be rather back-end jobs to being in the JavaScript realm.

Let’s draw a spectrum and see how that has morphed through time.

LAMP is Linux, Apache, MySQL,and PHP. It’s a rather old stack, but
it’s still very huge. It’s what an awful lot of CMS’s run. LAMP is
how the stack is talked about.

If I’m a front-end developer working in that stack, I’m way over on
the other side of the spectrum, not touching much of the technology
the stack is referring to.

MEAN is another stack, referring to MongoDB, Express, Angular, and
Node. Notice the OS isn’t mentioned anymore.

Notably, Angular is a front-end framework, so the stack is starting
to include that. If I’m a front-end developer, what I’m working on
overlaps with the stack.

Serverless moves the stack further to the right. We don’t even care
what servers the code runs on anymore, it’s just server-side code
using and creating APIs.

If I’m a front-end developer working in this world, I overlap in
that I might even be using my JavaScript abilities to be writing
these serverless functions and digesting the APIs.

Shawn Wang called
Design Systems, TypeScript, Apollo GraphQL, and React a STAR app.

That’s… like… all front end stuff.

It seems to me the way we talk about the important technology that
powers websites shifts more and more toward the front-end developer

Let’s take a quick look at how serverless is
expanding our front-end powers.

JAMstack logo

I consider JAMstack to
essentially be a part of the serverless movement.


Javascript, APIs, and Markup. Although I would say, half
tounge-in-cheek, that
makes a bit more sense.

title: JAMstack_conf_ldn
url: ''
cocUrl: ''
date: 2019-07-09T08:00:00.000Z
endDate: 2019-07-10T16:00:00.000Z
location: 'London, England'
byline: 'Learn how to design, develop, and deploy fast, modern web projects that run without web servers.'

Following the inaugural [JAMstack_conf in San Francisco]( in 2018, we're now also bringing an edition to London where we'll have talks about how to design, develop, and deploy fast, modern web projects that run without web servers.

Each conference is a
Markdown file with
Front Matter
to describe meta data associated with the conference, like the city
and dates.

I wasn’t deliberately trying to avoid a database, but this just
seemed like the perfect kind of site to use a
static site generator
for and the data needs are so basic that flat Markdown files are a
natural fit.

So each conference is a Markdown file, and there are some basic
templates in
Nunjucks, and
Eleventy is wonderful for
processing that kind of setup.

The site is
a public repo on GitHub. That seems obvious, perhaps, but I think it’s hugely significant

It means that:

  1. The entire site is in the repo. To run it, you pull it down and
    run a single command.
  2. There is no fiddling with log ins, permissions, or credentials.
  3. It opens up the content of the site for public
    contributions, as well as the design and functionality. This has
    been huge.

The site being on GitHub means I could just leave it on GitHub
Pages, but it’s like a 2-second process to put in on Netlify, which
is a massive improvement. Here’s a few reasons:

  • Deploy previews.
    When I get a Pull Request, I can take a look at a live URL of what
    the site will be like with that Pull Request merged. Amazing.
  • I can activate
    on the site and get the most accurate possible numbers.
  • I can
    fiddle with my images

There are a couple other big ones though…

With Netlify CMS, I get a
UI to edit content right on the site itself. No code editing or Git
involved at all once it’s set up.

I don’t even need Netlify to use Netlify CMS, but
Netlify Identity
makes the auth part a million times easier.

Check out this feature of the conference site. For each conference,
you can click a button that reveals an email input form. Enter an
email and submit, and the site fires off an email with details about
the conference.

That’s a back-end thing. You can’t really send email with
client-side technology alone. You can communicate with APIs that
will send email, but even that requires API keys that need to be
kept secret via back-end code.

const SparkPost = require('sparkpost');
const client = new SparkPost(process.env.SPARKPOST);

exports.handler = function(event, context, callback) {
      content: {
        from: '',
        subject: `Conference!`,
        html: `

Hello, World!

` }, recipients: [{ address: email }] }) .then(data => { callback(null, { statusCode: 200, body: `Message sent!` }); }); };

I’ll use Sparkpost to send
the email. They offer APIs to send email (that’s the entire point).
They also offer a Node.js library to make it very easy. Ultimately
just a few lines of code.

And that code? It’s JavaScript. I’m a JavaScript developer. This is
not a stretch.

How do I run this?

That’s the meat and potatoes of serverless:
cloud functions. I’m talking about
AWS Lambda,
Azure Functions,
Google Cloud Functions, etc.

The Netlify version, which is AWS Lamba under the hood, is
Netlify Functions. It’s stupid easy. You just toss your functions in a `/functions/`
folder and run them by hitting a relative URL.

It feels very powerful to be able to build the entire site from front
to back like that.

Let’s revisit the spectrum of technology again with this modern stuff
in mind.

I don’t really have to care about operating systems and servers.
Entire products can be built without having to care about these.

I probably don’t need to care much about databases either. It’s not
that databases aren’t important, it’s just that my dealing with data
is likely to happen through APIs. Perhaps a Headless CMS (e.g.
Contentful). Perhaps a data
storage tool that is designed to work through APIs (e.g.
FaunaDB) or on-page libraries (e.g.

So now I’m left with a spectrum of technology where I can work with
all parts of it.

So I’m feeling pretty full-stacky already. But you take all that and
add in:

  • I know Git
  • I can write tests
  • I design
  • I know about build processes
  • I care about performance
  • I can make sites accessible
  • I can set up a basic deploy pipeline


You’re Gosh Danged Right I’m a Full-Stack Developer!


The haystack of skills here is getting extremely large.

You can totally specialize. You probably will anyway. That’s good.

“Actual” unicorns, those people that are very good at every task
across the entire spectrum of building websites: as rare as actual

I’m also not trying to insinuate that back-end developers are
becoming obsolete. In fact, the fact that building websites has
gotten so damn complex, they are more important than ever.

Right now, I can open up the CodePen issue tracker and see 89 issues
that I can’t solve alone. I need back-end developer help to dig into
them and fix them. I can think of myself as full-stacky if I want,
but I know that back-end stuff is where my rough edges are.

Things tend to end up a bit more like this.

Or in my case, more like this:

That’s not to make fun of anybody. I mean, maybe a little, but it
draws a nice metaphor that is kinda perfect for this talk. We are
the whole horse! The whole dragon! But we’ve got rough edges. So

It’s cool to see the tech around our job evolve to the point that we
can reach our arms around the whole thing. It’s worthy of
some concern when we feel like complication of web technology feels
like it’s raising the barrier to entry. That happens sometimes and
it’s not great. But it’s also worthy of cheer when web technology
becomes simple enough that people can build things from start to
finish all by themselves. That’s pretty cool.

While we’re being all productive and amazing, let’s just remember
that doing a good job is everybodies job.

  • Good UX is everyone’s job
  • Good performance is everyone’s job
  • Good security is everyone’s job
  • Good accessibility is everyone’s job
  • Doing right by the people that use your website is everyone’s job

Even if you aren’t writing the code that directly affects any of
those things, you care about them and fight for them to be handled

CodePen PRO (support your local
artisanal craft software products with money)