[Nick Pettit]: Paul, Thanks so much for being here.
I really appreciate you coming out. >>[Paul Irish]: No problem.
[Nick Pettit]: So, for people who don't know who you are,
how would you describe yourself?
Who are you, and what do you do?
[Paul Irish]: I am a developer advocate
on the Chrome team right now,
and so I kind of focus on--that encompasses a lot,
but I focus on everything I can do
to make it better to create compelling content for the web.
We've got a lot of great content inside of Chrome.
I wanted to help educate people about that,
help people understand how to use things like
the Chrome DevTools better.
I also come with a big history of front-end development
and open-source projects that I work on
to help developers
learn what they need to know
to do better front-end development,
make better websites and web apps.
[Nick Pettit]: That's awesome.
You're involved in a million different projects.
You're doing Modernizr, HTML5 Boilerplate,
which I use all the time by the way.
You've been on the jQuery team,
and you've made all these really handy tools for
front-end devs.
This might seem obvious, but
what's the motivation for working on all these different things?
[Paul Irish]: I think part of it
is basically that I feel a lot of satisfaction
helping other people, and so part of it is just that.
Also, the other thing--I think this is actually another part that's happened--
is that I have a really bad memory,
and what that translates into is
if I don't write something down, I'll forget it.
So, this happened in front-end development where you learn this technique
of using media queries or the viewport meta,
and you need to keep track of this
because this is the right way to do it
in this situation.
So, that eventually translated into what became
the HTML5 Boilerplate project,
where a lot of best practices were distributed
all over on blogs and books and things like that,
and I was just like we need to get this together
just to keep track of it;
so I can keep track of it and remember to use it on the next project.
So, that's helped me a lot and has helped other people.
The other thing for me that really drives me
is that I want the web to be
where people build great things.
I'm just really excited about anything that I can do
to help make the web be a stronger platform
for making great, really cool stuff.
[Nick Pettit]: So, you're very diligent
in tracking all of these different things?
[Paul Irish]: Because I can.
[Nick Pettit]: How do you balance your time working on all those different projects?
[Paul Irish]: I don't have a good mechanism
for time management right now.
I use a really cool tool called, 'WorkFlowy,'
which is like a super-enhanced
to-do method list app. It's really cool.
I set up priorities for myself
on a quarterly basis
and try and get them.
I think that's actually quite important,
which is to have a longer-term view of what you want
to attack, because it's so easy on a daily basis
to be totally distracted and
just be like, "I want to play with this new thing
and get it done. Oh, wow, something,"
and then you totally forget that you have this much larger,
higher-impact thing that you should be doing.
So, it's hard, and I'm still really bad at time management,
but I'm working on it.
[Nick Pettit]: I know what you mean.
With being involved with so many different projects,
I guess you kind of have to keep a big-picture view
as to what all those things are working towards.
[Paul Irish]: Yep, and what the priorities are. Yeah.
[Nick Pettit]: Cool. So, before we continue, I want to back way up
and just get some of your history.
Where did you grow up and what were you into?
[Paul Irish]: Sure. I'm from Western Massachusetts and Connecticut.
So, I'm from New England where we say,
'wicked,' 'It's wicked cool.'
[Nick Pettit]: Wicked.
[Paul Irish]: I was into music.
I was in the marching band; I played the tuba.
I was into drama. So, I was a band and drama kid in high school.
I was really into music and, in fact,
the first time that I really got going online was
I created a music blog.
This was in--I put it out in 2004,
and I thought I was so late to the music blog scene,
but it turned out that I was one of the first 50 or so.
Having that environment where I had a website that had a lot of traffic,
and I could play with the design and experiment
and get a lot of feedback
on how people liked it,
that was one of the first times when I was really like,
This front-end development thing is a lot of fun.
[Nick Pettit]: That's when you first became interested in the web and technology?
[Paul Irish]: That was when I was like,
this could definitely be full time.
I'd been playing with websites.
Back when IE4 came out
they did this really cool marketing campaign.
This was when the DHTML term arrived,
and so they had this marketing campaign
where they rented out all these movie theaters across the U.S.
and invited a bunch of developers,
and I went and I got free popcorn and a free t-shirt
and a free Windows 95 install CD,
and they showed about what you could do in IE4,
and it was amazing.
So many great features came out then,
and so that was when I was like,
this interest of mine, there's cool stuff in here.
Eventually, it quieted down.
I went to college, but after that everything picked back up again.
[Nick Pettit]: So, did you go to school for this stuff?
[Paul Irish]: I went to school for--
I got a degree in technical communications.
I don't actually know--
I really do wish that there was more university-level coverage
for web development.
Front-end development is hard, and it's a pain,
and I wish that there was a more sophisticated education
program for this.
I got education in computer science and mathematics,
and management and communication.
[Nick Pettit]: With us being an education company,
I'm interested to know if
you feel like your degree really helped you
in your career, or--?
[Paul Irish]: Mine did,
and I think these days having a computer science background
has a very direct effect.
I wouldn't say 5 years ago that computer science would help in web development,
but nowadays, especially on the client side,
there's so much logic there.
You're writing jQuery, things are going good,
you're translating, you're writing larger applications.
[Nick Pettit]: It's getting complicated. >>[Paul Irish]: It's getting real complicated.
A background in computer science lays a lot of the groundwork
so that you're not making stupid mistakes
and taking 4 months to learn how you should have done things.
So, yeah, computer science has a big influence
on where the trajectory
of front-end development is going for sure.
[Nick Pettit]: Cool. Well, I think a big challenge
that's facing people coming out of college today
is how to make the transition to
a career and not just kind of hopping from job to job
or being unemployed.
How did you make that transition?
Were you just kind of in an internship,
and it was a really natural progression
or did you--?
[Paul Irish]: Yeah. I started out I was doing
some marketing for
a stationary company
that made wedding invitations and birth announcements,
and I wasn't even starting out with web stuff.
I was creating
a mail-merge Word document,
and then we were using that to fax blast all of our customers,
and I was customizing the mail merge to be
depending on the customer, and it was all this logic inside Word.
It was awesome.
That transitioned, within that job,
into working on their e-commerce presence,
and so that was good.
I think for most people
having something you can develop on your own--
In my case I had my music blog,
but I think having your own web presence,
whether it's a blog; I think blogging is really good.
Blogging what you're learning is extremely smart
and having that place where you can iterate and play around.
So, when you see a new feature come out,
like you're reading a site and they talk about some new CSS3 feature
or something, make a demo with it.
Kind of explore it.
Put it up on CodePen.
There's a lot of communities now that are encouraging
and let you explore things, get feedback.
Having a social community
that you can talk to and explore
your own professional development with.
I had one, and it's just been very--
It's a very smart way to go about things.
[Nick Pettit]: So what first attracted you to
front-end development, specifically?
Because you were making a blog, did you do that in WordPress or something?
[Paul Irish]: Yeah, it was WordPress. >>[Nick Pettit]: Okay.
Why aren't you, say,
like a Ruby or a PHP developer, for example?
[Paul Irish]: For me, the thing that really rocks about front end
is that you're building the interface,
and not only are you building the interface,
and you can make decisions around
how the interactions are,
but you're also getting feedback from its users
and from the customers.
The thing that they're touching, their cursor is going over
what you've created, and you're in a position
to where you can define the style of interaction
and the quality of the user experience.
Other people can work on how fast it responds
and a really strong infrastructure,
but the UI is just very sexy to me.
[Nick Pettit]: So it's kind of about that instant gratification then?
[Paul Irish]: The instant gratification and the feedback cycle of
I'm creating the interface, they're using it,
they can love it, they can be delighted by it.
Or they can hate it when I apply
a lot of text shadow to it and make it hard to read or something.
[Nick Pettit]: Sure, sure.
So, I want to talk about HTML5 Boilerplate for a little bit,
because I'm personally interested in it.
I think it's a really amazing project
for people that are just starting out
in web design and web development,
and I think there's a lot more that goes into it
than people might realize. >>[Paul Irish]: Yeah.
[Nick Pettit]: So, first, how did that project start?
[Paul Irish]: Before working for Google,
I was at an agency in Boston making websites, web apps.
We had a big team of front-end developers there,
and when I was going from project to project,
I was noticing that I was pulling lines of code
from my markup and from my CSS
from my last one into my new one,
and then I was like, well, I should probably make a template
just to keep track of this, and so I could start off with that template each time.
That's the original genesis, was just
that I needed to keep track of all this stuff
and move it forward from project to project.
Soon after, I got Divya Manian involved.
We put out a 1.0 just to see what everyone else thought.
Immediately it was really great
because inside HTML5 Boilerplate
is a bunch of techniques, right?
One of the things that has continued up until a little bit ago
is having inline documentation.
You see a technique, and you can instantly see
the website where that was birthed,
and someone can justify exactly why this is important.
So, it's kind of serving as an education tool.
You've kind of got to understand why everything is in here.
So, what happened is we put this out there,
and immediately we got a lot of feedback
over on GitHub where we open-sourced.
A lot of people coming in and being like,
Actually, I see what you're doing here,
but if you tweak it, this is a much stronger position.
It accounts for this edge-case bug in Opera 9.6 or something like that.
Every character inside HTML5 Boilerplate
has had a lot of discussion around it,
and so everything that you see is the result
of extensive conversations that have included
some of the best front-end developers in the industry.
You can go and look back at all those past conversations
in the old issues on GitHub.
The commits in the project,
the log messages have very desciptive
explanations of why we're doing this.
It's very well-justified in why all these decisions
are very strong as a baseline for starting your web project.
[Nick Pettit]: Cool. I think when beginning developers
look at HTML5 Boilerplate for the first time-- >>[Paul Irish]: We've got a lot.
[Nick Pettit]: --they're just like, "Wow."
"What's all this weird code?"
Let's talk about that a little bit.
From the top, what are all those IE conditional comments,
because that's the first thing people see?
[Paul Irish]: Yeah, so the IE conditional comments,
they don't look great.
They look kind of nasty.
It's like sometimes you want your mark-up to look
svelt and sexy and minimal,
and I love doing that as well.
Inevitably when you're developing--
So, this is not a problem for IE6 and IE7,
which have no market share anymore.
IE8's definitely still around,
but it's been a case where
they have actual CSS bugs in their implementation,
and you can use CSS hacks,
like syntax hacks, to target them and change the width or something,
and change the padding
to make your layout work and to fix those bugs.
But using undocumented CSS hacks,
it doesn't allow you to communicate well with your team,
and when you're working in a group
you want everyone to read the code and understand.
So, the conditional comments
provide a first-class way,
that was provided by IE luckily,
to specifically target these browsers
with CSS styles that affect just IE7 and just IE8,
or a combination thereof.
It's tricky because that's provided for you for free
in the Boilerplate,
but I do think that you do want
to try as hard as you can to avoid vendor-specific styles.
A lot of times just setting explicit dimensions,
width and height, on an element will let you avoid
doing that, and so you should try and go as long as you can
without specifying specific browsers.
But it is there when you need it, and it helps a lot.
[Nick Pettit]: There's plenty more in Boilerplate
that we could talk about.
There's--I've heard you talk about
all the weirdness with carsets. >>[Paul Irish]: Yes.
[Nick Pettit]: There's Chrome Frame, Modernizr, setting the viewport, and so on.
What's your favorite feature,
and what do you think is the most interesting thing that's there?
[Paul Irish]: I found this on Ajaxian a long time ago,
and now on Stack Overflow there's a great question called,
'The Hidden Features of HTML.'
I submitted it a long time ago, and it's the highest voted, and it's in HTML Boilerplate,
and this is the protocol-relative URLs.
So, down at the bottom when we include jQuery,
we pull it in from the Google CDN,
but the script source is equal to
//ajaxgoogleapis.com stuff stuff,
and you're like, "I think you're--"
We get pull requests and bug reports on a monthly basis.
Like, "You got a typo, you missed the http:."
And we're like, "Actually, we didn't."
So, the protocol-relevant URL
provides an ability to--
the browser will grab the HTTP version
when the page is in HTTP
and HTTPS when you're hosted in SSL.
This is cool because it guarantees
that the assets are requested securely
only when it's required.
There is a small overhead in requesting a secure asset
when you're in regular HTTP.
So, this is really cool
and helps, although it is a little tricky on Windows
when you're just developing, when you've loaded it up
from the file system and then in your browser it says, "file:,"
it can be really slow.
If you use a local development server
however, you don't have that problem.
So, I think the feature is really awesome,
and that's probably one of my more favorite things.
[Nick Pettit]: It's crazy you brought that up
because I was just looking at that the other day
trying to figure out what happened here.
It's kind of amazing to me just how much
goes into a, supposedly, vanilla webpage.
I mean, it's called 'Boilerplate,' right?
So, it seems like it should only be the most basic things that you need,
but there's a lot there.
Do you think the job of a front-end developer has become
a lot more complicated in recent years?
And is that a good or a bad thing?
[Paul Irish]: Well, there's 2 things happening at the same time.
One of which is that age-old legacy browsers
are on the decline. IE6 is dead.
If you look at market share numbers, IE6 is dead.
IE7 has under--actually just about 1%.
IE is really strong but still
that's improving.
A lot of front-end developers' pain has been
the old browsers that haven't kept up
with not only fixes, but features that we want to use.
So, that part is getting easier.
By the same point, the last 3 years
have brought an enormous amount of features
to browsers that we now get to incorporate
and figure out the best way to incorporate.
So, for instance, if you're using a CSS transition,
do you use that CSS transition
and just let it fall back
if it's not supported by the browser?
I recommend you do.
But you could choose to feature detect it with Modernizr
and then use jQuery to animate
the same general transition.
So, figuring out your fallback scenario
is a little tough.
A little bit ago, a few of us put out a site called,
'HTML5 Please,' which aims to provide
a bit more guidance for all this stuff.
So, basically, you get to look up
for every feature, all the new stuff,
you get to look up exactly
what is probably the best way to handle this
for a cross-browser scenario,
where you might not have support everywhere.
Should you use a polyfill script to enable that feature in an old browser
or should you just let it fall back
or is there some in-between state that is probably the best way?
Finding that is tricky, but I think there's more and more resources out there that help.
[Nick Pettit]: It seems like this is something
that's unique to the nature of web development
where you have to come up with these fallbacks
for all of these different browsers coming out.
Do you think it'll always be that way,
or do you think we'll hit some point
where things are pretty stable,
and web development is just kind of a little bit more static?
[Paul Irish]: Well, so if we got there,
if we got to that point, that would essentially indicate
that there's not any
groundbreaking new features being added.
I kind of don't want to be there. Right?
At the same time, I don't like
having to send a bunch of polyfills
at older browsers
and just testing and worrying about that.
So,yeah, that's getting really complicated and messy,
and managing the various states,
like if you think about the old state of
all browsers must look--the experience must look the same in all browsers
to the new one which is we feature detect, we find out what we can provide,
and there's a lot of combinations of how your site looks.
Then you're like bringing responsive design, and it's changing.
So, from a capability and future perspective, it's different
from a viewport size; it's a different experience,
and when you've built a site,
and you're testing it to make sure that everything is right,
there's a lot of combinations to look through.
Here, the most important things are
choosing features to use where the fallback scenario
is you kind of forget about it.
If a browser doesn't have border radius CSS transitions,
that's probably okay.
A lot of these just kind of enhance.
The other part is
that I think we could actually, as a community,
do better to help encourage our users
to be using browsers that we specifically want
to support, and that helps our job,
and it helps them.
I know conversion rates improve significantly
when the experience is faster.
Helping your users be on the kind of browsers
that you yourself enjoy
actually has a good business support,
and is a lot more fun for users and developers, of course.
[Nick Pettit]: There's so many steps
that are involved in front-end development at this point.
This is something you were blogging about recently
where you said the tool chain is a little bit overwhelming.
There are so many steps and there are so many different
tools and techniques to deal with each one of them.
Do you think there's a need to simplify that
and try to bundle all of that together?
What are your thoughts on that?
Because I feel like the barrier to entry
is really high for somebody that's new to it.
[Paul Irish]: Yeah, so, it's tricky.
There's a lot going on,
and, yeah, it's a lot to absorb.
I've recently been working
with Addy Osmani
and some other people inside the web development community
to put out a project called, 'Yeoman,'
and this project is about putting together a lot of tools
that help you build better web apps.
Now, there's a lot going on in there,
but it's using things like CSS pre-processors,
live reload,
even shipping a plug-in for Sublime text.
So, there is like a baseline of features
that most front-end developers use,
and I don't think this is really listed anywhere.
Maybe I should make a blog post out of this,
but there's a few things that these days are pretty well accepted
as these are fundamental to development.
People don't talk enough to their colleagues, coworkers
about what is their process for developing.
How are they interacting
with their text editor, their source control?
I think there could be a bit more of a conversation
around what we can do to make sure that
when we're coming back to work on our projects
it's not frustrating and instead it's fun,
and I'm getting work done quickly.
Every time I watch someone else do their work
and I sit next to them and I'm like, "Whoa, whoa, whoa,"
"What did you just do? What was that keyboard shortcut?"
[Nick Pettit]: Right.
{Paul Irish]: I think we should do a lot more of that.
[Nick Pettit]: Do you think it's okay for people to just use the stuff
and maybe not totally understand it but just know that,
"I need to do this thing for it to work?"
At what point does it just become an abstraction?
[Paul Irish]: I think it's--that's a great question.
So, right now--
Nicolas Gallagher is the new project lead
on HTML5 Boilerplate.
He's kind of taken over, and he's doing a fantastic job.
So, his perspective is that
the Boilerplate project is aimed specifically
as a baseline--this is a baseline for web apps,
and it can be used for web apps and websites,
and there's not really much to take away,
and there's probably not much to add.
In fact, it's a very stable project
at this point because it's not trying to solve
other problems.
Now, let's say in jQuery, for instance,
this has been a longtime question
which is, "Should I learn JavaScript at the same time as I learn jQuery?"
"Should I learn it first?"
My answer to that has always been
you learn them at the same time,
especially things like math and strings and array methods.
You want to learn those JavaScript methods fairly quickly,
because there are not good answers for them in jQuery.
At the same time, you don't want to have to learn
how a lot of the intricacies of the DOM work
very early on.
So, I think it's a matter of
learning the techniques as you're using the tools.
So, in HTML5 Boilerplate,
you kind of dig into some of the documentation,
and at some point you'll just be like,
"Why?" And you should be asking that question.
That shouldn't preclude you from using the tool.
At the end of the day, you want to enjoy what you're doing,
and you want to do it fairly quickly,
and you don't want to be frustrated.
So, you use the tools that are available.
I think it's important to understand how they work,
and right now I'm trying to get a better understanding
how browsers work, and those are really complicated.
But I'm not going to tell everyone that every web developer
needs to understand how all of the web browsers work.
I think we're okay with that kind of working as a tool.
It's a balance.
Understanding the internals of any tool
will help you be much stronger at using it,
but you don't need to understand it
to use it.
[Nick Pettit]: So, wrapping up, what advice would you give
to web designers and developers out there,
just as a very general question?
[Paul Irish]: Sure.
[Nick Pettit]: What can they do to better themselves?
[Paul Irish]: One of the things that happened to me
a while ago was,
I had joined the jQuery IRC channel.
So, IRC is kind of, it seems nerdy.
Yeah. Nick's like, "Yeah, definitely nerdy."
But I joined that a long time ago,
and I was just super active in it, and that's how I got involved
in jQuery projects, started doing developer relations for jQuery,
joined the jQuery team, was involved in the project for a long time,
and it was all because I joined the IRC channel
and just started talking to people and helping people.
So, helping other people with
front-end development
you learn a lot, and I would recommend that.
The same time that that happened,
I found a group of people that were
doing a bunch of jQuery, doing a bunch of JavaScript,
and we just formed this kind of social group
of 20 of us.
It was also on IRC, and we would just talk all the time
about what we were doing,
and this led to--there was a little bit of competitiveness,
but a lot of cooperation.
We would work on projects together,
things like MovetheWebForward.org
and HTML5 Please, have come out of this group.
So, having--
So you're not alone without a mentor.
It's great to have a social group
where you don't feel like completely inferior to everyone around you
and can kind of support each other.
The last part of this is really just to
be able to have fun while you're learning.
I think part of that is
creating little demos and experiments for yourself.
Doing that will give you more experience with cool features
and things that you want to explore
and help you feel more confident when you
propose to your boss, "Really we should do it this way,"
"Why? Why?"
And you'll be like, "Well, I've actually done some work with this,
and it's not as bad or as scary as you think,
and, I don't know, it'll all work out."
[Nick Pettit]: That's the advice that I always give to people
is just, "Do cool stuff and share it with other people."
[Paul Irish]: Yeah, absolutely.
[Nick Pettit]: Awesome. Well, thanks so much for being here. I really appreciate it.
[Paul Irish]: Cool, thanks.
[Treehouse FRIENDS]
[♪music playing♪]