Tip:
Highlight text to annotate it
X
[APPLAUSE]
BEN VINEGAR: Hello?
Test.
This is the Build Process Panel, which thematically is all
about, how do we take our source code in whatever form it may be
and transpile preprocess, minify, optimize, et cetera
until it arrives in its final form?
So my name's Ben Vinegar.
I'm a lead front engineer at Disqus.
I also wrote a book called Third Party JavaScript.
It's pretty terrible.
I have five wonderful panelists with me.
First there's Kyle Simpson, who you
may know as the author of LABjs, a JSON author.
He's writing a book called "You Don't Know JS."
Nick Fisher, who works at SoundCloud and he designs
and implements a lot of the build systems,
SoundCloud being a relatively large client side applications
with some cool stuff going on.
Addy Osmani, who develops TodoMVC and Yeoman, which
is a scaffolding tool working with Grunt,
and he also sorts on Chrome DevTools.
And then Sebastian Golasch, who works
for Deutsche Telekom-- I practiced pronouncing
that for a while-- working on a product
there that also uses sort of older, traditional build tools.
I don't know if "old" is the right word,
but with Maven combined with Grunt and some client side
stuff.
And then lastly, I have Gareth Rushgrove,
who works for the UK government, working on a big project that
involves modernizing a whole bunch of UK government websites
and bringing them into the modern era.
And with that said, Gareth is just
going to start us off with a quick presentation.
GARETH RUSHGROVE: Your build process needs you
because it's probably not as good as it could be.
There it is.
But what is a build process?
What we're talking about really is
it's a way of sharing common actions as much as anything
else.
If it's just you doing something and you're just doing it once,
that's not really a build process,
but actually storing it as something
that you can come back to, or more commonly,
storing it as something that your team can come back to
is really important because frankly, people
suck at repetitive tasks.
If I ask someone to do something over and over again,
they'll probably do it subtly different.
A build process is always about standardizing
those repetitive tasks.
And some of that's to do with the fact
that words can mean different things to different people.
If I say, can you minimize this bit of JavaScript for me,
people will do it differently, and that's probably
no good in an environment where you're trying to work together.
You end up with different results.
Someone might take longer.
That's no good.
We need to standardize.
But your build process is software.
People come to it, certainly, from engineering and web
development, from lots of different paths,
and not all of them will think of themselves
as software developers.
Tough.
You're a software developer.
If you're anywhere near a build process,
you're a software developer.
Live with it.
But what are we building?
What are the sorts of types of things
that we're putting into our build process?
Ben mentioned a few things that will
be common to lots of people in the room-- CSS preprocessing,
templating-- Kyle-- bundling, minification, linting, testing,
optimization, transpiling.
There's lots of things we're doing with our code
and there's lots of tools we're using.
Two of the common ones at the moment,
certainly in the front end space,
appear to be Gulp and Grunt.
Grunt-- this was a few days ago, but I
bet it's about the same today.
Maybe it's less today because we're all in this room
or watching on the video.
30,000 installs of this every day.
That sounds like quite a lot.
That's a lot of interest.
That's a lot of people.
There's 2,500 Grunt plug-ins, and I'll
come back to why that might not be great in a moment.
There's actually 450 Gulp plug-ins,
and that's a tool that's not been around anywhere near as
long.
But I said I'll come back to why that might not
be good in a moment.
Contrib-jshint is a Grunt plug-in, And excellent.
There's one for Gulp.
Brilliant.
And there's grunt-coffee and gulp-coffee,
and there's broccoli-coffee as well.
And at some point-- and there definitely
will be someone in this room, someone watching this,
I'm building another one, and hoping someone
comes along and builds another one -coffee, and -jshint,
and everything else.
And we know there's 2,500 Grunt plug-ins.
Do we want 2,500 Gulp ones and Broccoli ones
and everything else?
I think there's probably a lot of front end
people in the room.
There's probably people writing JavaScript, writing CSS,
writing HTML most of their time.
Is that fair to say?
Any people go, I'm basically just a Java programmer?
[INAUDIBLE]
But we're all working in environments
where there probably is a bucket that
might not be written in JavaScript.
You maybe are using Node, maybe you're not.
Maybe it's Ruby, maybe it's Python, maybe it's [INAUDIBLE].
It doesn't matter.
There's a lot of other things going on around you that also
have build processes, and there's
loads of build tools, whether it's Make,
[INAUDIBLE], Maven, [INAUDIBLE].
There's loads of these.
There's a bit at the bottom that says two points for each tool,
minus five if you liked using Maven.
Ultimately, building software isn't new.
It's happening all over the place,
and standardizing all the things, standardizing things
in silos probably isn't enough.
Even when it comes to typical tasks
around front end engineering, a lot of those
have plug-ins or projects related to other build tools
that are doing it, whether that's
[INAUDIBLE] versions of things like [INAUDIBLE] Compiler
or Compressor versus Sprockets and Rails
versus [INAUDIBLE] and PHP.
This is spiraling, massive, all these things
doing fundamentally the same jobs.
And really, everything old is new again.
Building software is not new.
It's maybe new to-- these tools are new, Grunt and Gulp.
There's a lot of interest around programming
and JavaScript at the moment.
There's a lot of new tools coming around,
but this isn't fundamentally a new activity,
and some of the same mistakes are being made.
Some of the learnings are not being taken forward.
Make is older than you probably.
I wrote this before turning up.
I think that's broadly true.
Unless you're all 37, Make is older than you.
There's a few people here who probably look older than 37,
but I reckon most of you-- I'm going
to go for Make is older than you.
Make is a build tool.
If you haven't seen it, it looks like this.
If you're thinking, wait a minute.
Where's all the rest of the code?
You can think, well, maybe you should
be using Make rather than Grunt.
Do you know how many Make plug-ins there are?
I don't think there are any.
That's probably going to be completely untrue,
but basically, there aren't really Make plug-ins.
There aren't really plug-ins for LS as a Unix command tool.
The reason is because Unix pipes are amazing, or rather,
the concept of simply chaining things
together by sending information between them.
LS doesn't have a Grep plug-in or a Sort plug-in.
It's just about Unix command line tools
being able to be chained together.
It doesn't matter that these things could
be written in different languages by different people
at different times.
We don't have to customize them all via plug-in models.
Actually, I don't do a lot for [INAUDIBLE].
I haven't done for quite a while.
So actually, I did a whole bunch of research
into what people were doing to be on this panel,
and I thought, as a community, it
seems that there's a lot of effort reinventing the wheel.
This isn't just true for this community.
That's true of basically programmers, myself included.
But we invariably invent things and reinvent things
in our language of choice and sometimes
in our tool of choice.
But the thing we have to miss is that's
our language and tool of choice at the moment,
and that probably changes over time.
So anything that we can do to minimize that
is probably a good thing to think about
because we can make things better.
And ultimately, things are better
now than they were before.
Having tools is good.
This is not about, oh, we shouldn't
have done any of that.
Throw it all away.
It's about, how can we make it a lot more sustainable?
How can we learn from 20-odd years,
30-odd years of other programming communities' build
processes?
What is the most valuable unit of sharing?
Is it a plug-in?
How can we build community consensus
and avoid the plug-in apocalypse?
I think there's a genuine problem there.
Can we share entire pipelines as well as tools?
It's fine sharing the individual bits,
but actually, we probably can all take a collection of things
together and string it together to do the same thing.
And actually, can we share the pipeline?
Is that a better unit of sharing?
And importantly, how do we break down
these artificial programming language silos?
Because even if you're thinking, well actually, my career is
going to be all about-- for engineering-- it's all
going to be about JavaScript and CSS and HTML,
and probably they're going to change,
they're going to evolve, they're going to better.
The tools around it's going to get better,
but that's what I'm going to do.
You'll probably do it in a context
where other people around you are writing
different programming languages, and how do we
make it so there's not that culture clash?
There's not that us versus them?
How do we bring these things together?
They're just some of the things that
were in my head and some of the things I care about.
My other panelists might violently
disagree with some of that.
With that, we can go on to the panel.
[APPLAUSE]
BEN VINEGAR: Thanks, Gareth.
I think that was a pretty good way to start us off.
There's a question I'm looking for as I browse
this thing that's been moved around.
I'm going to ask on Cornell [INAUDIBLE].
And also I just want to say, I feel
that we've butchered your question slightly,
and if you would like to go original with this,
please do so.
AUDIENCE: Is eliminating a need for a build process
a goal of web standards?
For example, should CSS adopt all the features
of CSS preprocessors, or should it avoid duplicating them?
ADDY OSMANI: So one of the really nice things
about the Extensible Web Manifesto
has been the community starts to iterate
on features and languages like JavaScript
and tools like JavaScript and so on,
and once we reach a nice consensus there,
we can then go and move on to standardizing those features.
So in the case of CSS and preprocessors,
we've already started to see things like variables actually
land and go from things like Sass and LESS
directly into CSS.
The same thing is being done with mix-ins.
I think that it's perhaps not necessarily
the browser's responsibility to provide hooks into your
build process, like a preprocess step or a post-process step.
That seems to be something that would be better left up
to additional tools or something on the server side.
But I think that we currently have a good system in place
for actually landing things that the community is doing
and finding useful patterns directly
inside native primitives, and I'd
like to see us continue doing that.
KYLE SIMPSON: I want to jump in because they asked
me to be on the panel so that I could disagree with everyone.
I actually think it's a terrible idea
to standardize all of these things
into CSS and into HTML and JavaScript.
For example, I think it would be an awful world
if the browser had a transpiler for every one of the 1,000
languages that are out there.
There are things that belong in our tool sets,
there are things they belong in our technology,
and there are things that belong in a build process,
and I draw a very distinct line between them.
So transpiling, a lot of things that we
see in CSS preprocessors are things that I think
aren't necessarily great to be in the CSS language.
They're things that tools could do for you.
So I don't think it's a good idea
at all to go down that slippery slope of saying, anything
that I can dream up should just drop into a standard.
I think build processes are there for a reason,
and I don't see them going away any day.
GARETH RUSHGROVE: If anyone's got
a way of just dreaming stuff up and dropping it
into a standards process, though,
I'd like to hear about it.
KYLE SIMPSON: That would be awesome.
GARETH RUSHGROVE: I think fundamentally,
the fiction around standardizing things is it takes time
and it's hard but for good reason.
So actually, I think the answer is yes,
but realistically, the rate that that happens
is slow for good reasons.
Until we can broadly all agree on something,
then it's not going to get standardized,
and we're definitely not going to broadly
agree on everything anytime soon.
So therefore, it's the stuff that we
can fight about that goes in our different build processes.
NICK FISHER: I'd agree with Kyle here as
well that I think one of the real benefits
and the reason that JavaScript and CSS got to where it is now
is because it didn't do that ever.
It is a very bare bones language, JavaScript,
that has let all of us then come up
with these new tools and these new things
to build upon a very basic level.
And I think that if we decided to do that, say, 10 years ago,
we might have a very different language today.
BEN VINEGAR: So I'd just tack onto this,
which is historically, have we even done
a good job of when we take features from other languages
and bring them into JavaScript or CSS,
people talk to me a lot about, we shouldn't even
be using jQuery but we should be doing straight DOM.
But I find that those API methods are still
pretty verbose and they're not very fun to use.
So if we went along the path of bringing a lot of these,
let's say, LESS and Sass features into CSS,
would we even get it right?
Would it be fun to work with?
KYLE SIMPSON: I think it's OK for these tools
to inform standards, but I think we should draw a line
and say just because somebody can put something
into a build process doesn't mean that it will ever
belong in a standard.
So there's plenty of good examples, for better or worse,
that CoffeeScript informed ESX.
I don't like all of them, but that's good
that we were able to inform that.
But I don't think it would be a good idea for CoffeeScript
to natively start being in the browser.
I think that's a build step.
ADDY OSMANI: So I think the TLDR of that
is it looks like it's probably not the best
idea for everything that's possible inside a build process
today to be baked into the browser.
We're always going to fundamentally differ
when it comes to our tools, and there
are going to be some patterns that it makes sense
to eventually land natively, but on the whole,
if we can do something outside of that process,
let's keep rolling with that.
SEBASTIAN GOLASCH: And also, in my opinion, the good part
of using a tool and a build process,
using processing before it is in the browser,
is that if it doesn't make sense, you can throw it away.
Once it's been in the browser, it's there forever, period,
and that's a huge problem.
That's also why standards are slow in the common sense,
but it's the right thing.
BEN VINEGAR: So there was a second part
to Cornell's question, the original question.
I don't know that he touched on it exactly.
I was hoping that he would, but it was about,
should the idea of preprocessing itself be a standards feature?
We are basically in agreement that it
seems like most of our code is being taken from one source
into another.
Is there an idea of having a preprocess step
versus a runtime step?
I'm looking for a nod from you.
Have I captured that?
AUDIENCE: [INAUDIBLE] was thinking
where CSS should be optimized for being preprocessed,
whether it should have syntax or features that are not
for humans to type manually, but for preprocessors to generate,
for example.
BEN VINEGAR: Any comments on that?
KYLE SIMPSON: Well, I'll jump in since I happen
to be experimenting with what I call CSS templating as opposed
to CSS preprocessing, and I think
that's a better way to go.
So again, what I said was there's
several things that we've been informed by LESS and Sass that
do belong in the CSS language, and I'm
glad that we've got tools that have standardized on what
those things are, like for instance, being able to drop
in a value or for instance, being
able to nest a rule or something like that.
But there's a whole bunch of other stuff
that I think should be externalized.
So I think we can draw those distinct lines,
and I think the tools can standardize on the stuff that
is smart, but that's obviously a gray area.
I mean, it's hard for any one person to say,
here's where the line goes.
So the community, I think, needs to be
more responsible about not just looking at the new, shiny thing
that somebody dreamed up but saying, really,
should that actually be adopted or should that
stay in the user land?
I think we need, as a community, to be
more responsible with that decision.
BEN VINEGAR: On that note, I'm going
to bring us to our next question.
I'm going to call on from the audience Ernesto Jimenez?
AUDIENCE: So the question is, much of the new tools
and preprocessors are growing within the Node.js community
and depend on the Node stack and MPM.
Do you think this dependency might
be limiting in the future?
ADDY OSMANI: Let's talk about Node for a moment.
So Node has been growing in popularity quite
extensively over the last couple of years.
It currently has something like 35,000 downloads a day.
I think 0.1 was downloaded something like a million times.
So Node's popularity is increasing, which is great.
At the same time, you have to remember
that the long tail-- so not necessarily
the people in this room, but people
who are still afraid of the command line, people who
want to be able to optimize their pages and their apps
and so forth but don't necessarily
feel like it's a nice place to go into the command line.
They still feel it's really, really scary.
It's those people that we actually
need to come up with solutions for.
And there do exist tools that can help with this stuff.
The long tail generally like working with GUIs,
and we can tie that stuff back to Node,
whether we're using something like Node-webkit or additional
tooling so that they just have to say, here's my project
or here are the directories I'm working with.
Can you just bind these to the different tools
that might do preprocessing, postprocessing, and so forth?
So I don't think that using Node is
something that's stopping us.
It's just going to be about improving awareness
of how OK it is to use things like Node and the command line
when you're actually working.
GARETH RUSHGROVE: Coming at that from a completely different
point as well is that Node's a runtime,
and yeah, whether someone's using
command line or another tail, it's
something that's actually in our code.
For some environments, that is a barrier to entry.
They're not going to put Node on their environment.
That's fine.
That's going to happen.
One thing that is happening, though,
because there's been a lot of interest in the tools
that are being built on top of this,
and there's certainly some work around basically
embedding a Node runtime in the JVM
for environments which are saying,
we're not going to install this random new tool,
but we are happy with running all this Java stuff.
So I think that becomes a less limiting factor over time.
The tools will be able to be run in different places.
KYLE SIMPSON: So to build off of that,
I think what it gets to is I would wholeheartedly
say we should standardize on JavaScript for driving
these tools, but Node is the tool right now.
It won't be the tool necessarily five years from now or 10 years
from now because Node wasn't the first server side JavaScript
engine and it's certainly not the last.
We had one from Netscape in the very early days of JavaScript
that didn't survive, Rhino, and now [INAUDIBLE].
I mean, we've got a whole bunch of other environments.
So I think to the extent that it's possible for a tool author
to build a build process tool in JavaScript
and try to be as agnostic as possible,
try to put as few touch points to the specific host
environment as possible, then we see that five years from now,
when there's something that supersedes Node,
it won't be as hard to convert that tool over.
Most of the logic will survive.
So I think we should be doing that.
SEBASTIAN GOLASCH: If you think back five years ago,
we didn't have Node, and back then, we
did build scripts with Ant, this XML Java thingy,
and maybe put a Rhino jar in there because we only
knew JavaScript and so we could script something up
that does a little bit on top of it.
It was hard to configure, and so with the rise of Node, front
end developers who were capable of writing JavaScript
and couldn't write some other languages, or only CSS and HTML
besides.
KYLE SIMPSON: Or didn't want to.
SEBASTIAN GOLASCH: Or didn't want to-- just
had the power to tap into that build process
without just learning another language
or whatever, or another tool.
So they're now familiar with the stack
and can embrace this whole plug-in ecosystem of whatever.
I think that that's a really good thing.
BEN VINEGAR: I want to cut you guys off
and actually just bring up the second part of that question,
which we haven't touched on at all, which was MPM.
I think everyone seems to be pretty positive on Node,
but what about this idea that there's
a huge dependence on MPM as a package manager,
and the MPM repository, for which I think
it's fair to say there's been some bumpiness to it.
PRESENTER: What are you talking about?
BEN VINEGAR: Well, bumpiness-- to contextualize this,
for example, I think a month ago,
they changed their security certificates without notice,
and I think a lot of people who had depended on Node,
they just couldn't download packages for a day.
There was no instruction.
There was no communication about what had happened,
just as an example point.
It's not the only one.
Anyone want to touch on this?
Perhaps I'm going to start with you, Nick.
NICK FISHER: I think that's going
to be a problem if you're relying on any third party
to host the things that you need for your application.
I don't think it's unique to MPM.
I think MPM's solving a really good problem right now,
but if something were to replace that in the future,
then I think that it shouldn't be that difficult to actually
transition across to that or even get rid of that
altogether, like flatten all your dependencies,
check that in, if it came to that.
I'm not suggesting you do that, but I
don't see that MPM itself is an issue there.
KYLE SIMPSON: Well MPM is actually, if I understand,
it's sort of like a protocol that you could theoretically--
and I know companies do-- spin up their own MPM instances.
So we don't necessarily have to think of MPM
as the one global, universal repository.
It can be a way to get your own company intranet repository
or something like that.
So I think that's good, but I would also
say Git and GitHub are pretty awesome for that, too.
We don't have to discount those as the place
that we keep repositories.
BEN VINEGAR: [INAUDIBLE] the audience here.
Sorry, I don't know your name, but do you
have a comment on this?
Oh, your name's on your badge.
Johnathan?
AUDIENCE: We have the issues as well that a lot of these tools
are now being stored in GitHub.
GitHub's a company and we're relying a lot on GitHub,
so what should be done [INAUDIBLE]?
PRESENTER: Don't use GitHub.
Use Git, not GitHub.
Use MPM the protocol, not MPM the--
PRESENTER: Registry.
BEN VINEGAR: What about the idea that-- obviously, you
can spin up your own thing, but MPM now, it's
a private company.
And if you go to other languages where there's PyPy
and there's Gems, those are all actually
community efforts sponsored, as far as I understand.
Does that change the landscape at all?
No?
KYLE SIMPSON: No.
BEN VINEGAR: All right.
I thought I'd throw it out there.
KYLE SIMPSON: I'm sure it does change the landscape.
AUDIENCE: I would love to hear from Gareth about that.
When you work with government people,
what do they say when the piece of software that you rely on
is an 0.1 release, and not a 1.0, 2.0, 5.0 release
that can be trusted?
GARETH RUSHGROVE: So the version number thing
is nearly a red herring because it's
an arbitrary string, basically.
It's only representing value in the eye of the author,
and so you can just go-- if someone goes,
oh, it's got to be 1, if you tell the author,
they might just make it 1.
But ultimately, different organizations
will have different risk appetites,
and that's true of-- I work for government,
there's going to be banks, there's
probably going to be your new startup.
The thing that kills your new startup
is probably not a bad dependency from a third party managed
service, but it might be something
that has an impact on a bank because someone
tries to compromise that service and come back to you.
It's a really hard problem, and it's not specific JavaScript.
It's specific to third party packaged services.
Having one per language was a stupid idea.
It's too late to fix it.
The next new language that comes around
will probably have an MPM or a Ruby Gems.
Its a bit of a shame.
The package management systems within operating systems
solve a lot of the problems and people
forget about the problems they're solving.
C Panther Perl does loads of really interesting stuff
that no one's recreated in the last 10 years.
SEBASTIAN GOLASCH: One addition.
I think one thing that will help us
with at least the security concerns about using
MPM is when MPM adopts something like Maven
does with package signing and stuff like this
so we can assure our clients that this thing is really
the thing that we said it's going to be there
and not something different because someone hijacked it
or something.
GARETH RUSHGROVE: It solves the man in the middle issue.
It doesn't solve the fact that someone might have compromised
the person who was uploading it in the first place.
PRESENTER: But in general, isn't it--
I find it always fascinating--
BEN VINEGAR: Guys, sorry.
I'm getting thrashed to get to the new topic.
So we could go to the audience again.
I think this is a pretty exciting question.
I guess I'm not going to the audience.
I guess I'm supposed to ask Kyle Simpson to ask a question.
KYLE SIMPSON: Like I said, they put me on the panel
so that I could stir things up, so I
get the pleasure of asking this question.
There's a mini browser war that's going on right now
between Grunt and Gulp, and we toyed around with having you
all have to stand up and declare where you are on that,
but we won't.
But there's other several other would be contenders,
and that sort of betrays this idea that maybe there
is one right build tool to rule them all.
So the question is, is that a realistic idea, that we're
striving towards one great build tool that we need to find,
or is it just idealistic?
And is it harmful fragmentation or useful experimentation?
ADDY OSMANI: I think that traditionally,
having multiple tools is a good thing because it drives
innovation, and I don't think that's a bad thing
in this community.
Build tooling on the front end is still very young
and it's somewhat in its infancy.
So I don't think it's necessarily a bad thing.
One thing I would like to see is us standardizing on
perhaps a task specification.
I know that there's been some effort from different
build tools to standardize on the Node task spec, which
talks about things like having a single way to handle records
or logging or notifications and so forth.
I think that could actually help us avoid having
this crazy wheel of reimplementing things
all the time, but I know it has its own challenges.
NICK FISHER: I have an opinion on the Gulp and Grunt
thing, which is I don't care.
I don't use either of them, and I
see these tools as useful for certain situations,
but they are glue that sticks together interesting things.
I think the discussion and browser war type arguments
going on-- well, I'm not sure anyone's really
arguing-- but arguments going on between these things
really distract from why we're even doing a build process
in the first place.
We're doing it to get faster websites,
to get better development time, and so on.
If you use Grunt, if you use Make, if you use Ant,
I don't care.
It's what we actually do in the build
process which is actually important.
But I would personally like to see less people reimplementing
Grunt-coffee, Gulp-coffee, whatever, and just have coffee.
Just use that and hook into it any way you want.
ADDY OSMANI: So you feel like we should get closer to the grain
and just actually call the existing tools,
rather than writing wrappers around them?
It seems to me what you're saying.
NICK FISHER: I mean, the wrappers are fine, but just
recognize that they are just wrappers.
The important thing is what it's wrapping
and what that actually does, and how you can plug these things
together is just details.
KYLE SIMPSON: There was a write up some months ago.
It was kind of tongue in cheek, but it
was tasks.js, which boiled down to simply just writing
the JavaScript yourself.
And while it was funny and interesting from a boilerplate
perspective, I think what it does miss a little bit,
the reason I write tools and the reason
I would make a Grunt plug-in for my tool is not
because that's the only way to use my tool.
It's because I'm trying to lower the barrier to entry so
that I get bigger market share.
I'm trying to make it so there's as little boilerplate
as possible to drop my template engine in.
Of course, some people-- and I might
have the same perspective-- but some people
would say, well, it's OK to raise the barrier a little bit.
If you want to use it, you have to know how to use it.
Call the API, well document the API.
I think that's the reason why plug-ins exist.
Everybody wants to make it so that their tool is the one that
blows up and gets 10 million stars on GitHub.
BEN VINEGAR: Sebastian, you had a comment there.
SEBASTIAN GOLASCH: I mean, the thing
is with all these dependencies, with all these plug-ins, when
we say, OK, we have a common interface
so we only have one plug-in that works with all of the systems,
perfect.
In the end, it's a tool and a tool should help us,
so if I like hammer B better in my hand than hammer A,
then I use hammer B because it's better for me.
And the same is true with Grunt and Gulp and Broccoli
and [INAUDIBLE] or whatever.
I mean, if you're a Node developer,
Gulp.js feels more familiar with all the stream stuff,
and so you can write it because it feels more familiar.
If you're a front end developer, most of them
like Grunt more because it's this declarative approach where
you only have to configure things.
I think it comes down to use the right tool for the job.
BEN VINEGAR: Can I go to the audience
here, because there's a bunch of hands going up.
Just first over here, and Remy.
AUDIENCE: Disclaimer.
Unfortunately, I'm one of these people who has also
developed another build tool [INAUDIBLE].
So I agree with everything we've said
and I think the idea of having inter-op between plug-ins
is great.
One thing to remember is that these tools are there
to make it really easy for people.
We want people who are scared by the command line
to be able to do the right thing by default without having
to worry about configuring crazy paths everywhere.
So to me, the real question is, what
is a good baseline for these tasks that
would work in different tools so that it does the right things?
And just to throw out a few examples is,
should it be able to produce source maps currently
for everything by default?
Should it be able to rebuild partially
so you don't have to rebuild all your things all the time?
And all these things, I think need
to fit into what is the common format for these build tools.
ADDY OSMANI: I think one of the really big challenges
with coming up with a spec for build processes in that task
spec is that it's difficult to create something that
is flexible enough to also match the architectures
of these different tools so that they can work behind the scenes
and do what they need to do without necessarily feeling
overly constrained.
Unfortunately, the Node task spec idea
that I talked about earlier, that's actually something that
is currently on hold because none of the
build tools could actually reach agreement
on how they should approach this problem.
It's really, really difficult.
I'm hoping that later on in the year, they'll come back to it
and think that it's something worth value.
GARETH RUSHGROVE: Sorry.
Are we talking about something like, oh, it's
good to have multiple tools because that breeds innovation?
Don't think you can't get locked into an open source tool,
because you can.
It's not just commercial side.
You talk about lock-in.
You get yourself locked into something by saying,
you know what?
The barrier to moving from this tool
is so great, I'm not going to do it, at which point
you benefit not one bit from the innovation coming
from other tools.
BEN VINEGAR: OK.
I'm going to get a quick comment from the audience
here, from Remy [INAUDIBLE].
AUDIENCE: I was going to say I don't personally
use build tools.
That's one step.
The thing is jQuery, it was the tool that
made working with JavaScript really,
stupid simple for a large amount of people,
and suddenly, they were able to write JavaScripts
without writing JavaScript.
And these build tools have given me
a way of just adding minification and getting
that done whereas before, I wouldn't have done it,
and many other people are going to be doing that.
You talk about getting locked in.
I don't think it matters at this point.
Getting hold of build tools at this point
was so new for this community.
If we get locked into Grunt for a few years,
and eventually, there's standardization in five years'
time, then that's a huge step forward compared
to just not doing it at all and just delivering massive images
over the wire, uncompressed images.
I think we're still at that very early days of when jQuery
was really spurring the JavaScript [INAUDIBLE].
ADDY OSMANI: I agree with that.
I feel like this build tool conversation,
sometimes it skips over the fact that we
don't talk enough about what's inside our build process.
We should be caring more about image optimization, image
compression.
Images are the thing that are slowing down the web today,
and we need to get more people caring about those problems
and spending more time talking about how we can actually
speed up our pages and less time,
perhaps, on arguing why you should
be using Gulp versus Grunt.
I mean, they're still fantastic tools,
but I think Sebastian said earlier,
people who are more familiar with Node
are perhaps going to use Gulp and people who aren't are just
going to use Grunt.
That seems to be working.
BEN VINEGAR: I'm going to cut you guys off because actually,
the next question I think, goes into just what
Addy was touching on.
I'm looking for, from the audience, Peter Muller.
AUDIENCE: I'll have to read this as well because it's
been changed a bit.
Most build scripts, including those generated by scaffolding,
are a chain of several discrete steps.
Do we even need the complexity of having control
of every one of these steps, or should we instead
have an opinionated build chain that just gets us
to the endpoint that we're interested in?
NICK FISHER: From my experience, I've
built an opinionated tool chain for our own
build system that we needed, and I'm really happy with it.
There's been a lot of work put into it, obviously,
but I think in the end, if you really
want to get total performance out of your
build process, not in terms of how fast it runs
or anything like that, but in terms of what actually executes
at the end of your build process,
then I think that's definitely a very smart way to go,
and you definitely don't need any particular tools like Grunt
or Gulp to get you there.
BEN VINEGAR: Kyle had a comment.
KYLE SIMPSON: So I think going back
to the Unix philosophy, which certainly informs a lot of what
we're doing, it says have lots of tiny little tools
that can be woven together.
And I think that's the more appropriate way of doing this.
When you get to the point where you've
decided that there is a particular flow
through those tools that make sense for you,
you write yourself a bash script so you
don't have to repeat it again, and that's all you need.
In the JavaScript world, when you have a set of API calls
through these different tools, you just
write yourself a little Node script
that repeats that process over and over.
So I don't think we need to worry so much about, oh,
there's too many details here.
You just wrap a script around it and then
you don't worry about those details if you don't want.
GARETH RUSHGROVE: I think the thing
is you said "for me" and "I write."
I think actually, sharing that unit for some people
is really valuable.
Some people in this room are going to go,
I'm a really good programmer, and that's
exactly what they're going to do, and like Remy was saying,
some people in this room are not.
They're going to, I have no idea what all these steps are doing,
but I want the magic from people who
are really smart to do it for me.
KYLE SIMPSON: So I just make a Gist and then I tweet it out.
That's my solution to that problem.
ADDY OSMANI: So one of things that we tried to do with--
AUDIENCE: [INAUDIBLE] the non-technical people
in the room.
[LAUGHTER]
GARETH RUSHGROVE: Distributing really usable software is hard.
Packaging that up into something that
is just easily usable off the shelf
by someone who does not understand what's going on
in the middle is hard work, but it's valuable.
Instead of these millions of plug-ins,
there's probably two or three good ways
that would be good enough for 80% of the people.
ADDY OSMANI: One of the things we
tried doing with Yeoman is actually
trying to provide people with opinionated workflows,
especially when it comes to things like performance
and what we think people should be doing.
Because a lot of people don't know
exactly what they should be getting in their build process
to actually keep their pages fast and so forth,
or what build tasks they should be
using, whether they're using Grunt or Gulp.
So there do exist solutions to help you
with opinionated stacks for the stuff,
but at the end of the day, if you
find those too much and too overbearing,
you can always just use them for reference in the same way
that people use HTML5 boilerplate.
Just take what you want.
Delete key friendly the rest.
BEN VINEGAR: Just going to go back to Peter here.
AUDIENCE: I'd like to touch on Kyle's point about the Unix
philosophy.
I love the Unix philosophy, small tools
being able to chain them together.
The thing is that Unix pipes work
with text and web files are not text.
We would need to be able to pass objects
like we can do in PowerShell.
The thing is some of the things that are really, really
difficult to do with the existing build tools-- revving
files, concatenating files, all that stuff-- are things
that both Grunt and Gulp do really badly,
actually, because they're based essentially
on a continuation of the Unix philosophy or the Make file
philosophy.
GARETH RUSHGROVE: I touched on earlier, steal things
from things outside your community,
and one of the things to steal from is PowerShell.
For those that are familiar with that Unix philosophy is all
chaining small things together, PowerShell
adds basically a full object in between those things,
and you can do a lot more with that.
KYLE SIMPSON: I don't think we need that.
Not that it's bad, but I don't think
we necessarily always need that.
If you look at the flows for JavaScript tooling-- parsers,
analyzers, transpilers, code generators,
and that whole flow and that round trip.
If you look at that, they decided
we start out with source code and then we
move to a tree format, and there's a relatively agreed
upon tree format, the AST.
We're actually working on a more complete version
of that called a concrete [INAUDIBLE].
That's the thing that moves from tool to tool,
and then what you get out is more compiled code.
I don't think that's a big problem.
BEN VINEGAR: I feel like we've gotten a little off track.
We've moved from, is there merit to having, let's say,
a plug-in like Grunt-awesome that just does everything,
and now we're getting into the details of chaining and stuff
like that.
So maybe just to bring us back, just a comment over here.
AUDIENCE: [INAUDIBLE] because I think
a lot of the things in the Unix idea is to chain things
through, sort of in a functional way, you're taking output
from one thing into the next thing.
But some of the things we do-- and there's
one in Yeoman, the one that transforms.
You can run things.
It can take chunks of JavaScript and compile them
into different files, and it keeps state.
So it can do something at the start,
go through the whole chain, and then refer back to something
that happened, and that's the same for revving things.
You have to have some idea of the state of the whole system
to be able to rev things later on and go, right,
this is what has appeared.
So this whole idea of just having chains-- even in Unix,
you do stupid things where you might temp files
and you get into all this weird stuff
when you're trying to do something that just
isn't fundamentally functional.
It always goes back to, I'll just do it the Unix way,
but there are some things that just
can't be done that way very well.
BEN VINEGAR: Any comments on that?
NICK FISHER: Yeah.
That's what I was saying.
This build script that we use has
a lot of these things that at the start,
we find all the assets, and then we
have a state that is then used later on.
The downside of that is that it means that you can't really
share your tools very easily because it's
very specific and bespoke to your application.
I know one of the themes that's coming here
is sharing and helping people get into community,
but there's the other side, which
is I want to build the best app that I can
for me, which might sound a bit mean, but that's my job.
I'm pretty sure everyone else here
has got a job very similar to that as well.
And you shouldn't forget that.
Sometimes, you do have to just do something
then you can't open source.
That's fine.
BEN VINEGAR: I'm going to stop there.
That seems like a good closing point, me, me, me.
So I'm going to call on the next question.
Looking here from Ian Feather.
AUDIENCE: [INAUDIBLE].
Most of the pain in build process
occurs at dev iteration.
Would it make sense to implement things
like Sass and CoffeeScript as plug-ins for developers,
removing the need for repetitive build
processes, or even in the browser itself?
So I think he's talking about having extensions which
will allow you to iterate without having
to run the build process [INAUDIBLE].
BEN VINEGAR: Just to jump ahead of this before you comment.
This question interested me because what
I seem to read a lot about new tools,
like Gulp being produced, is that the speed of building
is actually becoming really important to people.
So what if we can just not have that at all?
Any comments?
ADDY OSMANI: Generally, I think we
were all in agreement about things like Sass and Coffee
not necessarily belonging in the browser.
We agreed on that earlier.
But I think in terms of your iteration workflow,
Gulp is commonly used by people because when you're actually
iterating on a project using Sass, it's a little bit faster.
Whenever you make a change and you
want to see that refresh in the browser,
you don't necessarily have as much of a delay
as you perhaps do with Grunt.
It's not a massive difference but it's
important enough to people that they sometimes
consider switching over.
I think that we need to look at how we can actually
keep our tools lean and fast where possible
to improve on that.
GARETH RUSHGROVE: It feels like it's a software thing.
What you're saying is, well, I have a slow build script,
and I bet those browser people have
got some really good coders who can
do exactly the same thing faster.
It's like, well, maybe, or you could
find someone else who can re-engineer your build process
to be faster.
Ultimately, you're doing the same job,
you're just doing it in a different place with code.
If Node isn't fast enough, write ANC.
PRESENTER: [INAUDIBLE].
SEBASTIAN GOLASCH: I think the thing is we're web people,
and we're used to hitting F5 or Control R, and refresh,
and it changes, not like the Java guys who
could grab a coffee while their thing is compiling.
I think we should really embrace that and not
build tools that are watching in the background a file system
and then doing something for 10 seconds
before we can see the change in the browser.
That's not the web and I think that's totally
heading in the wrong direction.
You have Sass and stuff, OK, but really don't overdo it.
Just keep it clean and simple.
NICK FISHER: I think one point here
is to consider your total build separate to your development
time.
Things like watches can be good, or running a local server that
compiles these things on the fly and can give you
a good enough representation of the production
build while you're developing.
If your build script takes less than five minutes, that's fine.
Above that is a problem, but less
than that I wouldn't care, as long as when you're developing,
that feedback loop is very short, and do
that through file watching, serving
individual files on the fly.
If you separate those two ideas, then I
don't think you hit this problem.
KYLE SIMPSON: Just real quick, one area
that definitely needs to get better with those tools
is the incremental recompile.
So just because I change one Sass file doesn't mean I really
actually want to recompile the entire damn directory,
but that's often what happens.
So if we could get smarter tools that it could understand,
I only need to recompile this one little part of this one
little file, that would certainly
speed up a lot of that time.
BEN VINEGAR: A comment here from Jake Archibald.
He's right in the middle.
People can't decide which mic he's going to get.
AUDIENCE: Aside from the performance issue,
if the browser understands Sass or CoffeeScript,
doesn't that make tooling better?
We've got source maps at the moment,
but that is just a basic mapping.
Wouldn't we get a lot more if the browser actually
understood the other language?
ADDY OSMANI: When you say the browser understanding
other languages, I think we need to realize that it's not just
about Sass and Coffee.
It's about Sass and LESS and Stylus
and other crazy thing that's been created
while people are sitting in this room.
We have to define limits about how we can actually
go about supporting these things and what
we support because if the browser were to support that,
that goes back to one of the earlier questions
about having some sort of a preprocess step
where the browser could perhaps call out to external tools
to actually get the job done.
That's realistically the only way
I can see it being done without you baking in support for Sass
into the browser directly.
GARETH RUSHGROVE: It comes back to the
build process thing as well.
It's still a build process.
It's just you've split it over the browser and your code.
That could be fine.
And yeah, getting it into the browser
is probably easier than getting it into a standard,
but it's not easy as grabbing a plug-in
or writing some code yourself.
There's this barrier to entry there.
Yeah, it's not quite the standards thing, but still,
grabbing like the [INAUDIBLE] and adding that feature
and getting it through a process whereby
it's fit for everyone else to use,
much higher barrier to entry.
KYLE SIMPSON: Someone earlier said,
and I think it bears repeating, as soon as you put something
into the browser, now it's going to move a whole lot slower
in terms of change.
So I don't think we ought to put Sass in there
until we're really sure that it's pretty much done,
and I don't think it is, so I think we need to keep separate.
BEN VINEGAR: First comment over here from [INAUDIBLE].
AUDIENCE: [INAUDIBLE], when you said ramping up people,
I think the web started and became so big because it was
easy to write something, put it in a browser, and see it.
When I see a lot of people tweeting, that people look up
to, that tell people, if you want
to start with web development, go to the command line,
get a Ruby Gem, do this, do that, do that.
It's no wonder we're using new developers
to close platforms instead of the web.
So could we do a better job in actually promoting power tools
only to power users rather than saying start with this?
PRESENTER: I think so.
BEN VINEGAR: Actually, got one more question coming up
that I think basically captures this,
so I think we're just going to jump to that also because we're
running low on time.
I should have queued this up ahead of time.
This is awkward.
I swear it was here.
KYLE SIMPSON: Let's start addressing this question
while you look it up.
BEN VINEGAR: It's more finding the person who speaks it.
PRESENTER: Who's got that question?
BEN VINEGAR: Let's go to the audience.
It's a question about, is tooling taking us away
from these fundamental building blocks?
You do?
Yeah.
PRESENTER: Crowdsourcing.
ADDY OSMANI: I think that the fastest iteration loop today
is probably just sticking directly
with HTML, JavaScript, and CSS.
Only use these power tools when they're actually
going to be genuinely useful to you.
That's at the core of what you're saying,
and I don't think that we should move away from that.
If you're just hacking away on something,
there's no reason not to stick with those tools.
Where all this other stuff becomes important
is when you're trying to develop for a large system
or something that's going to go out to production,
and you want to make sure that if someone's
accessing something on a slow network on a phone,
that it's actually still fast.
BEN VINEGAR: Addy, going to-- also,
can you say your name because I don't have it in front of me?
AUDIENCE: My name is Florian, and the question obviously
has been rewritten, but it covers my question exactly.
As build processors become more and more complex,
our source code gets further away
from the fundamental building blocks of the web--
JavaScript, CSS, and HTML.
How does this affect future maintainability,
and is this a good thing?
KYLE SIMPSON: Yes, it's a good thing
because we all pick our various levels of abstraction.
Some people loved writing in assembly,
some people didn't, so we picked a higher level of abstraction.
So all of these extra tools and things, when you decide-- I
say this all the time.
Source code's not for the computer.
It's for the developer.
Computer just cares about ones and zeros.
So you choose ClosureScript because you like something
about that tool and the way that allows you to express
your code, and that makes you a better and faster and more
efficient developer, so that's a good thing.
BEN VINEGAR: So to play devil's advocate for a moment, what
about all the resources that we've put behind HTML and CSS?
MDN doesn't have CoffeeScript examples.
W3Schools does not have Sass examples.
We have this huge base of knowledge,
and are we getting away from that?
Is that necessarily bad?
SEBASTIAN GOLASCH: I think back in the day,
we looked for developers for the web,
and they must understand HTML, CSS, and JavaScript.
Today, we're looking for TypeScript developers,
Sass developers, and not--
KYLE SIMPSON: Who's looking for TypeScript developers?
GARETH RUSHGROVE: Certainly when we're hiring, we're not.
On the programming side, we're looking for programmers,
and on the front end side, we're looking
for people with a really good understanding of HTML,
CSS, JavaScript.
And the fact is everything else, they will learn.
We write a lot of Ruby code, and we've hired actually
a relatively small number of people
who were proficient in Ruby to start with,
but they were programmers.
SEBASTIAN GOLASCH: Then you're doing it right,
but I've seen job descriptions with lists of tools.
In the end, you don't need to know all of them
but we just lined them up because they're so popular
and we want to attract people to work for us.
That's stupid.
ADDY OSMANI: This is where you get job descriptions
like 15 years AngularJS experience.
GARETH RUSHGROVE: But we're not going to fix that.
NICK FISHER: I think to go to what Chris was saying
about how scary it is for a new developer,
I don't think that should hold us back.
I mean, you can still have the tutorials.
They're definitely very worthwhile.
But JavaScript is where it is now
because we didn't let it hold us back.
We did start building upon it and create
really amazing things with it.
And the more that people do the amazing things,
that's even better.
I don't think necessarily having a zero level entry
barrier is a goal.
BEN VINEGAR: Just want to get an update from Florian here.
AUDIENCE: I think you're not really
addressing my question because what
I'm worried about it is I'm writing code today,
and it may be Sass, it may be CoffeeScript.
And in five years' time, I go back to that code
and I can't run it anymore because it's not standardized.
All I can run is my previously compiled code,
and the output is--
NICK FISHER: I think that should be a serious consideration
before you choose one of those tools.
GARETH RUSHGROVE: Different organizations as well
are going to have different thresholds for that.
Because if in five years' time, your startup has either
been sold, at which point you don't care, or it's gone bust
and you don't care, actually probably optimizing for right
now is massively important.
Government stuff, yeah, I'm not going
to choose something that's not standardized.
ADDY OSMANI: I was just going to say
that if you're choosing an abstraction,
you're almost marrying yourself to it.
You can't expect Sass necessarily
to be the thing that people are going to use in five or six
years' time from now.
You can expect people to still be
using CSS, though, and probably JavaScript, and probably HTML.
So sometimes, staying closer to the grain
is not necessarily a bad idea.
But to add to your point, a lot of the time these days,
people are just trying to build stuff that works now.
You need something that's maintainable for right now.
If that makes sense, sure, use these new tools
to augment your experience and make it easier
for you to develop.
But I think that our abstractions
are something that are not going to be around forever.
BEN VINEGAR: Well, we're out of time,
so I think that's a good place to end.
Just want to thank all these amazing panelists
for their thoughts and opinions, and I
want to thank you guys for being here.
[APPLAUSE]