 Good afternoon, everyone. So my name is Shashrotha Ghosh. And I want to start with saying that it feels awesome to be here today. Now, this is my first Watt camp. And I just love the community. You guys are great. So you can find me on Twitter and on GitHub by the handle at the rate Shashrotha. Please mind the spelling. I want to say that I love WordPress and I love JavaScript. Right, right, right. With that being said, today I'm here to talk about front-end tooling for WordPress themes and plugins and the developer experience it brings. Now, please mind that it has nothing to do with that picture. That's not the developer experience that we'll ultimately have today. We'll have something better. So front-end development is really all about JavaScript, CSS, and HTML, right? So today we'll see about the new language features. Today we'll see the tooling around them and how everything is going to help us to build some really large-scale web applications. Now, when talking about language features, the first thing that comes into mind is ES6. Now, ES6 is the version 6 of ECMAScript programming language which was released back in the year 2015, hence also the name ECMAScript 2015. Now, it's a standardized name of JavaScript itself. And the point of the goal of ES6 and newer version is to provide us with language features which would ultimately help us develop really large-scale front-end applications. Now, for styling, we have many other languages apart from CSS like SAS, less. But today we'll talk about SAS. Now, SAS is unique in its way because it's a superset of CSS, meaning that although SAS is going to compile down to CSS itself, all your existing CSS files are also valid SAS files. Now, SAS by itself provides great many features so that you are able to make your styling grow as your application grows. And over the year, it has been battle-tested and approved by our industry. Then we have npmjs.com from where we can consume thousands of open-source JavaScript and CSS libraries. Press Next, please. So if I were to install and consume load- and axios, I would do so by simply running this command, npm i load-axios. And then from my application file, I would simply import them like any other ES6 module and I would execute them. Now, all these things together brings great many benefits. But today we are going to talk about the thing that matters to us most, us developers. And that is the awesome developer experience we get. So what is developer experience? Anyone? OK. No one? So developer experience simply is the experience that we developers get when we are building something. It's as simple as that. So it could be the tooling. It could be the language features. Or it could simply mean how we build and deploy our application. Now, we are all WordPress developers. So how many times do we find ourselves pressing the same refresh button again and again after we perhaps make some changes to a PHP file or a CSS file or perhaps a JavaScript file? Has it happened to you before? Please raise your hand if it has. It has happened to me as well. Please next. So let us quickly see three toolings which are very popular among front end developers. The first one is Babel. Someone call it Babel. Someone call it Babel. I try to stick with Babel. Now, Babel helps us use next generation JavaScript today. Not all ES features are ready to be executed in our browsers yet. But when we are using Babel, we can continue writing our JavaScript applications with existing or even upcoming features and have it compiled down so that the browser of our target audience can also run it. OK, so for SAS, we have many other compilers. But Lipsass and DirtSass are two very popular ones, which are officially supported. Both of them compile SAS language to CSS at an incredible speed. And both of them provide many automation tooling which we are going to see. And finally, Webpack. Here's some sound when you're talking about Webpack. Webpack, everyone. Webpack. OK. So Webpack is a static module bundler. Now, when using Webpack, we can have modular JavaScript code as well as modular CSS or SAS code. Press Next, please. And next. And Webpack can handle all sorts of assets, like fonts, images, anything, provided that we have the particular loader. And Webpack can use Babel and SAS compilers under the hood. Now, to set up an application to use Webpack, we have to do a little thing. First, we have to write an entry point. Now, entry point is basically a JavaScript file which starts the execution of our application. Once it's done, we tell Webpack to use that entry point and somehow bundle all of the dependencies and our assets through different source of loaders. Then we can have Webpack Dev Server to serve our application to search static HTML files, which in turn provides us with great many benefits, like live reload, hot model replacement, et cetera. We're going to see what those are. Press Next. OK, so I'm going to give a demo where I'll be showing a simple front-end application. Thank you. So what we have here is a front-end only application. And it's written in JavaScript and React. And it's basically, sorry, JavaScript and SAS. And it's basically a simple to-do application. Now, there's no backend involved. And we have used a very popular JavaScript library React here. And I'm not going too much into the implementation detail. Let us first quickly check our entry point. So this app.js file is our entry point. As you can see, it is importing dependencies from node modules, from it's importing a SAS file into a JavaScript file. And it's importing our application. Now, using JavaScript, we have added an event listener to the document. And we are telling the document that when you're ready, when the DOM content is loaded, ask React DOM, excuse me, to render our application in a particular DOM node. Now, with all the tooling set, we have this index.html file from where we have the DOM node. That is our div hash app. And we have the bundle JavaScript. Under the hood, we are using Webpack, which in turn is using Babel and SAS to compile everything and give us the bundle. So let us see what happens when we run the tooling. npm run start is the command which we have set. Let us hit Enter. And we can see that our development server is running at this URL, localhost colon 8080. So let's open it up. And there we have our to-do application, running hot. Now, if we were really developing this, we would probably change something in the source code. Let me zoom it so that we can see. So I'm going to go ahead and change the title of this thing. I'm going to go ahead and edit index.jsx file. And instead of awesome to-do app, I'm just going to go ahead and write, say, to-do application. Now, as I'm hitting the Save button, please keep your attention towards the browser. I'm going to hit the Save button in 3, 2, 1, now. Did you see what happened? So it's showing us the chain state of our application, and it didn't even involve a reload of the browser. So what really happened here? Now, Webpack is already watching all of our files. And whenever something is being changed, Webpack is compiling the file for us. And it's telling Webpack Dev Server that, hey, something has changed, and you need to refresh yourself. Now, this is where another concept called hot model replacement comes in. Let me show it to you. So again, we see our app.js, and we see this piece of code. So it's a way of telling Webpack Dev Server that if something changes from component slash to-do app, then we don't want the browser to get refreshed. No. What we want you to do is we want you to require the new module and then ask React DOM to go ahead and render the new application on the same DOM node. Hence, we see this effect that we are changing something, yet the browser is not getting reloaded. So that was some good DX, right? Now, please raise your hand if you thought that that was some good developer experience. Thank you. So the question is, can we do that with WordPress? And if the answer is yes, no, that won't work. Just right arrow, right arrow. Just press this, right arrow. So does it mean that we have to set up Webpack? We have to set up Babel and SAS and all those toolings. And we have to do it every time we start a project. And how do we even tell WordPress to use those things from Webpack? Because WordPress doesn't need to know about Webpack. And then we have seen that all those cool features like Live Reload and Hot Model Replacement came from Webpack Dev Server itself. Now, WordPress by itself requires a local development server. It could be VVV, it could be WampMap, it could be anything. So how do we connect Webpack Dev Server along with WordPress Development Server? Let us see. And once more. Once more. Once more. So let me introduce you to a new tooling that we have been working on. It's called Wpack.io. And it's open-source software, MIT licensed. And under the hood, it uses Webpack and Browser Sync. The goal of this tooling is to provide you to help you develop modern, large-scale, front-end heavy WordPress themes and plugins. Right out of the box, you get Babel, SAS, and many more compilers. It can work with any local development server you have. And you can have it integrated with your ongoing projects. And since it uses Browser Sync with the help of Webpack and DevMiddleware and with the help of Webpack HotMiddleware, it's going to provide you with a live reloading and HMR-enabled development server. Let us again see a quick demo. So here we are porting the same application as a WordPress plugin through a short code. Now, again, this project is all bootstrapped, so I'm not going too much into the implementation detail. What we have is the same app.js file, which is acting as the entry point of our application. Then, using this file, wpack.io.project.js, we are telling Webpack that, hey, this path is bringing you the entry point. So go ahead and compile that. Then for the plugin itself, this function is the output of the short code. As you can see, it's just returning a div with a particular ID. And using a PHP library that comes with the tooling, we are enqueuing the asset automatically. Now, with everything all done and set up, let us run the same command again. And there's one more thing before we can start. Now, I'm using varying vagrant vagrants here, which has given me this URL, wca.test, running on my own machine. So depending on your local development setup, you might need to change this. So let me go ahead and run npm run start. And we wait for it a little more. And there we have the URL open just for us. Now, just like before, we can go ahead and change our source code, because that's what we do. We can say to do app, to do app. I don't know how to spell. Save, and it's still live. Now, once we are done developing, we can simply press Control C or Q to quit the tooling. And then we can create production build with one single command npm run build. I'm sorry about the messed up output. It says the resolution. So now we have the development builds ready. So without changing anything within our source code, we can just go ahead and open the URL directly. And we still have our application running. Now, there's one last thing that this tool can help with. If you wanted to create a distributable zip file of your plugin, save for continuous integration, continuous delivery, or perhaps just giving it off to your client, you can go ahead and run npm run archive. Now, I'm going to show you some good output. And have it all packed and ready to consume for you. So that's all this tooling is going to help you with. So let me ask you this. Was it fun? If it was fun, please raise your hand. Thank you. So did you feel like a rockster having such tooling at your disposal to create some front end heavy application? Hell, yeah. So to take a step back and recap, front end tooling is awesome. Front end tooling brings the best developer experience ever possible. There's no beating that. And it's actually very easy to set up today. And front end tooling is very essential to create modern large scale JavaScript heavy application. And all of this can be easily integrated into WordPress. So thank you, everyone, for being here today during my presentation. I know I might have goofed up a bit. And if you have any questions, before I take my leave, if you want to check out all the demos, I couldn't show each and everything. If you want to check out the demos, this whole thing is available online at wca.wpack.io. So you can go ahead and check it. And I'd like to thank you, everyone, and the organizers for giving me the opportunity here. If you have any questions, please ask me on Twitter or during the tea break. Thank you.