A bright star in the JavaScript community, Addy Osmani has skyrocketed to prominence not only for his fabulous JavaScript articles and open source contributions but for also being one of the friendliest and approachable developers around.

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.

JavaScript was going to play a large role in making this possible.

I wrote some of my first JavaScript back when Netscape Navigator was the dominant browser. Dynamic front-end development was only slowly starting to becoming more popular at the time, but the idea of being able to write something with just HTML/CSS/JS and have it work everywhere was powerful. I got hooked on to that idea and have been ever since. Some of my first creations were little things you would laugh at today - calculators, password generators, nothing too amazing.

As a language enthusiast, I liked that JavaScript was prototype-based and weakly typed, so I decided to continued learning it alongside other languages like C++. Back in the early 2000's, I tried bridging the languages by writing a little interpreter on top of SpiderMonkey (Mozilla's JavaScript engine), which let me write logic for my desktop apps in JS and define UI components using C++. It was a silly idea, but I learned a lot about JavaScript engine internals in the process.

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?).

I continued learning and using JavaScript as a freelance web developer while in college, slowly writing more complex sites and playing around with Dojo. It wasn't, however, until I got an invitation to GMail in 2006 that it occurred to me that the browser was going to be the next platform for building rich applications. JavaScript was going to play a large role in making this possible and I decided to walk away from desktop app development permanently.

Since then, I've been trying to continue learning and where I can, push the front-end community forward through my writing and contributions to open-source. JavaScript is virtually everywhere today, and it's one of the reasons why I love the language. If I want to teach one of my kids how to author JavaScript, I can just pop-open my browser DevTools and show them. No additional compilation steps needed - there's something really special about that.

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 - "First do it, then do it right, then do it better" - it's all about setting realistic goals for yourself and iterating fast as soon as you have something that just works. It won't be the most eloquently written article, nor the most beautiful code, but it's a simple baseline you can build on.

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.

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.

On the JavaScript community: we're in a good place but the one thing I wish we would collectively do is spend less time creating new frameworks and more time investing in efforts to improve existing solutions. I think it's fantastic that developers are spending time learning how to solve problems on their own - it's one of the best ways to learn new things - but if it's an experiment, make that clear so that other developers don't expect you to maintain the project. That type of thing only adds to the noise, so please keep support in mind when releasing things!.

One of the big myths out there is that it exists to replace JavaScript.

I was actually super curious to learn more about the goals Dart had when I first joined Google. One of the big myths out there is that it exists to replace JavaScript, but it turns out that this isn't quite true. Dart is targeted at those developers more familiar with Java, C++, C#, who are trying to build high-performance web apps; and so on that, have certain expectations around their tooling and language. I think that's a legitimate reason for something like Dart to exist.

As a company, both JavaScript and Dart are technologies that we believe in and invest in. We participate in TC39, working on the future of JavaScript and also continue work on V8, the fast JavaScript engine. The Chrome engineers continue to work to push the web forward with new specs like Web Components. Meanwhile, the team that originally built V8 is now building the Dart VM.

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).

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.

In fact, Blink allows us to give developers more of the tools, features and compatibility they need to get the most out of the web as a platform. Long-term it's going to let us prioritise features that will ease building the next generation of web apps and in the same way that V8 gave us a way to speed up JavaScript, I think Blink is going to let us innovate in ways that will benefit the whole platform.

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.

Reusable components.

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.

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.

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.

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.

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.

Releasing my first book, Learning JavaScript Design Patterns (with O'Reilly) was probably the accomplishment that's given me the greatest satisfaction. It was my largest writing project, and I made the decision for it to be completely open-source from the start - a call I'll never regret. Making educational material available to anyone, anywhere whether they can afford it has the potential for a great deal of both good.

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!