His blog is a treasture trove of front-end knowledge and well-worth the visit. In this post, we'll chat with Addy about how he got his feet wet in JS and bring up some tough topics relating to his work in developer relations at Google.
I spent a lot of time building small hobby sites, but when I was in my last year at high-school, I decided to really get stuck into the world of browser internals. I wrote a lightweight rendering engine, basic HTML 4.01/CSS 2.1 parsers and wrapped all of these parts into my own little browser. The project was a nightmare to get working reliably, in part due to how lax web developers were with standards-compliance in their pages - it's funny being on the other side of the fence now! The larger challenges were spec-compliance, rendering large tables and maintaining performance, whilst loading up video plugins (anyone remember good ol' ActiveX?).
Q You produce a LOT of content; I'm sure people are wondering how you do it. Can you share your secrets for not only generating this content, but actually understanding what you're writing about?
If you leap into any non-trivial topic with that mindset, it's necessary to break it down into simple, more easily digestible steps
The secret is that I consider myself to be somewhat stupid. Really. If you leap into any non-trivial topic with that mindset, it's necessary to break it down into simple, more easily digestible steps in order for it to make any semblance of sense.
It's this perspective that I think makes my writing feel accessible - I try to make sense of those concepts or tools that can initially feel quite daunting to the average developer. It's important to be able to apply this to articles and especially documentation. So, keep it simple. This helps make articles more focused. How do I generate so much content whilst understanding the material?. Well, I make understanding a prerequisite.
First do it, then do it right, then do it better.
Einstein has this great quote: "If you can't explain it simply, you don't understand it well enough" and it's true. You cannot teach about or claim a framework, tool or best practice, unless you've actually taken the time to use it yourself. Finding this time is easier in my current role, but back in my days as a 9-5 engineer, I would spend time over breakfast and lunch actively using what I would later write about on the weekend.
Finding time to get everything done is always a challenge. For the past few years, I have this mantra that I try to apply to every task - "
You can then share this first iteration with your peers and get a feel for whether you're going in the right direction or the idea is worth pursuing. To me, that makes a great deal more sense than spending weeks on a draft or prototype before asking for input.
Q You were at AOL before. What are the differences in the culture there versus Google, and how has it impacted your views on software development?
There's something special about being a part of a company with such high standards.
Both AOL and Google are companies with terrific engineering teams, and any of my reflections of culture aren't about any specific groups, more a general observation.
The engineering culture at Google is such that we care a lot about polish and shipping things when we feel they're just right. There's something special about being a part of a company with such high standards.
At AOL, I was proud of any of the products or applications we completed, but due to the fast-paced nature of business and competition, delaying launches or releases for polish wasn't always feasible. I think that's a reality for many businesses, despite any desire they may have to change that culture.
When it is possible to delay releases to, as Google say, get it "right" I think it can make a world of difference to your users first impressions of your product.
I'm pleased with the direction TC39 have been taking over the past few years.
I'm pleased with the direction TC39 have been taking over the past few years, which in part has been helped with the involvement of Rick Waldron and Yehuda Katz from the jQuery project. They've paid close attention to the patterns and libraries developers have been heavily relying on, and investigating how these could be better solved using platform primitives. I won't comment on ES6 specifically, but I'm looking forward to seeing modules, classes, 'let' and
Object.observe() available more widely.
Back to your original question - I believe forking WebKit was a lot more to do with the divergence of the multi-process architecture between both projects than trying to embed Dart into Chrome. Dart's a separate open-source project with it's own goals and you can still get Dartium today (the build of Chromium using the Dart VM).
Q Now that Blink is in the works, how do you think this help the web, and what do you feel are some new challenges that web developers will face with yet another rendering engine to think about?
When I first heard the news about Blink, I was concerned that we'd now have another browser to support.
The reality, however, is that there have already been so many differences between the various WebKit ports that this isn't going to negatively impact how you develop and test.
Q Google is in an interesting position, where they're heavily vested in both native apps (Android) and web experiences. As you do developer relations at Google, how do you balance the business directives and priorities for both ecosystems?
We get caught up in the debate about native vs. web quite often these days, but don't talk as much about the need to put our users first. They're the focus. There are many cases where you can deliver a compelling experience for the web on desktop and mobile and it'll work fantastic. That said, there are others, where either the platform or mobile browsers still need work. As a business, you often need to make a call on what makes the most sense for your users. I think that, at present, it makes a great deal of sense to offer developers the best platforms possible for making a call on native vs web, and that's what we do, via Android and Chrome for Mobile.
Q Stripping away specific web technologies, what should developers be thinking about at a higher level when it comes to the future of the web?
Reusable components. Traditionally, a lot of us have developed applications quite vertically, spreading a single concept (whether it be logic or UI) across a few different parts of the project. Not only does this make it harder to maintain the idea but it also makes it difficult to extract and reuse the idea in future applications without a great deal of effort. It also decreases our chances of being able to share the component with others.
Without referring to specific technologies, we're working on making it easier to define and package up components on the web platform side, and now is a great time to start thinking about how your own apps might be written, if they were broken down into specific components.
Q Staying on this track, what are the key technologies, end-to-end, that you feel are making the most impact to pushing the web forward? Why?
The front-end is seeing a revolution in tooling at the moment with an increasing number of developers starting to use Grunt and explore workflow tools around it like Yeoman. Developers are paying more attention to what they can automate and I think that this will help facilitate more time spending building better apps and less time on those manual processes in between.
Going back to the components idea, I think that between web components and front-end package management we have a huge opportunity to really shift the way we develop for the web. AngularJS (and Angular directives) have done a great job of re-introducing the idea of reusable blocks of functionality and things are really looking up on the package management side of things, through Bower.
Writing an app with lists you want to make sortable? Great. A few keystrokes at the command-line and you've got that. Want to make the items in that list persist when you're offline? No problem. A few more keystrokes and you're using a package another developer once had to write to get that capability. Want to turn your list into a reusable component anyone else can use? That's easy. That's the future we're working towards.
Q Yeoman is your new baby. Why did you feel the need to spin up such an ambitious effort when existing projects seemed to be filling the need?
We're fortunate to have a wealth of helpful tools at our disposal on the front-end these days â€“ tools that save us time and make our lives just a little bit easier. Abstractions like Sass and CoffeeScript, frameworks like Twitter Bootstrap, module loaders like RequireJS, a never-ending list of MVC and unit testing librariesâ€¦some would say we're spoiled for choice and it's interesting seeing how long it can take you to get a project started up.
Are you still manually refreshing your browser whenever you make a change to your app?
As much as these tools work exceptionally well on their own, it can be a tedious process getting them to work together, especially if you have to put together a workflow and build process where they all compile and get optimized succinctly. Even if you do manage to get a solid build process in place, you're often left having to spend a great deal of time writing out the boilerplate code for your application.
Even then, you have to ask yourself how well this fits in with your day to day workflow. There are several little steps we repetitively do while developing which can more easily be handed off to tooling. Are you still manually refreshing your browser whenever you make a change to your app to preview how they look? Still trying to figure out whether you're using the latest versions of all your dependencies? Wondering if there was just something that let you get on with coding and forget about a lot of the grunt work?
We were too, which is why we started looking at whether we could give developers a solution to many of these common problems. We tried solving them in a free, open-source project we recently released called Yeoman. Yeoman's official tagline is that we're a â€œrobust and opinionated client-side stack, comprised of tools and frameworks that can help developers quickly build compelling web applicationsâ€.
Practically, we're a series of tools and tasks that help you achieve automate some of the more tedious tasks in front-end development. We're composed of yo (the scaffolding tool), grunt (the build tool) and bower (for package management).
If you find that you're still writing boilerplate code for your application, manually managing the dependencies for your apps or putting together your own build system to work with the tools you love, you might find Yeoman a nice way to save yourself some headache.
Q When you launched Yeoman, Windows wasn't initially supported. What were the challenges you faced with supporting it, and how can the Windows developer community help in these circumstances?
The Windows developer community could really help us here.
Creating a command-line tool that works well cross-platform can be a delicate dance. One of the initial challenges with Windows support was that a lot of our team were used to using a *nix system and having access to homebrew/apt-get. We weren't however as well versed in using PowerShell or Chocolatey (the PowerShell-based Windows equivalent to apt-get) and needed time to understand how well these solutions compared to the tools we had available elsewhere.
It then took time to find (or get) all of the packages we required up on Chocolately as we needed git, phantoms, opting and many others. The situation there has greatly improved since our first release and Windows is now officially supported with Yeoman using the instructions on our homepage.
The Windows developer community could really help us here by advocating for more widespread adoption of tools like Chocolately and helping us reach parity with tools like apt-get. Other than that they've been fantastic and we've really appreciated the help and support the Windows developer community have offered us throughout our road to compatibility.
I've got to give a call out to Sindre Sorhus, Mickael Daniels and Paul Irish, all of whom really helped improve our Windows efforts in the early days.
Q Along those lines, I have a question based on totally selfish-motivation, since I use Windows. How can *nix and Windows developers collaborate more effectively so that everyone can contribute?
At the moment, there are a lot of (fantastic) development tools being written which are not just *nix, but Mac specific because making them cross-platform has it's own development costs and overhead. I would love to see more open-discussion and development of tools that can work everywhere, but this can't be done without the help of users.
If there's a tool you want for Windows that you just see on Mac, please be vocal about it - even better, submit a pull request!
Try to find out what it would take to bring it to Windows (and elsewhere) and who knows? Maybe the combined efforts of multiple communities would be enough to make something happen.
Q You've written excellent posts, published books and contributed to top OSS projects, like jQuery and Yeoman. Of all your professional accomplishments, is there one thing that really stands out as a proud moment?
It also has the potential to increase your book's impact, so if you're an author - please consider doing it. You won't regret it!
Thanks so much to Addy for sitting down with it. If you have any of your own questions for him, I'm sure he won't mind answering below in the comments!