#StopWarInUkraine Save the children

The awards of design, creativity and innovation on the internet

Magazine for designers and web developers
01 Collect

Interview with Addy Osmani, Developer Programs Engineer at Google

Article by Awwwards in Design & Illustration -

Addy Osmani tells us what it’s like to create the future of the web.

Martha went to meet the developer relations wizard at Google HQ in London.

Personal site | @addyosmani | Google+ Profile

Question So, Google. How did you end up here?

In the interviews, I was asked "If you had six oranges in one hand and seven in another, what would you have?". I answered "very large hands". That’s a terrible joke.

What I’m passionate about is helping people be as productive as possible on the front-end - a lot of that is about getting the tooling right. I’ve tried to do my part to help with this by hacking on open-source projects, articles, and books over the years and I guess the Chrome team at Google thought I could have more impact if I could focus on this type of thing full time.

  • They called one day asking if I’d like to interview and I’ve never looked back. It’s been a really fun journey. I feel we’re still not at that stage where it’s delightful and easy for developers to create sites and apps but I think it’s achievable. We’re very slowly getting there.

    Question Is it how you imagined when you started?

    That and more. Working at Google sometimes feels like a rollercoaster ride. It’s fun and not always easy, but you wouldn’t want it to be either. You get to focus on challenges that not only have the possibility to impact on a lot of people, but they're genuinely fascinating.

    I was working as a full-time JavaScript developer before I joined and the work involved is a little different. In my specific role, whereas before I would be working on webapps everyday, my time is now spent analyzing the workflow of other front-end developers and coming up with either the tooling or documentation that can help them make that process a little easier.

    We want to help make front-end development fun and developers productive.

  • Question What's your role on Chrome Team?

    I work in Chrome Developer Relations with a focus on engineering tools and technical writing. Some of my work includes evangelism for the Chrome DevTools and writing our official documentation but I also work on front-end tools like Yeoman - a scaffolding tool for speeding up the creation of web sites and web apps.

    Whereas before, if you wanted to start a new app, you had to go on the web, find a boilerplate, figure out how to structure it, how it would look, and all that stuff, and then figure out a build process to actually push it to production. We try to automate a lot of that using a few different tools. We take care of scaffolding.

    A big focus for our team this year is on mobile, so lately I’ve also been spending a lot of time trying out a few different mobile web development workflows to discover what the pain points are that we can help with. There’s a lot of work to be done there.

    Developers want to be able to offer compelling experiences that are as good as what you can deliver with a native application, but that’s not always easy. We’ve been looking at what can be done to improve that on the platform side but also in general education of best practices.

  • Yeoman, modern workflows for modern webapps

    Question Can you tell me a bit more about Yeoman?

    Of course. Yeoman's work flow is comprised of three tools that help automate common front-end tasks: Yo is for scaffolding, Grunt is for building and Bower is for package management.

    With Yo, you want to scaffold out something new, whether it's a site or an application, we give you some scaffolding to do that. So if you're working on a new Backbone application, you don't have to do much more to start off your project than just go to the command line and say "Yo, I want to work on a new Backbone app". It will ask you a bunch of questions and then it'll go scaffold out your initial application for you.

    If you then want to be able to create a new Backbone model, collection or view you can also just as Yo to do that for you and it will. We're really, really big on the idea of unit testing, so we also scaffold out unit tests for people. What that means is that you have a fairly quick baseline that you can go and start building on.

    We try to minimize the amount of boilerplate you have to worry about when you're working on coding. We have generators for around 130 different types of projects right now, ranging from AngularJS through to Adobe’s TopCoat framework.

    The types of projects Yeoman scaffolds out assume you’ll want to use Grunt (an awesome JavaScript task runner) for handling many of your workflow tasks. What we do there is try to prescribe tasks that are going to help you during development. So, let’s say you want to use CoffeeScript in your project - great. We can include a Grunt task automatically that will compile your CoffeeScript files at build time.

    To help you manage the different dependencies you might want to use in your app, whether they be jQuery or a plugin to achieve something specific, we have first-class support for Bower. That means in just a few keystrokes at the command-line you can install any dependencies for a project or update them in one go. That’s a lot easier than having to manually copy them back and forth through a Downloads directory.

    We think all these tools have the potential to make modern front-end development easier.

    Question That’s exciting! Can you tell me a little about what’s new in the Chrome Developer Tools?

    Sure. At Google I/O, Paul Irish announced a few features (such as Workspaces) to enable developers to use us as an in-browser code editor. That's exciting. Developers often spend a lot of time going back and forth between their browser and text-editor when they're trying to find and fix bugs or make small tweaks, so we thought we'd try to streamline that process. Workspaces let you map local file systems to the current page. We also added the ability to work with and debug Sass.

    Normally you have this problem of debugging a page where you want to be able to author in Sass and make tweaks in the DevTools Elements pane, but you can't because your changes are saved to your .css files rather than your .scss source. That's no longer a problem. You can now see the original local of a style in your scss and edit it. We live link to macros..variables..lots of things. We can even reload CSS upon Sass save if the daemon is running.

    You also no longer need to use the Android SDK if you want to debug Chrome for Android. That's huge. Just using a small Chrome extension called ADBPlugin you can go to chrome://inspect and it'll show you pages on any connected devices. You get a lot of power with that - paint profiling tools to help you improve the rendering performance of your page, Timeline, lots of things.

    All of these features are now available in Chrome Canary so we hope people will try them out and let us know how they get on.

    Question What do you think the future holds for JavaScript?

    I'm really looking forward to JavaScript getting proper modules as well as generators.

    Generators are going to help us do all sorts of things including code suspension. Think of a generator as an iterator (or a sequence of values of some sort). The interface to that generator might just be an iterator that you call next() on until it's completely run out of values. Each time your generator is called, the value being yielded becomes the next one in the sequence. When you instantiate a generator, you have this function whose execution you control, so you can start and stop it. When it stops, you decide when it restarts which is really amazing.

    On the module front, we’ve had numerous ways to define modules in JavaScript for the past few years (the module pattern, AMD, CommonJS) but nothing implicitly inside the language. ES6 modules will change that byl hopefully giving us a way of universally declaring modules regardless of context. They'll work in the browser, on the server, everywhere.

    I wrote an article about a few new things coming to JavaScript that I’m excited about for anyone interested in hearing more on this topic.

    Question What about the future of the front-end? What’s the next big thing we’re going to see there?

    I see the future of the front-end as being heavily crafted around the idea of reusable components.

    When beginners start using things like jQuery, they love the idea of plugins and being able to just go and download something, stick it in their page and get a lightbox, for example. But how many times have you actually ended up having to write your own custom bits and pieces for your pages across different projects? I know, at least when I was freelancing many years ago, I ended up having to write lightboxes probably ten or twenty times, and I know that other developers have had to do the same thing. The same could be said of things like carousels and other widgets.

    What if you had a carousel tag to define a carousel, and all you had to put inside that was image tags and it just worked? It's a much simpler way of injecting and using that component. You just have to say: “here are my images, you take care of the rest”. If you're working on a lightbox, maybe you just add a single lightbox tag and specify your image, and that's it.

    With reusable components, the idea is that just a few people people write the base for a carousel really well, and then everybody else uses that base and builds on top of it. So we reduce the amount of code people have to write. Reusable code is also about doing one thing and doing it well, so you can stick it on any page and it just works. So if you want to create an application, rather than having to build out all these components yourself, you can actually go to a library and grab the widgets you need, stick them in your page and get set up much more quickly.

    Practically speaking, on the web platform side, the way we're going to achieve that is using Web Components. They let you leverage your existing knowledge of HTML, CSS and JavaScript to build components you can easily reuse anywhere. I'm excited about web components because they let you extend the vocabulary of HTML (through Custom Elements), scope styles and logic (using Shadow DOM), get access to native data-bindings (through Object.observe) and much more. Eric Bidelman on our team has been covering the fundamentals around these concepts really well over on HTML5Rocks.com. You should check them out.

    Also check out Polymer, a library for using these concepts in the browsers of today using polyfills. Alex Komoroske and Scott Miles have put some terrific work into it and it’s a good project to follow for a glimpse into where front-end development is going in the next few years.

    Question For somebody starting out as a front-end developer, what languages, frameworks or libraries would you recommend?

    That’s a hard one, but in general always use the right tool for the right job.

    Although I’ve written books about it, I still consider myself a humble student of the front-end, and I think everyone should consider themselves that way. If you have a good grasp of the fundamentals, even if you're coming from a jQuery background, you can always do things to improve your knowledge of JavaScript and CSS. I would try to first of all do that: spend time actually writing experiments and writing code. Reading books is fantastic, it always helps you soak up more knowledge, but you actually have to be going out there and doing in order to properly understand these concepts. Get a good grasp of the fundamentals.

    Once that's done, when it comes to frameworks, I always say use the right tool for the right job. Personally, I use things like Backbone and Angular quite heavily in my own apps. I think those are two good choices, but there's also Ember and Knockout and so on. I and my buddy Sindre Sorhus created this project a while back, called TodoMVC


    We've got 50 or 60 different frameworks available, and if you want to get a flavor of what that might look like if you're implementing an app, TodoMVC has got every single application. It's a To-do app, but it's implemented in every single different framework, so you can easily go in and compare what code using that framework might look like between two different things. You can say, "OK, well I've already played around with Backbone and I'm interested in Angular".

    You can go and compare what the app written with Backbone looks like compared with Angular, and you can get a feel for the different syntax and concepts. It's not supposed to convince you to use something, but it's supposed to give you a slightly better feel for what it might be like to use, so you can then go and do your own research and hopefully make a good, balanced decision.

    The whole project has been greatly helped by our recent additions to the team, Stephen Sawchuck and Pascal Hartig so a big shout-out to them.

  • TasteJS, a better JavaScript learning experience.

    Question I hear TasteJS is your next big project. What can you tell me about it? Where did that name come from?

    That’s right. Our next big project is called TasteJS. TodoMVC is great, but I want to do better than that. We're working on a completely new, more complex application, with a bunch of different framework authors. You usually have to go and implement things, like authentication, login or CRUD with your backend and things like animation between different views in your page. So when you're transitioning from one part of your page to another, sometimes you need to be able to have animations in there. There's a bunch of other stuff that people have to start thinking about when their applications become non-trivial. We're hoping that project will give them a slightly better version of Todo MVC, better tools for deciding what framework to use.

    You were asking about the name of the project. TodoMVC is a name I came up with on a bus. The idea behind Taste is that I want people to get a taste of JavaScript. I'm taking the idea further. Over the past year I've started to see more and more people outside the JavaScript community going and implementing apps. People in the PHP community, the Ruby community and the .net community. That's been really interesting because the concept of being able to compare different programming languages can be applied here. It's the same app, why don't you look at different ways of doing this in different languages?

    We're also exploring some different sub-projects like Taste Lang. The idea there is "You want to learn a new language: here's a language you probably already know, and here's a new one". Then you can go and compare how we built this app using these two different things. We try to encourage commenting and good practices to help people get started. I generally keep myself way too busy!

    Question So once developers have tried out the different frameworks using TasteJS, which ones do you predict more of them will start to use in the near future?

    I love Backbone. I've written a book on it called ‘Developing Backbone.js Applications’ and I’ve built lots of relatively complex apps with it. But there are certainly cases where you may want something a little more opinionated. Opinionated software tries to make a lot of decisions for you so that you don't have to make them yourself. Something like Backbone is heavily un-opinionated. It tries to give you a good baseline for developing something, but it leaves a lot of the decisions about how you want to actually architect and build your application up to you.

    There are times when you need and want that and others when you don’t.

    With some slightly newer solutions like Angular and Ember, they make more decisions for you. One of the practical benefits of that is that in some cases you end up writing less code. They're encouraging you to do things in a specific way, so they can take care of some of that boilerplate behind the scenes so you don't have to worry about it. I'm seeing more people starting to take a look at Angular and Ember and so on.

    In the Backbone space, more and more people are taking a look at Marionette.js by Derick Bailey. This is something I showed people during my workshop at Future of Web Design, and they loved it. Marionette tries to give people more of those opinions that are missing from Backbone. It's like an extension- it's an essential framework that lives on top of Backbone. I think developers love the idea of having options for opinionated frameworks, and an increasing number of good ones are coming out.

    Question What do you see in the future for cross-device applications?

    I feel like the mobile web needs to be able to offer parity with the experiences you can get with a native application. Those experiences are generally buttery smooth and almost always hit 60fps, but this can’t be said about many mobile web experiences. We need to change that but there are lots of other problems that we need to solve.

    It's hard, because if you take a look at the mobile landscape these days, many of the sites that you access will automatically navigate you to a dedicated mobile site. The problem with a dedicated mobile site is that if you come to a site from a search, there is often a break in the search experience.

    Say you’re searching for some new Nike shoes on Google, and you click through on the first link. In a lot of cases when they redirect you to the mobile version they don't take into account what you were actually looking for. They'll just navigate you to their home page rather than the URL you wanted or even worse, suggest you download their native app to continue. That sucks when all you wanted to do was buy those shoes you were looking for.

    Another challenge is that sometimes developers feel they have to offer completely scaled down versions of their sites and apps on mobile down to poor performance. This is because your network, rendering and logic processing performance can vary drastically between desktop and mobile. They’re very rarely the same if you’re doing anything intensive.

    We're working with slower processors and GPUs, limited battery life, all sorts of constraints. Your mobile web application has to take that into account. The challenge is that we want to be able to create really beautiful, compelling experiences on the web, but you always have to keep performance in mind. Shipping a desktop experience to mobile is fine, but if people can't interact with it and it's sluggish and slow, they're not going to want to use it. They'll either close their browser or navigate to a competitor, and that's not what you want.

    So I would say try to spend some time optimizing your mobile web application so that it performs well on those devices your users are using. There's tremendous benefit to doing that, it can really impact your user experience and user engagement.

    For anyone interested in learning more about rendering performance, Paul Lewis and I just recently wrote up a case study on how Pinterest found and fixed their issues here that might be of interest.

    Question Do you think that will take a while?

    I think it is going to take a while. Everybody has deadlines, and we're adding another thing into your bucket of stuff to get done when we talk about performance optimization and better mobile experiences. We need to convince not just developers, but also the managers and clients who are defining their timeframes that this is worth investing in. It's going to take some time, but we’ll get there.

    Question You've contributed to a lot of open-source projects. What's the most interesting one you've been involved with?

    I would say the most interesting one has probably been Yeoman. The reason for that is that it was actually my first really big project where I spent a lot of time in Node. It is entirely event-driven and non-blocking meaning you basically say 'go do this, when something happens use this handler for it'. It’s a pleasure getting to work in a JavaScript environment without needing to worry about cross-browser inconsistencies. Yeoman gave me that opportunity.

    I learned so much during the process of helping create it, and now I'm just completely hooked. I get a lot of satisfaction out of seeing the project grow and that more developers are starting to use it is terrifically exciting.

  • Google Dart

    Question How do you think Dart is going to evolve?

    I think Dart is really interesting. Google actually invest a lot of time in improving the web platform through efforts like V8. We're also exploring ways that developers coming from other backgrounds might be able to build better apps, and that's where Dart helps. So if you're coming from a C# or Java background, for example, moving into Javascript might not be the easiest thing for you, because you already have a lot of assumptions about the type of tooling that's going to be available and the type of editors that are going to be available. You might have some expectations about the language that Javascript doesn't necessarily deliver on, mostly because it has its own way of doing things.

    Dart offers people a fairly decent solution to that. I've seen a lot of developers who were coming from those backgrounds building some really complex apps using Dart, and I think it's a really good solution for that particular use case. In terms of how it will evolve, the team there are constantly working on improving Dart's speed, and how easy it is to use. It might evolve around helping people using web components, and some of the concepts I discussed earlier, in the Dart world. I see these efforts being fairly parallel. Us front-enders and JavaScripters and going to continue using what we use and we're going to rely on V8 and things will be awesome. The folks that are using Dart are going to continue using that and will probably try and make sure they've got the best tools and capabilities possible at both ends.

    Question In your opinion, what is the biggest news that was announced at Google I/O?

    Web Components! I’ve already talked about components, but I was excited about a few other announcements too. One of my other favorite parts was the idea of auto sign-in across all your devices. A really great demo was shown of you trying to create a new account or log in to a web application on your desktop. As soon as you tried logging in with Google+, it gave you the option to go and automatically install the app for that site on your device.

    So it detected that I'd previously signed in using my Nexus phone, and with just one click I was able to go and install the app on my phone without even touching it. It was really neat. And when I go back to my device, I'm actually able to click on the icon for the app, and it automatically signs me in using the details it got from the desktop version. It's synced everything together. I think that's really amazing, because I find myself spending a lot of time these days re-typing my login details on my phone.

  • Martha with Addy Osmani at Google London

    Question And finally...how do you keep up with all the developments on the front-end?

    Over the past few years I've moved away from relying on things like RSS to using Google+ circles and Twitter lists for keeping track of news in the industry. I've found that really effective.

    There are maybe 40 or 50 people I find to generally post really good content (relative to my interests). They're not just aware of the latest trends, but they're also working on things themselves so they have pretty good insights. I have lists for people that work in the JavaScript community, people that contribute to open-source, people who are generally good at web development and CSS and so on. I use lists and circles pretty heavily to just narrow down the noise and keep up-to-date on things.

    There have also been some really great efforts in the past few years to bring people newsletters in the community. Whenever you tell someone "I subscribe to an e-mail newsletter" they're like, "What is this, 1995?" But the reality is that they're actually pretty good. If they're curated by the right people and they care about quality, they're really great.

    Things like JavaScript Weekly and HTML5 Weekly by Peter Cooper are really great assets, because at the end of the week there are generally at least one or two things that I've missed and still blow me away. I love using newsletters; it's a nice digestible form you get once a week, and it's not too much of a time investment.

    webplatformdaily.org is another resource that only recently started getting published. There's new news on there pretty much every day. It captures the bleeding edge of the web, what the most interesting developers have been doing, new specs... Lots of things to do with the platform that you otherwise have to know people in the industry in order to keep up-to-date. I've found that really helpful for keeping on top of specs. These resources that narrow down information for you have really made it easier. I’d recommend people try to do something similar.

    Finally, definitely checkout Front-end Rescue. It’s a fantastic site that gives you all sorts of resources and tips for staying up to date on the front-end. I highly recommend it.