07 July 15 Code, coffee and frontend devs: a wrap up of Web Directions Code 2015.

Some key takeaways from this year’s Code: user experience is king, time is money, test your code and use tools to improve your workflow.

Held in Melbourne on 25 and 26 June, Code, presented by Web Directions, was two jam-packed days of ideas and awesome catering (hello pulled pork wraps and chocolate éclairs!).  The conference offered amazing insight into building websites, the tools that help us improve our workflow and finding out what’s coming to the web.

I attended the conference with Allan Pope. We weren’t really sure what to expect from our first Code conference. In web development, things change so fast and there’s always so much to learn. I felt a bit embarrassed to admit how much I didn’t know to the man sitting next to me. He just laughed and told me not to worry. “I think everyone here feels like a junior developer,” he said. Day made.

The conference program focused heavily on JavaScript, with much discussion centring on emerging ES6 features. But it wasn’t all talking heads. There were loads of demos, code examples and dialogue making for a really inspiring event.

While we’d love to tell you about every speaker that presented, here are our top five sessions from Code 2015.

If you were at the event, we’d love to hear your thoughts on what you found useful and inspiring. Feel free to comment at the bottom of the page.

1. Mobile-friendly sites are no longer a nice to have, they’re essential.

Alex Russell, a software engineer at Google, gave us a glimpse of the future of the web in his excellent one-hour presentation.

Alex presented some interesting statistics on mobile usage. He noted that for many people, mobile is the only way for them to access the internet – driving home how critical it is to have mobile-friendly sites.

And yet in 2015, there are still so many websites worldwide that are not mobile-friendly. Google even blogged about it. In fact, the tech giant was explicit (something that Google rarely is) in its directive that mobile sites matter.

Alex also discussed the rise of ‘progressive apps’ – web apps built with TLS/HTTPS, Service Workers and Manifest in order to function like a native app.

A progressive app starts out as a standard web app accessed via a mobile browser, such as Chrome.  It is then ‘installed’ on to the home screen when the user chooses to ‘add to home screen’. Now when the app is launched from the home screen it looks like a native app, but if it has Service Workers, the app can work without an internet connection. A web browser can also use Manifest details to suggest that a user add the app to their home screen after multiple visits. It can even send push notifications: check out Roost for quick demos.

But how do you decide between building web app versus a native app?

Native apps are developed with the mobile platform (Android, IOS etc) in mind. Native apps are usually faster and more efficient and, unlike web apps, they can access some native mobile features.

Alex reinforced this view by presenting us with strong supporting statistics. He mentioned that 86% of the time spent on mobile is spent on apps. Of that 86%, 40% is on gaming, 26% social and 20% is ‘other’.

So, if your application lies within that last 20%, you might need to consider if the costs are worth it. Not only is it expensive to build, but a native app needs to be tailored to different mobile platforms.

And a native app may require further promotional and marketing costs to get people to learn about and install it.

According to Alex, users use 12-20 apps per month, but you can get more than 100 site visits in the same amount of time.

For an eCommerce site, a web app is a simpler point of entry for your customers: you’re not asking someone to download your app before they’ve even made a purchase.

2. The world of animation.

Rachel Nabors, award-winning cartoonist and interactive developer, talked about the state of animation in the post-Flash era.

When Flash died, she said, we lost a host of great animators and their knowledge. Rachel interviewed four people in different roles on the topic of animation: UI designers, interaction developers, animation library developers and animation spec authors and implementers.  The four people all had different opinions and ideas on how to best animate for the web. Currently, there are no standards.

Rachel used Greensock and Velocity js as good examples of animation libraries. Many agencies also build their own internal tools, which are not released to the public.

She also introduced the Web Animations API, describing what it is and how to use it. The people she interviewed hadn’t heard of it, or only knew about it vaguely. The Web Animations API is the result of the infamous CSS versus JavaScript animation infighting – and it is making things a lot more interesting, too. While the support isn’t great for the API at the moment, there’s hope it will become popular as browsers pick it up.

A good thing to remember: if animations are used in a high traffic area of a site, you should probably reduce the animation’s effect. It may look good when a person visits the site for the first time… Eventually though, it could become annoying to the user.

3. What it means to be a frontend operations engineer.

What is a front end operations engineer? It’s simply a shift in your focus as a developer. As a front end operations engineer, you know how to optimise a site’s performance, monitor client-side errors and, ultimately, are responsible for the life of the app once it reaches production.

A good front end developer will look out for file requests, file sizes, keep error logs (think Sentry, Newrelic, etc), check for speed and are basically the ‘gatekeepers of the application’.

Alex Sexton, from Stripe, highlighted some tools and methods every front end developer could be executing faster, therefore increasing our efficiency. Winning!

Some of the tools he mentioned include:

• Critical Npm helps to render important CSS styles for above the fold content.
• CSS Colorguard makes sure you aren’t using colours that are too similar to each other.
• SuitCSS: a pre-processor that uses a naming convention best suited to component-based UI development.

One easy tip we took away was to set up shortcuts in a text editor for code you use frequently. For example, ‘console.log()’. Although it’s a tiny piece of code, the few seconds we save each time we use a shortcut can add up to many hours over the course of a year. It might even add up to a whole day.

Alex also reminded us of the importance of ‘linting’ your code for double-ups and other inefficient practices. Elijah Manor (see below) talked about this process, too. It’s a helpful tip and a good habit to form.

4. HTML Canvas and war simulations.

One of the most fun presentations was Simon Swain’s explanation of HTML Canvas.

Simon built the Cold War game. By creating different components, each with a specific set of rules, the game simulates a war where the outcome of every game played is always different. The game explores emergent systems, the limits of JavaScript performance and some useful techniques we can all use as front end developers.

The demonstration Simon ran was pretty awesome. The game has heaps of vector graphics, high-altitude bombers, missiles, killer satellites and explosions. You can find his site here and his code is available on GitHub.

5. Get rid of stinky JavaScript.

“A code smell is a surface indication that usually corresponds to a deeper problem in the system.” –Martin Fowler

This quote really resonated with us. Elijah Manor from Ramsey Solutions talked about ‘bad-smelling’ code snippets and not only how to eliminate them from your codebase, but also protect your code against them.  What is Elijah’s definition of bad smelling code? It’s code you’ve written that feels inefficient, or code you think could be better. He gave examples ranging from junior level to senior.

Check out his presentation here, with suggested fixes for convoluted code, copy-and-pasted code, concatenated code and more.

As we mentioned in Alex Sexton’s presentation wrap-up, Elijah also talked about the importance of linting. He recommends eslint for non-complex chaining. You can use it to set up your own rules, which help combat that bad code smell.

A few other handy resources Elijah mentioned:

• JSComplexity is a great site for improving the readability and clarity of your code.
• JSCPD removes duplicate code and works in most languages. So does JSInspect.
• A good read worth checking out is Learning JavaScript Design Patterns by Addy Osmani.
• Elijah has some great demos in his CodePen account. Take a look for inspiration.
• When you’re creating templates, you don’t need a big library. Just use Lodash.
• For repetitive events, try using throttle and debounce on your functions.

***

Overall, Code 2015 was an inspiring event that had us bursting at the seams with new ideas and tools we’re itching to try out on projects.

If you attended this year and had a favourite presentation you’d like to share, add it to the comments below – we’d love to hear from you.