Full Frontal — The conference experience
Next level CSS, progressive web apps, accessibility, continuous deployment, the power of emoji, dev-tools secrets, the history of modularity and making art with code.
We were up at 6am and in the car at 7 on a fresh November morning to go to Full Frontal conference in Brighton.
I love conferences. You come out with a thousand new ideas in your head, full of inspiration. My first conference was the thing that really set me off getting excited about all things front-end, back when responsive design was just starting to rear it’s head. 6 years later, they’re still getting me fired up to make software better.
Duke of York’s picture-house
We arrived in sunny Brighton just after 9am and strolled down to the conference venue.
FFConf is a two-day one-day conference. The same conference, but two days back-to-back so more people get to see the awesome talks.
It was cold in the autumnal Brighton air, but there was free coffee, pastries and stickers so we were happy as developers can be, away from their computers.
We grabbed some comfy seats in the theatre, got super excited about the offline support on the conference site (yay, service workers!), and commented on how jacked Remy (the organiser) is looking.
But that’s enough introductions, you’re here for the juicy talk details right?
Next level CSS
Our first speaker was Rachel Andrew to take us through some next level CSS. Front-end developers sure love new toys and she had all the toys.
Most exciting was the new CSS box alignment module level 3. What does that mean? Well, it’s proper grids coming to CSS. We’ve been hacking grids with tables, floats, inline-block and flex-box for a while now, but now we finally get display: grid;
The spec is as big as it is exciting so I won’t write it all down here. Instead, get yourself over to Grid by Example and check out some of the code yourself.
Keeping the web in web apps
All fired up on exciting new CSS toys, our next speaker was Ada Rose Edwards, talking about progressive web apps.
These are the hot new topic at the moment, supposedly blending the best of the web with the feel of native. I’m super excited about them and feel they offer a much better solution for most people who think they want an app.
I was expecting more toys and some demonstrations and examples of progressive web app tech: offline support; push notifications; app manifests; home-screen worthiness. What we got was an awesome reminder to keep the progressive in progressive web apps.
The future is already here — it’s just not very evenly distributed
Everything is great on our shiny new macbooks and shiny new smartphones with our super fast 4g or wifi, but we can all do with a reminder that there’s a lot of internet out there that doesn’t work perfectly.
You might think that’s limited to developing countries, but I bet you’ve had a website semi-download or fail to download whilst on the train.
The current practice of loading an enormous client-side only ui framework to handle the content delivery is killing the power at the heart of the internet. We’ve forgotten to send some good old HTML from the server. Chrome developer relations is recommending the PRPL pattern for thinking about how to download your resources.
By building on top of the heart of the web instead of rewriting it, we can create experiences with longer life spans that can be used by more people for more years to come.
More cake
Minds freshly blown by our first two talks, we popped outside for a break, more coffee and more pastries. I’m not sure conferences are good for my waistline. I wonder if Remy keeps a secret stash of beef jerky for between speakers…
Technologic: Accessibility mix
Freshly filled with sugar and caffiene, our next speaker was dropping more toys on us, this time with accessibility as the focus.
I’m a huge fan of keeping the web accessible. At my interview for Etch, Jim Ramsden asked about my process for building websites and I said I start by trying to make a site that *sounds nice. *I pump my HTML through a screenreader before adding any JS/CSS to make sure it’s semantic and works for users who are visually impaired.
Leonie took us through some great ARIA patterns to make your HTML more accessible and semantic in this day and age of complex web apps. There’s a little more detail on these and some great links in my recent article: 10 things your website might be missing.
There were also some awesome tools to help automate your accessibility workflow. We know human error is the cause of 99% of bugs, so anything you can do to remove it will make your code better.
Tenon api can test your site against accessibility guidelines at multiple resolutions. This can be built into your CI setup to prevent accessibility regression.
There were several tools for the more popular JS frameworks out at the moment including the Ember A11y test suite, the React accessibility API and ngARIA for AngularJS.
All things continuous
Our pre-lunch talk was a devastating knowledge and tools explosion on all things continuous. I could barely keep up with typing out the names of the different things available for keeping you shipping code.
Continuous integration/delivery/deployment means automating the process between your development team’s laptops and the production server. You should be confident that it’s difficult to impossible to push broken code and this should let you ship more features, more often.
Amazon ship to production every 11.6 seconds.
I love the continuous integration setups we have at Etch. They make me feel safer when pushing code to live and that keeps us shipping.
This talk dropped so many new ideas on tools to try out and deployment best practices that I’m just going to write out a huge list for you to investigate. All the tools are free and private.
Provisioning
Hosting
Deployment
NPM shrinkwrap, Yarn, Docker Swarm, Mesos, Kubernetes (with DEIS and Flynn)
Logging
Logz.io, Logstash, Uptime Robot, Status Cake, Data Dog, Zapier (to wire together), Stack Storm, Bip.io
Andrew covered a few different large scale deployment types such as blue/green, canary and hit ‘n’ hope (probably not the best one, haha).
The final takeaways were: fix forward, embrace failure, rollback if you have to and write tests to stop it happening again.
Lunch
After a long morning of learning, we headed over to the nearby Joker pub where they do a mean line in buffalo chicken wings. We’d booked 8 developers in from different companies to chat nonsense through the lunch hour and get excited about Jeremy Keith having lunch in the same building.
I think Brewdog Nanny State might be the best “work beer” going at 0.5% ABV and still delicious.
Power of emoji
The problem with a serious lunch is it can leave you seriously sleepy. I’d noticed the emoji talk after lunch as was expecting some light weight lols on the use of emoji in the modern world.
Mariko’s talk turned into an incredibly detailed history of emoji and their journey from Japan (E-picture, moji-words) into a worldwide phenomenon.
It turns out the first digital emoji was created around 1997 with a heart emoji on Japanese pagers. Shigetaka Kurita, working at DoCoMo, saw these pagers sold better than others and decided to add emojis to the available characters on the i-mode mobile internet service in Japan.
It’s crazy to think one man could define an entire set of emoji characters. Now there are entire standardisation bodies working on making sure emoji are compatible across countries and devices.
Optimise your development workflow
Having been woken from our post lunch slumber with the power of emoji, it was back into the toys with some dev tools secrets.
I wanted to write more of these down, but Umar had absolutely packed his talk with tips (over 100 slides! of gifs!) and I just had to sit back and soak up the awesomeness.
Highlights for me were CSS animation debugging, CPU throttling, in-browser terminal and live nodeJS app editing.
Secret features: try going to chrome experiments in Canary and hitting shift 6 times to open up the experimental experiments!
All I can say is, you definitely need to sign up to Umar’s dev tip newsletter.
Free beer and ice-cream
Literally reeling from the information bombardment, we stumbled out of the theatre and towards the delicious free beer and ice-cream. What better way to pick up a room full of 200 developers? I wonder if anyone got both…
A brief history and mis-history of modularity
When a speaker opens with recursive space turtles, you know things are going to get interesting.
Ashley was in from NPM to talk about the concept of modularity. What was awesome, was that this talk was literally about the concept. Ashley majored in philosophy at University and things quickly got cosmic.
We began with broad concepts, looking at both great programmers and great philosophers, and moved through to more practical applications of modular code.
Start with difficult design decisions or design decisions that are likely to change. A module should mask the things that are complex or liable to change.
This particular (badly remembered) quote absolutely rang true for me. It mirrored something I heard at a front-end architecture workshop with Micah Godbolt earlier this year. We are trying to mask complexity or code likely to change with our modules. By doing this, we can free up our brains to worry about the rest of the app.
Really nice applications are just a tiny bit of application logic that can’t be abstracted away, everything else should just be modules/packages.
Ashley tackled one common criticism of modular architecture covered in “The cost of small modules”: the more you modularise your code, the bigger it gets.
Modules are great for developers, but not in the final runtime. Our modularised code is awesome to write, but it’s hurting performance for the end user.
By using a non-preserving build tool such as rollup or closure (rather than webpack or browserify), we can remove the modularity in the runtime environment and speed up our apps. Best of both worlds!
Art.js
Having had a minor existential crisis over modular JavaScript (standard working week hey), it was time to get really cosmic with some live coded JavaScript art.
Mathieu is well involved with Demoscene and Creative Coding, people who make art with code. The goal is to create something expressive, rather than functional.
Mathieu gave us some breakdowns on techniques that could be used to animate canvas elements and create audio sound effects with code, then got stuck straight into a live coding demo.
Coding with no libraries, no frameworks, 1 primitive and 1 formula in front of 200 developers… live. It was a crazy idea, but it paid off, creating a wild animation and music to go with it in only a couple of hundred lines of JavaScript.
Brighton
And just like that… it was over! A roller coaster of tips, techniques, history, art, tools and everything in between. We dispersed into the night to discover Brighton, Mexican food and awesome beer with our brains filled with code.
If you’re thinking about a conference and want to get inspired, don’t hesitate. I’ll be looking forward to FFConf 2017 (Link should work in a few months right?).
Many thanks to all the organisers and speakers for getting us excited about front-end.