ffconf 2017
Web components meet 8-bit video games
I recently attended ffconf - a conference in Brighton for web developers. This is the first time I’ve been. The event is broad and covers general topics about the web as a whole, rather than covering the latest trends in web development. That’s what drew me to it in the first place; as someone who has been primarily involved in “backend” development but wants to diversify a bit, I wanted something that I was sure would be a worthwhile investment, rather than a gamble on a framework I may never use.
It’s held once a year at the Duke of York’s cinema in Brighton, so I didn’t have far to go. We were welcomed with delicious pastries and a classic 80’s playlist which set the bar high for what was to come.
The rest the day didn’t disappoint. I made a lot of notes during the day, and it’s been helpful to go over them afterwards and write them up here.
Big thanks to Remy and Julie for organising such a great event - I got a lot out of it.
1. Rethinking the Web Platform
James Kyle spoke on the conflicts between making progress and technical correctness when learning web development. He helped a friend create an app using React without gaining any experience with HTML or CSS first.
He felt strongly that statements of the form “you need to learn … first” were off-putting to new developers. Instead, he saw all web sites as a set of components, and advocated for getting started with a framework early on that could provide those and get a project up and running in it’s entirety, at the expense of having parts you don’t understand.
James’ argument was that we need to rethink our approach to teaching, embracing tooling early on and placing a lot more emphasis on getting a result quickly. Only then should you go back and start learning individual parts in more depth. To really learn and understand a topic you need an appreciation of where it fits within the wider picture, and an understanding of how it relates to other things.
I was intrigued by this talk. Much of it resonated with me; some things I disagreed with; overall it was thought provoking. It was a challenge to hear that as an industry it’s not easy for new developers to pick things up. But I still think we need to be careful with tooling though, particularly a large framework like React. I think that comes too soon, learning a tool before knowing what that tool does for you.
I’ve taken away some things from this talk for use when I teach things. I like to learn in a thorough, methodical, bottom-up way, usually outside of a real world project. It’s inevitable that’s also going to be reflected in how I teach. But not everyone learns that way. Many people are happier with a big picture that they can delve into from the top-down, gradually understanding more and more. The challenge is to fit in with them, not the other way round.
2. If you’re going out of San Francisco, be sure to wear Web Standards in your hair
Bruce Lawson started by looking at some of the holy wars in web development. All industries have them, and our current one seems to be CSS vs CSS-in-JS. Pure use of the fundamentals of web development (HTML, CSS & JavaScript) is often out of line with what happens in the real world. CSS for components is difficult - everything is global, the order matters, and the CSS is tightly coupled to the structure of your HTML. But CSS-in-JS is only a methodology, not a new technology, and similar things have existed before.1
We risk locking out many great designers who understand CSS if we use a different model just for our own convenience.
There’s also a performance cost. Bruce spoke of some of the work he’s doing with Wix. Traditionally everything was built with JavaScript. That’s been ok–performance wise–on desktops, but now has real problems on mobile. They are working on a project called Stylable to address this.
Utimately though, the web isn’t about computers or clouds, it’s about people. Technology is only worth caring about because it facilitates the communication between people across the world. During the talk Bruce shared the story of his diagnosis of MS and his first use of the internet as a result. Whilst abroad he was able to get online in an internet cafe, finding forums and information about the condition. Some of the founders of those sites have become lifelong friends.
Bruce went on to give some illustrations of the digital divide. In Africa, the lack of locally relevant content and digital skills are some of the biggest barriers to internet adoption.2. Cost is often prohibitive. In Nigeria, the bandwidth for a 2 minute video clip can cost more than sending a child to school for a month.3 Landlocked African countries typically incur an extra $232 to the cost of monthly broadband.4
The web can provide opportunities for the poor, particularly for women, older people and disabled people, who generally benefit more from flexible online working. Progressive web apps are thriving in Asia and Africa, where native apps are too big.
The web is a lifeline for people in backward and despotic regimes. But we need to be more responsible in what we do, and ensure large companies like Google, Facebook, Twitter and Amazon are held to account in the way they make profits.
As our industry professionalises, we mustn’t lose the sense of craftsmanship, and the artisan mentality of caring about the end product. This is perhaps best described by the Japanese idea of shokunin:
Shokunin means not only having technical skill, but also implies an attitude of social consciousness... a social obligation to work best for the general wefare of the people, an obligation both material and spiritual.
If you haven’t already, I’d recommend reading Bruce Lawson’s article World Wide Web, Not Wealthy Western Web.
3. How to train your dragon web standards
Monica Dinculescu talked about how web standards come to be. Web standards are a compromise between browser vendors. We need them to stop browsers copying each other’s bugs.
Not all standards have been sucessful - <input type='date'> for example. Although a popular request, it turns out date pickers are a hard thing to standardise because of the variety of ways people use them. Which day of the week to start on? How do you omit day, month or year? How do you style it?
This example hasn’t worked because it was an attempt to standardise the component rather than the component model. The date picker is too high level. Web standards should focus on low level capabilities of browsers, leaving space for libraries and frameworks to build on this. WebGL is a good example - it facilitates graphics on the web, and tools like D3.js exist because of it.
A standards process should have these properties:
- it should cover something that browsers already do
- it should document and explain any existing browser magic
- it should be extendable
- people should already use and like the feature
Monica went on to talk about one particular standard - web components. The idea behind web components was born out of a desire to reduce the amount of copying & pasting JavaScript to produce common widgets, like date pickers. Web components are an attempt to standardise ideas behind many different models, rather than any one implementation. They provide the low level functionality for something like a date picker to exist - a lifecycle and integration with the DOM.
Despite the extensible web manifesto being made in 2013, progress has been slow. It’s a catch-22: developers are hesitant to use features that browsers haven’t fully implemented, and browser vendors won’t implement things people don’t use. Polyfills (named after Polyfilla!) are the answer to this. They are–quite literally–a way to plug holes in existing browsers. We shouldn’t be scared of using them!
4. Lessons learned sciencing the web
Addy Osmani looked at using data science to help with performance on the web.
Mobile devices are resource constrained. On a 3G connection, 600ms is taken up with the network overhead. The server response adds another 200ms, only after which can client side rendering take place. So it’s cruicial to load only what you need, when you need it.
JavaScript comes with a cost due to parsing and compiling. So don’t just consider download size - 100kb of JavaScript is not the same as 100kb of JPEG. We can do a lot by removing unused code, or deferring what we don’t need for the current request and lazy loading it later. An average phone (eg Moto G4) will parse 1Mb of JavaScript in 1-2 seconds, but this can vary from almost nothing on an iPhone 8 to over 6 seconds on a low-end device.5
Addy explained the PRPL pattern6: push the minimal code for the initial route, render it and become interactive as soon as possible. Then pre cache remaining resources using a service worker and lazy load anything else. He went on to give examples of this from CNN and Pinterest.
It’s also important to examine your caching. <link rel="preload"> is a way to specify that resources should be fetched early on. We can use this for any type of resource, not just CSS and JS. There are also prefetch (loads but doesn’t parse), dns-prefetch and preconnect declarations.
These declarative ways provide hints to the browser about ways in which performance might be improved. They are a lot easier to debug and reason about than something like HTTP2 server push. Although push can be powerful when you know what resources are needed, it isn’t cache aware, so the browser may download more than it needs to.
Images qaulity can make a big difference too. q=80 is a good baseline for JPEGs.7 Tools like ImageOptim and mozjpeg can give you a comparison of quality levels and their respective file sizes. Addy has also written a guide to image optimisation.
If you’re using webfonts, have a loading strategy. Preload can bring a big improvement; you don’t have to waiting for the CSS to finish loading. But if you can’t load fonts quickly, don’t load them at all. The font-display property dictates how long a browser should wait for a font to load–if at all–before showing a fallback.
Finally, it’s important to introduce workflows that force everybody to think about load times from the beginning. Performance budgets are a useful constraint to have.
5. My password doesn’t work
After lunch, Blaine Cook looked at passwords.
Much of his talk originated out of frustration in helping a friend–who is a nomadic guide in the Jordan desert–set up email on his phone. There were many hoops to jump through, not least configuring an iTunes account and billing address. Why did Apple need this information for someone to download free apps? What data did they really need? And why do password restrictions seem so arbitrary?
Email addresses are so often used as a primary means of identifying someone. And if that service also uses a password, it can usually be reset via email, thereby rendering the account only as secure as the email account.
Blain gave an overview of the forgotton-password-reset-email dance that we encounter so regularly. This process is only a means of verifying that someone is who they say they are.
He advocated for third party sign-in as a good way to improve your conversion, arguing that if you’re going to provide a password reset mechanism over email, you might as well just use that email provider as your authentication provider. This can improve conversion, because there’s one less password for a user to remember.
I’m always skeptical about logging in with Google/Twitter though! I think there’s some more information needed on the possible privacy implications of doing this.
There were some pointers for web developers too:
- don’t require an account at all if you can help it
- if not, leave sign in as late on in the process
- long lived sessions reduce the number of times users need to enter passwords
And we should all take care to keep our primary email secure. So much is accessible via it.
6. Don’t forget to take out the garbage
Katie Fenn gave a overview of garbage collection in JavaScript, and illustrated how Chrome dev tools can highlight memory usage.
Memory is a finite resource, and apps will find a way to consume it. Memory is particularly constrained on older devices.
Languages like C require manual memory management - you ask for memory by calling the malloc function and return it for reuse by calling free. Unlike C, we don’t have to do this in JavaScript. The browser keeps track of what memory are in use and can release it as required.
JavaScript scope captures variables declared with var, let or const and makes them available to the functions within that scope. Once the scope no longer exists, the variables are no longer reachable, and can be garbage collected.
The memory heap is divided into two sections - a young generation area and an older generation area. The younger generation is small and fast, for short lived, frequently used data. The older generation is for longer lasting data.
Variables start off pointing to space in the young generation segment. Once that space is full, a minor garbage collection occurs. All the unreachable variables are considered dead, and can be discarded. Anything still alive after two minor garbage collections then gets moved to the older generation. A major garbage collection marks dead objects, sweeps the memory and compacts it, freeing it up for future use.
JavaScript does a good job managing memory for us, but there are some potential pitfalls. If we aren’t careful, variables can remain referenced longer than we expect, and end up not being released. This is a memory leak, for which there are a few common causes:
- accidental global variables caused by a missing
var- these will have the global scope rather than the function’s scope, so they will end up living indefinitely - forgotton timers and event listeners also keep a scope alive
- detached DOM nodes
Katie illustrated using the Chrome task manager and dev tools to highlight memory usage. These give you an overview of the memory footprint of each tab, and an indicator of what objects are in use.
7. Abstract art in a time of minification
Software is for humans. It’s easy to forget or ignore that sometimes. To be a good engineer, you have to be a good member of society.
Jenn Schiffer learned by viewing the source of web pages. Nowadays, that method of exploring other’s work isn’t always enough to learn how things work; a lot of what we do is hidden behind developer tools. In treating those tools as only for developers have we raised barriers to entry for people? Have we unwittingly made it more difficult to learn to code?
There’s a sense of ephemerality about what we do online now. Things we produce and the tools we use to do so are often at the mercy of startups who disappear at any moment without our consent, leaving a steam of 404s in their wake. Ownership is another issue - who really owns your data? Which companies can you trust with it and what will they use it for? Do we understand our rights and what licences like GPL and MIT give us? Can we educate people about this?
In a capitalist society, companies have an incentive to do things faster, but not always better. Computers are very good at doing this fast, but not all problems are best solved with speed. Many problems require empathy, and if we’re not careful technology can often make things worse here. Jenn gave examples of how software can introduce racial bias to law enforcement.8 9
Like the art world, the tech community has a problem with diversity and representation. But we make this worse for ourselves when we consider problems like accessibility as “too hard to solve”. Why do we argue this? Ok, it may take a tiny bit of work to understand the difference between a div and a button, but is that not worth it to avoid leaving technical debt for those less fortunate than ourselves.
That optimistic belief that every problem can be fixed sometimes leads people making tech to think they’re the only ones who can fix things. And all of these problems are severely exacerbated by tech’s persistent failings at inclusion, which means these problems affect marginalized communities even more acutely.
Anil Dash 10
Jenn left us with a challenge: What’s your legacy? Think! talk! Widen and diversify your network, and become role models.
8. Alpha, beta, gamer: dev mode
Joe Hart, descibed as “a comedian who codes”, closed the conference with something very different.
Regaling us with tales of his unfortunate Sims characters and their various demises, through communist Tetris to a nuclear weapon-wielding Ghandi (it happens when you represent agressiveness using an unsigned int…), he then got the audience playing games of cheering controlled Flappy Birds and home drawn Super Mario.
If you like get the chance to see this show, do! It was a lot of fun, and nice way to end a thoroughly useful and enjoyable day.