 Hello, Tess. So yeah, 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 Fine Engineer at Discuss. I also wrote a book called The Prior JavaScript. It's pretty terrible. I have five wonderful panelists with me. First, there's Kyle Simpson. Who you may know is the author of LabJS. He's also an 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 application with some cool stuff going on. Adi Asmani, who develops Todo MVC and Yeoman, which is a scaffolding tool, working with Grunt. And he also works on Chrome Dev Tools. And then Sebastian Golasz, who works for Deutsche Telekom. I practiced pronouncing that for a while, working on a product there that also uses older traditional build tools, like if older's the right word, but with Maven combined with Grunt and some clients and 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 bring them into the modern era. And with that said, Gareth is just going to start us off with a quick presentation. Slides up. Do I have to do anything? Yeah. Ooh. OK. 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? I think 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, well, 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, oh, 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. And certainly for some people, people come to certainly front-end engineering, front-end 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 software types of things that we're putting into our build process? And Ben mentioned a few things that will be common to lots of people in the room, sort of 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 sort of like 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. Like 30,000 installs of this every day, that sounds quite a lot. That's a lot of interest. That's a lot of people. There's 2,500 Grunt plugins. And I'll come back to why that might not be great in a moment. There's actually 450 Gulp plugins. And that's a tool that's not being around anywhere near as long. But I said, I'll come back to why that might not be good in a moment. Contrib.js is a Grunt plugin. And 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, who's building another one and hoping someone comes along and builds another one, Dash Coffee and JSN and everything else. And we know there's 2,500 Grunt plugins. Do we want 2,500 Gulp ones and Broccoli ones and everything else? And it's not just about the sort of, I think there's probably a lot of front-end people in the room. There's probably not like people writing JavaScript, writing CSS, writing HTML most of their time. Is that fair to say? Any purpose person going, I'm basically just a Java programmer? That's part of how we do that. But we're all working in environments where there probably is a back-end that might not be written in JavaScript. Maybe you're using Node. Maybe you're not. Maybe it's Ruby. Maybe it's Python. Maybe it's C sharp. It doesn't matter. There's a lot of other things going on around you. They also have build processes. And there's loads of build tools, whether it's Maikar and Maik, Maven, NAM, SPD. There's loads of these. There's a bit of a hit 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 having standardizing on things, standardizing things in silos probably isn't enough. Even when it comes to sort of typical tasks around front-end engineering, a lot of those have plugins or projects related to other build tools that are doing it. Whether that's sort of multiple versions of things like Django static compiler or compressor versus sprockets in Rails versus aesthetic in PHP. There's this spiraling mass of all these things doing fundamentally the same jobs. And really sort of everything all is new again. Building software is not new. It's maybe new to, these tools are new, Grant and Gulp. There's a lot of interest around sort of programming in 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 have been made. Some of the learnings have not been taken forward. Maik is older than you probably. I wrote this before turning up. I still think that's broadly true. Unless you're 37, Maik is older than you. There's a few people here who probably look older than 37, but I reckon. Most of you, I'm gonna go far, Maik is older than you. Maik 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 Maik rather than Grant. And do you know how many Maik plugins there are? I don't think there are any. That's probably gonna be completely untrue. But basically there aren't really Maik plugins. There aren't really plugins for LS as a Unix command tool. The reason is because Unix pipes are amazing. Or the concept of simply chaining things together by sending information between them. So LS doesn't have a grep plugin or a sort plugin. And 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 plugin models. And I think sort of, actually I don't do a lot of front-end stuff. I haven't done it for quite a while. So actually I did a whole bunch of research into sort of like 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. And this isn't just true for this community. That's true of basically programmers, myself included. But we invariably invent things, like reinvent things in our language of choice. And sometimes in our tool of choice. But the thing we often miss is that's our language and tool of choice at the moment. And that probably changes over time. And 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. They're like having tools is good. This is not about saying, oh, we shouldn't have done any of that. Like throw it all away. It's about how can we make it a lot more sustainable? How can we learn from maybe like 20 odd years, 30 odd years of other programming communities build processes? So what is the most valuable unit of sharing? Is it a plug-in? How can we build community consensus and like avoid the plug-in apocalypse? I like that. I think there's a genuine problem there. Can we share entire pipelines as well as tools? And it's fine sharing the individual bits, but actually we probably then all take a collection of things together and string it together to do the same thing. And actually can we share the pipeline? And is that a better unit of sharing? And importantly, how do we break down some of these artificial programming language silos? Because even if you're thinking, well actually my career is going to be all about front-end engineering, it's all going to be about JavaScript and CSS and HTML. And they're probably going to change, they're going to evolve, they're going to get better, the tools around it's going to get better. But that's what I'm going to do. You probably do it in a context where other people around you are writing different programming languages. And how do we mix it? So there's not that culture class. 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 that I sort of care about. The panelists might violently disagree with some of that. So with that, we can go onto the panel. So thanks, Gareth. I think that was a pretty good way to start us off. There's a question I'm looking for. Oh, God. Is that kind of browser thing that's been moved around? Oh, boy. I'm going to ask on Cornell Lasinski. And also, I just want to say, I feel that we butchered your question slightly. And if you would like to go original with this, please do so. So 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? So one of the really nice things about the extensible web manifesto has been the community starts to iterate on features in 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 SAS and less directly into CSS. The same thing is being done with mixins. I think that it's perhaps not necessarily the browser's responsibility to provide hooks into your build process like a preprocessed step or a post-processed 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. So I want to jump in, because they asked me to be on the panel so that I could disagree with everyone. So 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 that 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 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 sort of 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. 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. That would be awesome. I think fundamentally, the friction around standardizing things is it takes time and it's hard 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 at any time soon. So therefore, it's the stuff that we can fight about that goes in our different build processes. I kind of 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 in 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 decide to do that, say, 10 years ago, we might have a very different language today. So I just sort of like tack on to this, which is that 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 or 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 than SAS features into CSS, would we even get it right? Would it be fun to work with? I think it's OK for these tools to inform standards, but I think we should draw a line and say not 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 ES6. And I think those, you know, I don't like all of them, but that's good that we were able to inform that. But I don't think that it would be a good idea for CoffeeScript to natively start being in the browser. I think that's a build step. 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. 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 like, if it doesn't make sense, you can throw it away. If it's 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. There was also a second part to Cornell's question, the original question. I don't know that you touched on it exactly. I was hoping that he would. But it was about, should the idea of preprocessing itself be a standards feature? Like, 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 preprocessed step versus a runtime step? I'm looking for a nod from you. Does this seem to have a capture of that? So why not always 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. Like, $9 in JavaScript. Any comments on that? 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 LessonSas that do belong in the CSS language. And I'm glad that we've got tools that have sort of 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, well, really, should that actually be adopted, or should that stay in sort of the user lane? I think we need, as a community, to be more responsible with that decision. Okay. On that note, I'm going to bring us to our next question. I'm going to call on from the audience Ernesto Jimenez. So the question is, much of the new tools and processes are growing within the Node.js community and depend on the Node stack and NPM. Do you think this dependency might be limited in the future? So 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. And 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, well, 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 pre-processing, post-processing, and so forth? So I don't think that using Node is something that's stopping us. It's just gonna be about improving awareness of how okay it is to use things like Node and the command line when you're actually working. I think coming out of that from a completely different point as well is sort of Node's runtime. Yeah, whether someone's using command line or another tool, it's just something that's actually occurred. For some environments, that is a barrier to entry. They're not going to put Node on their environment. That's fine. That's gonna happen. One thing that is happening though, because I think there's been a lot of interest in the tools that have been built on top of this, people, there's certainly some work around basically embedding a Node runtime in the JVM for environments which is same, seems to be saying like, we're not gonna install this random new tool, but we are happy with running all this JavaScript. So I think, and that becomes a less limiting factor over time, the tools will be able to be run in different places. 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. It didn't survive Rhino and now Nashor. 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 developer tool, I'm sorry, not a developer tool, 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. So, okay, go ahead. So if we think like five years ago, we didn't have Node and back then we did like 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 sees as an HTML besides. Or didn't want to. Or didn't want to. Well, 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 they can embrace like this whole plugin ecosystem or whatever. And I think that's a really good thing. I wanna 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 NPM. So, I think everyone seems to be pretty positive on Node but what about this idea that there's a huge dependence on NPM as a package manager and then the NPM repository for which I think it's fair to say there's been some bumpiness too. What are you talking about? Well, bumpiness just in case to contextualize this, like for example, I think a month ago, they changed their certificates, their security certificates without notice. And then I think a lot of people who had dependent on Node, they just couldn't download packages for a day and there was no instructions, there was no communication about what had happened. Just as an example point, it's not the only one. Would anyone wanna touch up on this? Perhaps I'm gonna start with you. I think that's gonna 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 NPM. I think NPM'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 all together, 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 NPM itself is an issue there. Well, NPM is actually, if I understand, isn't it, it's sort of like a protocol that you could theoretically, and I know companies do, spin up their own NPM instances. So we don't necessarily have to think of NPM as the one global universal repository. It can be a way to get your own company internet 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. So we don't have to discount those as the place that we keep repositories. Google the audience here, I'm sorry, I don't know your name, but do you have a comment on this? Oh, your name's on your badge, well, Jonathan. So we have the issue as well that a lot of these tools are now being stored in GitHub, a GitHub's a company and we're relying a lot on GitHub, so what should be done so we can get just distributed so we can technically use lots of different videos. Yeah, don't use GitHub. Yeah, use Git, not GitHub, use NPM, the protocol, not NPM, the universal repo. But what about the idea that, so I mean, obviously you can spit up your own thing, but NPM is now, it's a private company, right? And if you go to other languages where there's PyPy and there's Gems, those are all actually community efforts with Sponsored, as far as I understand, right? So does that change the landscape at all? No? All right, let's throw it out there. I'm sure it does change the landscape. I would love to hear from Gareth. 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 a 0.1 release and not a 1.0, 2.0, 5.0 release that can be trusted? So the version number thing is nearly red herring. It's like it's an arbitrary string, basically. It's only representing value in the I of the author and so you can just go, well, if someone goes, oh, well, it's got to be one. Like if you tell the author, they might just make it one. But there is a, and ultimately, different organizations will have different, sort of like, like risk appetites. And that's true of, like, so I work with the government, yeah, there's going to be banks, there's probably going to be like 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 to JavaScript, specific third party package math services, which broadly, like, sort of having one per language was a stupid idea. It's too late to fix it. So the next new language that comes around will probably have an NPM or a Ruby gems. It's a bit of a shame. The package management systems within operating systems sort of solve a lot of the problems and people forget about the problems they're solving. CPAN for Perl does loads of, like, really interesting stuff that no one's recreated in the last 10 years. You guys, we're gonna, we're gonna, oh. One addition. I think one thing that will help us with at least the security concerns about using NPM is when NPM 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 gonna be there and not something different because someone hijacked it or something. So it solves the sort of mental issue. It doesn't solve the fact that someone might have compromised the person who was uploading it in the first place. In general, isn't it, I find it always fascinating. Guys, sorry, I'm getting, I'm getting thrashed to get to the new topic. Okay, cool. So we could go to the audience again. And I think this is a pretty exciting question. Oh, I guess I'm not going to the audience. I guess I'm supposed to ask Kyle Simpson to ask a question. 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 many browser wars going on right now between grunt and gulp. And we twit around with having you all have to stand up and declare where you are on that, but we won't. But there's several other would-be congenders. 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? I think that traditionally having multiple tools is a good thing because it drives innovation. And I don't think that 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 sort of standardizing on perhaps a task specification. I know that there's been some effort from different build tools to standardize on the no task spec, which talks about things like having a single way to handle records or logging or notifications and so forth. I think that that could actually help us avoid having to sort of have this sort of crazy wheel of re-implementing things all the time. But I know it has its own challenges. 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, for certain situations, but they are kind of glue that sticks together interesting things. I think the discussion and browser war type arguments going on, well, I'm not sure if that'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. Like 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 and, I don't care. It's like what we actually do in the build process which is actually important. I would personally like to see less people re-implementing grunt coffee, gulp coffee, whatever, and just have coffee, just use that and hook into it any way you want. So you feel like we should get closer to the grain and just actually call the existing tools rather than writing like wrappers around this. It seems to be interesting. 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. I was going to write up some months ago about, 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 sort of 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 plugin 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 okay 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. So I think that's the reason why plugins exist. Everybody wants to make it so that their tool is the one that blows up and gets 10 million stars on GitHub. Sebastian, you had a comment there. I mean, the thing is with all these dependencies, with all these plugins, when we say, okay, we have a common interface, so we only have one plugin that works with all of the systems, perfect. I mean, 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 it with grunt and gulp and brokely and fast or whatever. I mean, if you're a node developer, gulp.js feels more familiar with all this stream stuff. So you can write it because it feels more familiar. And if you're a front-end developer, most of them like grunt more because it's like this declarative approach where you only have to configure things. And I think it comes down to use the right tool for the job. Okay, I'm gonna go to the audience here because there's like a bunch of hands going up. Just first over here and then Remy. Well, my friend here is actually gonna be out of use. Oh, oh, sorry. Yeah, so disclaimer, unfortunately, I'm one of these people who has also developed another build tool for Hammer. So I agree with everything we've said. And I think the idea of having interop between plugins 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 parts everywhere. So to me, the real question is what is the good baseline for these tasks that would work in different tools so that it does the right things? And just to throw a few examples is should it be able to produce source maps correctly for everything by default? Should it be able to rebuild partially so you don't have to rebuild all your things every time? And all these things I think need to feed into what is the common format for these big tools? I think one of the really big challenges with coming up with a spec for build processes and 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. And unfortunately, so 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. We talk about something like, oh, it's good to have multiple tools because that breeds innovation. Don't think you can't get locked in to an open source tool because you can. It's not just commercial stuff. We're talking about lock-in. You get yourself locked in by something by saying like, you know what, the barriers to moving from this tool is so great, I'm not gonna do it. At which point you benefit not one bit from the innovation coming from all the tools. Okay, can I get a quick comment from the audience here from Remy Sharpe? Yes, I mean, I don't personally use build tools at the moment. There's one step, but the thing is, jQuery was the tool that made working with JavaScript really stupid simple for a large amount of people and suddenly they were able to write JavaScript without writing JavaScript. And these big 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 were doing it. It's all about getting locked in. I don't think it matters at this point. The build, like 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 their stabilization in five years time, then that's a huge step forward compared to just not doing it at all and just delivering massive images out of wire, uncompressed images, we're still at that very, I think we're still at that very early days of when jQuery was kind of really spinning up the charts with us. 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 and image compression. That's the thing, images are the thing that are slowing down the web today. And we need to get more people caring about those problems and spend more time talking about how we can actually speed up our pages in less time, perhaps, on arguing why you should be using gulp versus grunt. I mean, there's still fantastic tools that I think Sebastian said earlier, people who are more familiar with note are perhaps gonna use gulp and people who aren't are just gonna use grunt and that seems to be working. I know. I'm gonna cut you guys off because actually the next question, I think it goes into just what I was touching on. I'm looking for, from the audience, Peter Mueller. I will 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 opinion at a build chain that just gets us to the end point that we're interested in? I like to see what's going on. Yeah, so like from my experience, like I've built an opinion at a 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, you actually get, like if you really want to get total performance out of your build process and on 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. Kyle had a comment at the start. Yeah, 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 makes sense for you, you write yourself a bash script so you don't have to repeat it again. And that's all you need. And 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 have to worry about those details. I think the thing is, you said for me and I write, and I think actually sharing that unit for some people is really valuable. Some people in this room are gonna go like, I'm a really good programmer. I mean, and that's exactly what they're gonna do. And like Remy's saying, some people in this room or not are gonna go like, I have no idea what all these steps are gonna do. So I just think- But I want the magic from people who are really smart to do it for us. No, I just make a gist. And then I tweet it out. That's my solution to that problem. So one of the things that we try to do with the- Can't you reach the long term if the people- Yeah. Yeah. Yeah. Yeah. Seriously? Distributing really usable software is hard. Packaging that up into a sort of 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 like it's valuable. And there's probably two off, like instead of these millions of plugins, there's probably two or three good ways that would be good enough for 80% of the people. So- So one of the things we try doing with Yaman is actually trying to provide people with like 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 using like grunts or gulp. And 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, right? In the same way that people use HTML5 boilerplate, just take what you want, delete key-friendly the rest. Just gonna go back to Peter here. Yeah, 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 webs of files are not text. We would need to be able to pass objects like we can do in PowerShell. Yeah, as well. Because 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 Matefile philosophy. I touched on earlier, steal things from things outside your community. And one of the things to steal from is PowerShell, because for those that haven't come, that are familiar with sort of like that Unix philosophy of sort of chaining small things together, PowerShell adds basically full objects in between those things and you can do a lot more with that. But I don't think we need that. If you look at, 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 syntax tree. That's the thing that moves from tool to tool. And then when you get out is more compiled code. So I don't think that's a big problem. I feel like we've had a little off track. Is there merit to having a, let's say like a plug-in like Grunt Awesome that just does everything and whether now we're getting into the details of chaining and stuff like that. So maybe just to bring it back. Just a comment over here. Why would you do that? Because I think a lot of the things, the unit's idea is to chain other 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 Yoavun that is the one that transforms. You can run things. You 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 revision, 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 write temp files and you get into all this sort of weird stuff when you're trying to do something that just isn't fundamentally functional. So we always go back to that. I'll just do it in Unix way. But there are some things that just can't be done that way in very well. Any comments on that? Yeah, that's kind of what I was saying. Like this build script that we use has a lot of these things that like at the start we find all the assets and then we have that state that is then used later on. The downside of that is that it means that like you can't really share your tools very easily because it's very specific and bespoke to your application. And I know like one of the themes that's kind of coming here is like sharing and helping people get into the 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 like that's my job. And I'm pretty sure everyone else here has got a job very similar to that as well. And that you shouldn't forget that. That sometimes you do have to just do something that you can't open source. That's fine. I'm gonna stop there. That seems like a good closing point. Me, me, me. So I'm gonna call the next question. I'm looking to hear from Ian Feather. I'm very embarrassed. Most of the pain in build process occurs at depth iteration. Would it make sense to implement things like sass and copper script as plug-ins for developers removing the need for repetitive build processes or even in the browser itself? So then he's talking about having extensions which are allowing to iterate without having to build a process. 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 Gullfin Produce 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? I mean, I'm 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 that in terms of your iteration workflow, so 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 see 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. It feels like it's a software thing. Yeah, 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. And 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 a different place with code. If no one isn't fast enough, write it in C. So it's Sebastian's idea. I mean, I think the thing is we're web people and we're used to hit F5 or control R and refresh and it changes. And not like the Java guys who could grab a coffee while their thing is compiling. And I think we should really embrace that and not build tools that are watching in the background of 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 SaaS and stuff, okay, but really don't overdo it. Just keep it clean and simple. I think one point here is to consider like your total build separate to your development time. Things like watches can be good or like running a local server that compiles these 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 there's 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. And then if you separate those two ideas, then I don't think you hit this problem. One area that I think definitely just real quick, one area that definitely needs to get better with those tools is the incremental recompile. So just because I changed one SaaS 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. I want to get a comment here from Jake Archibald. That's right, middle. People can't decide which mic he's gonna get. Aside from the performance issue, if the browser understands SaaS 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? I think that we... When you say the browser understanding of the languages, I think we need to realize that it's not just about SaaS and coffee, it's about SaaS and less and stylists and other crazy thing that's been created while people are sitting in this room, but 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 us having some sort of like a pre-processed step where the browser could perhaps call out to external tools to actually get the job done. Because that's realistically the only way I can see it being done without you baking in support for SaaS like into the browser directly. And it comes with the build process thing as well. It's still build process. It's just you've split it over the browser and your code. That could be fine. And yeah, getting into the browser is probably easier than getting it to a standard, but it's not as easy as grabbing a plugin or writing some code yourself. So I think there's this barrier to entry there. Yeah, it's not quite the standards thing, but still grabbing the Chrome's OS code and adding that feature and getting it through a process whereby it's fit for everyone else to use. Much higher barrier to entry. Someone earlier said, and I think if there's repeating, as soon as you put something into the browser, now it's gonna move a whole lot slower in terms of change. So I don't think we ought to put SaaS 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 it separate. First comment over here for me. Quick one, when you said like ramping up people, I think the web started and became so big because it was easy to write something put in the browser and see it. And when I see a lot of people tweeting like that people look up to that tell people if you wanna 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? I think so. Sorry, I actually got one more question coming up that I think basically captures this. So I think we're just gonna jump to that also because we're running low on time. Boy, I should have queued this up ahead of time. Oh, boy. Oh, this is over. I swear it was here. Let's start addressing this question while you look it up. Yeah, yeah. It's more like it's looking, finding the person who speaks it. Who's got that question? Let's go to the audience. It's a question about is tooling taking us away from these fundamental building blocks? You do? Yeah. See? Crowd-sourcing. 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 gonna be genuinely useful to you. That's I think that 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 like a large system or something that's gonna go out to production. And you wanna make sure that if someone's accessing something on a slow network on a phone that it's actually still fast. Right? So, Adi, you're just gonna... Sorry, go ahead. Also, can you say your name? Because I don't have a problem. Yeah, my name is Lorie. And the question obviously has been rewritten, but it covers my question exactly. As build processes 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? 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 closure script 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. So to play just devil's advocate for a moment, but what about all the resources that we've put behind HTML and CSS? We have, MDN doesn't have copy script examples. And W3Schools does not have SAS examples. We have this huge base of knowledge and are we getting away from that and is that necessarily bad? I think back in the days, we looked for developers for the web and they must understand HTML, CSS, and JavaScript. And today, we're looking for TypeScript developers, SAS developers and not... Who's looking for TypeScript developers? Yeah, I said, like, when, I'm... Yeah, certainly when we're hiring, we're not. Like, we're looking for... Like, on the programming side, we look 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'll learn. So like, we write a lot of Ruby code and we've hired actually relatively small number of people who were proficient in Ruby to start with. But they were programmers. And you're doing it right, but I've seen job descriptions with lists of tools and it's like, oh, in the end, yeah, 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. It's like, that's stupid. This is where you get job descriptions, like 15 years of AngularJS experience. I think to go to what Christian was saying about, like, how scary it is for a new developer. I don't think that should hold us back. I mean, you can still start with, you can still have those tutorials. They're definitely very worthwhile, but JavaScript is where it is now because we didn't let it hold us back. That 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. So I don't think necessarily having a zero-level entry barrier is a goal. Just want to get an update from Florian. It didn't, I think you're not really addressing my question because what I'm worried about is I'm writing code today and it may be SAS, it may be JavaScript. 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... I think that should be a serious consideration before you choose one of those tools. So one of the challenges with choosing... Different organizations as well are going to have a different threshold for that because if in five years' time your startups either been sold at which point you don't care or it's gone bust and you don't care, actually probably doing what they're optimizing for right now is massively important. Government stuff, like, yeah, I'm not going to choose something that's not standardized. Adiotto, come on. I mean, I was just going to say that if you're choosing an abstraction, you're almost marrying yourself to it. And you can't expect, you know, you can't expect SAS to necessarily be the thing that people are going to use in five or six years' time from now. You can't 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 and you need something that's maintainable for right now. And 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 they're not going to be around forever. 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. Thank you guys for your time.