Interview: Google’s Addy Osmani discuss tools & workflows for developers

We had the chance to meet and interview a lot of very interesting Googlers during the last Google I/O. Today, it’s Addy Osmani ! We’ll release those interviews (mostly in English) in the upcoming days. This one is done by SFEIR’s Wassim Chegham, who got the chance to talk with Addy Osmani about his work on tools for developers.

Wassim Chegham: Hi Addy, could you introduce yourself?

Addy Osmani : Sure, my name is Addy Osmani. I work on open web tooling with the Chrome team at Google. Some of the projects I’m currently focused on are Progressive Web Apps, Service Worker libraries and in general, tools that help web devs stay productive. I want folks to be able to build kick-ass web apps, regardless of whether they prefer writing them with React or Web Components.

Can you tell us a little bit about the modern tooling?

Addy Osmani : We’re at a fascinating cross-roads with tooling in the JavaScript community. We’re trying to balance productivity with tooling fatigue. It’s a fun problem. It’s not uncommon for intermediate to advanced developers to rely on a transpiler to let them use next-level EcmaScript features. Or filling in the gaps in CSS with something like PostCSS or scoping with CSS Modules. These types of explorations enable power in our workflows while we wait for the Web Platform to catch-up. At the same time, it’s important to remember that both libraries and tools are there to inform standards bodies about what we’re missing. Ultimately, those tools should seek to no longer exist – especially if we can get their core value baked in. There’s so much interesting work going on to evolve what you get for free.
Like, take Shadow DOM or CSS variables or the ability to custom paint with Houdini. These efforts came out of developers telling browser vendors that they needed a built-in way to solve hard problems. Are any of these pieces of machinery perfect? Well, no. But each step we take towards baking in the power that tools give you, that means one less dependency and one less tool you need to have installed. One less thing you don’t have to worry about. Imagine how much power we’ll have when you can mostly use ES2015 (with Modules and a loader) without the need for a transpiler. That’s going to be HUGE !

As developers, we see so many tooling, also some complicated workflows. Can you tell us a bit about your own workflow?

Addy Osmani : I spend most of my time crying in a corner to be honest !

…like most of us [laughs]

Addy Osmani : Exactly! I think the most frustrating thing for me today is, you go to start a project or you go to checkout a buddy’s project and you need to git clone and npm install, you can go and bake a cake while waiting for everything to be ready. And then you spend the next 3 to 4 days debugging, webpack or browserify instead of actually working on the logic for your app. I now feel 90% of my time is debugging my build tools and 10% of it is writing code. Which is crazy! I think, a lot of the problems that we’re trying to use tooling for are important, like code splitting is something that is getting popularity at the moment. People will use Rollup and other tools for that type of thing. At the same time, I think we’ve gone to this place where if you’re starting a new project, often people will use a boilerplate someone else has put together and maybe it’ll come with like 50 000 different tools. And maybe you don’t need all of those, right? If you’re working on a new prototype for something, whether it’s using React or Ember or Angular or Polymer, whatever. Maybe you don’t need all of that tooling to start off with. Maybe it’s OK to just be able to open your browser, hit refresh and just keep on working on code. And then introduce tools into your workflow later on, when it makes sense. Because a lot of the time, we try to solve problems we don’t necessarily have in advance. It’s like “I can’t work on this button, I need hot reloading first of all. I can’t work on this thing, I need browser sync! I need 12 different transpilation steps…”

Is this why you made Yeoman?

Addy Osmani : Yeoman was born out of our frustration with just having an opinionated way to develop for the web. One workflow we could suggest to folks that we thought worked well together end to end. A few years ago, especially when you were trying to put together a build process with live-reload, web optimisations and just a sane boilerplate – it was hard to find a setup that did this well. Yeoman tried to solve that problem. As it turns out, it spawned this huge ecosystem of custom generators – folks from all parts of the web development community sharing their workflows and iterating together on making them better. Today Yeoman’s used by a lot of teams to get started at their agency or company with their best practices or their preferred tools and workflows baked in from the start. Folks like Microsoft, IBM and Google are using it pretty happily. I think that’s where it’s core value lies today – in helping teams get started on projects with similar setups more quickly.

That’s exactly what we’ve done. We wrote our own generators for Yeoman. We included our internal best practices and standards.

Addy Osmani : Cool! I’m glad to hear that.

Speaking about workflows and the tools you use, can you tell us what is, for you, the best tool ever? The one you can’t live without?

Addy Osmani : I could give you an obvious answer and say the browser. haha. I would say the one tool I honestly couldn’t do without is the browser Developer Tools (Chrome DevTools most of the time). I open that up more than any single tool in my daily workflow. I use the Element panel when I’m iterating on a design and for inspecting, I use the Memory profiling and Timeline tools when I need to solve performance. And I know this year, we’re announcing a lot of new tooling in Developer Tools that help with Service Worker debugging and PWA debugging. I think having something with low friction is good, you don’t have to setup DevTools, you just to open it up, it’s right there. The low friction of that is kind of powerful.

What is your opinion about the JavaScript Fatigue?

Addy Osmani : I think it’s fascinating that if you talk to any JavaScript person and you say “I’ve spent the last couple of weeks debugging my build step”, everyone knows exactly what you’re talking about. I think because building complex JavaScript apps is still in a state of evolving, we’re still trying to figure out the best practices and how can tools help us automate those best practices. But we haven’t found that balance yet. If I’m starting building a modern web app today, I don’t really need to start off with using babel. Most modern JavaScript engines support over 90% of ES6. In my project I’m able to run classes and promises…

… but we don’t have module supports…

Addy Osmani : We don’t have module support just yet. Glad you caught that. So, module support is being prototyped in a lot of the major engines at the moment. I think the biggest missing piece even if modules were to ship today is module loader. You need the ability to properly load modules. I can’t guess when that’s going to ship but I would say a year or two from now…


How do you see the future of developers workflows?

Addy Osmani : Let’s rediscover simplicity. In the future, I want us to be able to spend more time working on the actual code for our apps than we do debugging our tools. Our workflows need to get smarter whilst rediscovering simplicity. As much as we joke about it, installing dependencies for your project shouldn’t take as long they do right now. It shouldn’t be as complex as it sometimes feels to debug something like WebPack. I think frameworks and libraries are going to be pivotal in bringing about this sea of change. A lot of them are investing in opinionated CLIs as a core part of their developer experience. Being able to help swallow some of today’s complexity and helping folks get more productive in the process would be amazing.

I was about to ask you about the CLIs. They usually abstract things for the developer. Do you think this is a good approach?

Addy Osmani : I recently started using NWB for React and Angular CLI for a few projects and found they really help get you on a well-lit path sooner. I’ve been a really big fan of Ember CLI for a while. It’s the developer experience around it. I think it’s just “just right”. They do just about enough work for you. It’s not doing too much magic. It’s scaffolding out and giving you just about the right level of tooling, I’d say. That also comes with its own cost. With Yeoman…I actually worked on Yeoman before I started working on boilerplate projects and we discovered: if your first step for a beginner is to npm install a tool, rather than actually going write code, maybe that’s not the best thing because sometimes just giving them a ZIP download of a template that they can go and just customize will get them running more quickly and you can introduce the tooling to their workflow when they’re ready. So, I think we’re still trying to figure out that balance of at what point is the CLI valuable, what point is the boilerplate valuable too.

I feel like we’re slowly getting to the right point, it’s just going to take time to understand what the sweet spot is.

Well said Addy. Thank you for taking the time to answer our questions.

Thanks to you.

Vous aimerez aussi...