 We've got our next talk from Alessandro Molina, who will be telling us about moving away from Node.js and on to Python, if you could all welcome him, there will be a chance for questions at the end. Thank you. Okay. Thank you. First, I would like to start by telling you why I decided to have this talk, because I know that probably many of you are already using a solution to transform and manage their assets, probably you have been using it with success for months here, I don't know, and probably in this solution Node.js is involved in many ways, at least to run the tools that perform the translation or the transpilers themselves or whatever. But I know that many people approach the solution that they are using today for the reason that they don't know there are other ways to do that. Most people have been doing that that way. If you look on Google or wherever how to do that, the first result is probably how to do that with Node.js, and so people have been approaching that kind of solution mostly because that's the way you are meant to do it. But there are actually very good alternatives that can solve also the problem of having to cope with two different languages. I know for sure that anyone in this room is a Python programmer, but I'm not sure that everyone in this room also is as proficient with JavaScript or Node.js or whatever. So having to maintain two different environments with their dependencies, different tools, different package managers, and install both of them on your at least development environment if not even on the production environment is not always what you want to do. So let's talk about something that probably happened in the life of every one of us, which is that you've been able to start your project using Python for everything. Your web framework is probably Python-based. You serve your API or even your web page through it. You are able to run it using a Python-based solution that you can write plugins for using Python. So we can deploy it using supervisors, like a whisky, whatever you are using that it's probably comfortable because you know you can go into the code and have a pretty good grasp of what's happening or write plugins for it and extend its behavior and so on. You're probably also deploying it using a tool like Salt Ansible or Docker Compose which are in Python too. And you probably monitor the state of your application using a tool like Sentry, Datadog, Backlash which have all Python agents, some of them even have backend code between Python and so on. So we are fairly able to do everything we want by going into the Python code, messing with it, extending its behavior, doing whatever we want in our stack. And that's only not true for the assets part because one day you probably go on holiday, you come back and the front-end guy introduce a whole new language, a whole new dependency manager, a whole new set of things in the project which now need to be installed through NPM, through having a new interpreter on your system and things like that. Which is not bad because Node.js actually has a really good set of tools for doing this as a good set of transpilers as most of them transpile to JavaScript and have been written by the JavaScript community, have been written, of course, in Node.js itself. They have a good set of tools to automate testing of your JavaScript part and front-end part. And there's a good set of tools to automate tasks like, for example, Granting Group, which are actually made to do that job and provide pipelines that transform your assets and things like that. So the side effect of this is that while it's a great tool and everything you usually need, you now need to have a package manager to manage the package managers because you have to be sure that in the environment you are working on, you will have both PEEP or the premade wheels if you use the binary distribution. You need to make sure you have NPM to be able to set up the working environment from scratch, at least on your continuous integration or on the developer's machines and so on. So you will need a tool that installs both of those. In most simple cases, it might be just an upget itself. In more complex cases, you might want to provide something like an Ansible script to actually deploy the working environment. Then you have two different places where you need to be sure to update your dependencies because we will have the dependency for NPM and we will have the dependencies for PEEP. And in the most simple case, two different people work on the two different parts of the system and they update each one their own dependencies. But in some cases, there might be features that cross through the bridge of the two parts and you might need to be sure that to make the front end of your new functionality added, you will need to add the dependency in both places and have the client and several side dependencies of your functionality and make sure that they get installed both otherwise your feature won't work as expected at all. So you will probably end up adding a third solution on top of all of these to actually manage this complexity. And there are many and so far there is not really a standard de facto to rely on. I mean, you can probably try to achieve this by using Ansible for everything. You can probably try to achieve this by doing pre-configured docked images. You can actually try to solve the solution in many different problems. But it's actually a problem that you should not need to solve because it has been introduced for a purpose that in most cases can be solved without introducing the new technology that is actually triggering our problem with different stacks and dependencies. And there are pretty good frameworks in Python to manage assets. One of them is actually WebAssets, which has been the one that I prefer over the long run because it provides a really simple interface. You can configure it both through an API and through a simple YAML file. And it provides also the front end part of your assets whenever you need to use an asset, you can actually use it by importing it from WebAssets. So it will also take care of things like cache basting and things like that for you. So it can replace solutions like Groom and Gulp in performing the transformation of your assets because much like them works as a pipeline. So you get some kind of input, which is usually a file, and end up providing another output, which is usually a file itself, which will be the file transpiled, your CSS converted, or your images are scaled and things like that. And the advantage of using this approach is that if you need something, if you need support for scaling images, if you need support for compiling less, if you need support for SAS or whatever, you just track the dependency in your setup UI because the less compiler for WebAssets is just a Python package like WebAssets itself. So if you need less, you don't have to remember that you have a step to run before your application. So you don't have to remember that you need to perform MPM install. You don't have to remember that you need to run grand. You can actually make everything automatic through Python by having your application that when it's installed, if we need to install the support for less, and when it starts, it will automatically provide, compile the assets without having to actually provide yourself a solution to the debt. And it actually works with any Whiskey framework. So you can even use it as a middle one around your framework, which doesn't care about the language and the framework you are using and allows you to manage your assets independently for the framework, even if you use a plain Whiskey application without a framework at all. And as I told you, it's actually providing a HTML side API to inject the resources, which is good because in many other cases, when you inject the resource, you generate it to maybe grant a goal. You will have to provide the solution for things like cache-busting yourself. So in case the resource changes, in case you update the CSS file, you want the browser to load the new updated version and not keep using the old one just because the browser has it in cache. And usually this is something you might need to provide yourself, maybe by adding a timestamp to all the URLs or things like that. But WebAssets does it for you. So when it generates a mesh of your resource, and whenever the resource changes, the hash will change. And so the new resource will have a totally different URL. And as you inject them to an API, it will inject the latest URL every time you run your template language. And the way you define your resources in WebAssets is actually through bundles. So a bundle is actually any kind of resource. You can even be a bundle made of just one single thing. If you need to translate your single CSS file from SAS to CSS, you can create a bundle with single file inside. And the bundle is defined as something that has a name. In this case, we have two bundles, style and JSO. And each bundle might have a filter, which for the first case is CSS Utils, which is used to minify the CSS. And we'll have an output, which in this case for simplicity is just a file I've coded. So everything inside the bundle will be minified and squashed into that style.css file. And actually you can have content, which can even be a bundle itself, because you can see a point where we have a content, a sub-entry, which has CSS files inside and provides a different filter, which is LibSus, which is used to convert the CSS to CSS, of course. And LibSus itself is a Python package, so you can actually just add it to your setup PY and then everything managed through your package manager. So what happens is when our system will need the style bundle, it will actually end up compiling, performing all the transformation for the nested bundles. Like in this case, it will start by transpiling all the SAS files to CSS files. And then it will perform the upper part, which in this case is the CSS Utils filters on all the files we specified and on the result of the previous bundle. And we will end up with a single style.css file, which inside that's all that CSS files, or our scss file transpiled by LibSus, and the result is then minified too. And the same happens for JS all, which actually in this case applies to JS mean filter, as you can imagine, performs a minification of JavaScript. And it will get all these files and we will squash them into dependencies.js, and we'll minify them, of course. And to use them from your front end, it's actually pretty simple as web assets will provide you with an environment that has knowledge about all the bundles you created in the configuration. And you can just inject the resources through these environment. In my example, the environment is owned by the global application object, which is that G object you see there. And what's happening is that I just create, I loop on all the resources of the style bundle and create a new link entry for each CSS resource. You might be asking why I loop as I actually have the single bundle named style. So there should be only one. And the reason why I loop is that actually if you run web assets in the bug mode, you won't perform the minification and squashing anymore. So you can debug your resources separated and then when you are sure that things work as you expect, you turn the bug mode off and you end up having a single resource. So with these syntax, you are sure that everything works, both when you run in the bug and production mode. So both when you have a single or multiple resources generated by web assets. And the same happens for the JS old bundle because I just looped through all the URLs provided for the JS old bundle and I inject the script back for that. So in this case, the example I made using the Kajiki template engine or the game she won, the syntax is the same actually, but it works in any template language. If you look at the web assets site, you will find the samples in Jinja and so on. But we didn't really remove the problem totally because still for some more complex filters, we will need to have Node.js available. For example, if I want to convert my yes six code to a yes five to JavaScript that the browser is actually able to run, I will probably need to bring in something like Babel. And Babel actually is implemented in Node.js. So I will need to install Node.js and tell web assets where it can find the Babel executable file. Which is actually not really good in my opinion because I didn't really solve anything. If I need to have Node.js to perform the Babel, to run Babel, at that point it makes sense to just have Node.js for everything and don't have to actually have parts of my assets pipeline on one side and parts of my assets pipeline on the other side. And that's the point of this talk actually. What I wanted to do is solve this problem, not having to rely on Node.js at all in my Python environment. And that's why I created Duck Pie. And Duck Pie is actually a replacement for Node.js in many ways. It's specifically meant for assets management. So you won't be writing web application on top of Duck Pie. It doesn't have the concept of any or request. It doesn't have a server inside. It's just a JavaScript interpreter. We built things transpiler for the most common environments and most common languages and things like that. So we can now just add Duck Pie as a dependency of our setup file in our requirements. And we know that whenever we need something that relies on JavaScript, we just have Duck Pie installed without having to have some external tool taking care of installing it and so on because it's just a Python package. And there is a Python package which actually has no external dependencies. Duck Pie self comes, self contained and the only thing you will need is a C compiler because currently there is no binary distribution mostly until we support for Linux environment is totally clear how it should work in a reliable way. Currently, but the C dependency self doesn't use any C library apart from libc. So as far as you have GCC installed, you don't need anything else to actually install and compile Duck Pie. So you just run pip install and you will end up with Duck Pie installed at work. And the reason why I created it is that because I wasn't really satisfied with the other existing solutions because like PyXJS, SpiderMonkey, V8 and so on for Python require external tools like V8 and SpiderMonkey. And it's usually really hard to build those. I don't know if anyone of you ever tried to build SpiderMonkey but it's something we spent like two days only trying to get a binary that runs and work. So it's not really easy to have them integrated in your install and build process. And Duck Pie is also specifically tailored for web development. So it means that most things you will need are probably built into Duck Pie to make your assets pipeline in Python itself. A simple example is actually compiling coffee script. So I don't need to install anything because in Duck Pie itself there is the coffee script compiler built in. So I just import Duck Pie, run the coffee compiler function and I get the JavaScript generated out of that coffee script. And you should notice that this is not something that will have major problems or that might not be compatible and so on because it's not a coffee script compiler implemented in Python. It's actually the real coffee script compiler in JavaScript itself that it's running on top of Duck Pie. So whenever the coffee script compiler is updated with a bug fix, new release, new support for language or whatever, it will be just a matter of replacing a JavaScript file, maybe fixing two or three things inside that file and then your release of Duck Pie will have support for that without major issues. And the same applies for bubble. I can convert my ECMAScript 6 to plain JavaScript just by calling the bubble compile function and you see that I get out the plain JavaScript out of my class declared in ECMAScript 6. And also for TypeScript. So you can actually create Angular 2 web application using Duck Pie and no need for Node.js at all. I actually did it for real, this. So you can declare your application, your class in TypeScript and compile it and you will get the compile JavaScript out of it. And as I told you, Angular.js 2 perfectly works on top of Duck Pie. So these actually solved the problem of compiling and transpiling my resources and my most complex resources. For simple things, I can use web assets which already provides all the filters I need usually. And for more complex things, like transpiling TypeScript ECMAScript and so on, I can rely on Duck Pie, which provides the filters or web assets itself. So I can just import from the Duck Pie the filter for TypeScript, import from Duck Pie the filter for bubble.js, register them into web assets and from that point on, I will have support for TypeScript or bubble.js inside my bundles. So in this case, you can see for example that I added a bunch of ECMAScript 6 files which are compiled, minified into the JS app bundle and that's declared by the fact that they use the bubble.js filter, which is provided by Duck Pie. And you don't only stop there. You don't even need MPM anymore because Duck Pie has a package manager for MPM.org built in. So if you need to have a JavaScript dependency in your Python program, you can just use Duck Pie.install.js package, specify the name of the package, the version that you want to install and if you want it's optional, the directory where you want to install it, by default it will install it inside the JS vendor directory of your web application, which is from the environmental web assets. And it also will install any dependency of the package. So if your JavaScript package has dependencies itself, it will end up installing them all too. And if you mix these with the setup tools which have a setup requires function, you can tell that your web application setup requires Duck Pie and that all the JavaScript dependency installed by setup tools itself. So when you do pip install my web app, you get all your Python and JavaScript dependency installed without the need of any external dependency manager. And the only thing you should notice is that Duck Pie is not full of features as the MPM original one. So for example, in case of a collision, in case two different packages require two different versions of a package which collide, which are not supported one by the other, Duck Pie currently would just take the newest one. So it will take for granted that the newest one should work with both of them, but will not make more advanced things like filtering on the minor version and things like that. So in some cases, if you only specify the high level dependency, you might end up with collaging dependency installed, but that's something you can solve by just specifying the precise version for each dependency you want to have. I plan to extend this behavior by providing full dependency resolution, collision and version resolutions because the dependency resolution is already provided, but the collision part is not. And, but currently has not been a major issue for me because I tend just to specify the precise version of each of my dependencies to make sure that the software is always reinstallable even in 10 years from now. And one really interesting thing is that, Duck Pie is compatible on Node.js also for the requirements of packages. So Duck Pie provides a required function which is able to import Node.js packages. And that makes possible to use something like React to render your script from server side code in Python. So we can actually create isomorphic web application in Python alone without the need to mess with Node.js anymore because we can just render the isomorphic part, the part that uses React from our Python code by using Duck Pie.js compile and running then the render to static markup code which will render the React component to plain markup. Inject this markup into our template and never react from the client side continue from the markup we generated. Actually, if you want client side react to continue from the markup we created from the server, you should be using render to string instead of render to static markup. But that doesn't matter. You just switch the function name and things work. So you can provide the first version of your web page rendered from the server. So the user sees the result instantly and then the client side are very kick-seeing and continues from there without any problem because we actually run the real React code from our server. And not only that, if you need to export your Python code from Python, of course, and make it available inside JavaScript, as you can call JavaScript from Python, we can actually call Python from JavaScript. We just use the export function feature of Duck Pie and in this case we export the sorted function which is built in into Python and sort whatever it have above you throw at it. And we exported the sort number. So inside JavaScript we will be able to call it using call Python sort numbers and passing the numbers that should be sorted. And we will get back as a result of course the sorted numbers. And also you don't have to care about references to the objects and memory management because there is a choice I made which is to pass everything by value. So every value you pass back and forth from Python to JavaScript is actually copied. It's not the original object itself. This allows much simpler resolution of problems in memory management of references. And you won't end up with leaking dangling pointers in Python because some code in JavaScript is leaking memory which needs support and which needs a Python object. As leaking memory in JavaScript is pretty easy sometimes but that one actually do anything to your Python code because the objects you pass back and forth are copies and are not the original object. So this actually did everything I needed. I was really happy with Duck Pie as a solution because I could actually manage all my dependencies from setup PY without the need to maintain MPM or an external tool that maintains both MPM and PIP. And I could perform all the transpiling in Python so if I needed to add a feature or change something in my transpiler I could just mess up with Python code. And Duck Pie actually has been a quite performing solution for me. I would say you should not use it on production because there is a lot of C code. I mean not on production. You should not use it in the live running web application. You should use it during the packaging of the web application because there is a lot of C code inside. I cannot guarantee that you won't crash with a segmentation fault while ending 2,000 requests a second and things like that. But for everything that is related to packaging and building the resources and so on it's always worked without any problem for me so far. The bugs that I found are being solved pretty quicky and it has been like a few months that I have been using it without finding a new bug. So if you want to try it, feel free to. Duck Pie actually works for practically any used version of Python from 2.6 to 3.5. And if you find any bug feel free to open an issue on GitHub because it's totally open source. It's fully tested. I guarantee there is one under coverage on all the Duck Pie code and I have an example that ensures that all the transpiler is still working whenever I update the JavaScript side code of everything. And to use it, you just have to pre-install it and have fun with it. So thank you. If you have any question. So this is really awesome. Thanks very much for showing this off. Have you had any experience using it for things like Ember CLI, which is more opinionated? No, never tried with this Ember. I tried with Angular 2 React only. You feel free to try it. If you find any issues, send me an email. I try to solve it. Thanks very much. It's very cool to not have to run Node.js on my web server. So thank you for that. Do you know if your project will work with the less CSS compiler, transpiler? It should. I didn't try it on Duck Pie itself because you have a less compiler for web assets. So whether I mostly use SAS, but I know there is the less compiler for web assets itself. So it never came to my mind in my need. But it should be a matter of just loading the JS file of the less compiler, running it with Duck Pie, and see if it does what you expect. Usually it does. The only problem in my face is with regular expressions because Duck Pie actually applies the JavaScript standard more tightly than Node.js. So some syntaxes that Node.js consider valid in regular expression, and they're actually not. Duck Pie will tell you, hey, this is not valid. You need to escape this part of the regular expression. But as far as it's a matter of fixing the two free regular expression, then they will code. We usually just work. Thank you very much. A semi-related question. Have you investigated at all the state of pure Python JavaScript interpreters? I'm not saying it's not turning. That's a complex question because, yes, I did like a year ago. I tried to use some of them. But I'm not sure. At least a year ago, none of them could last year be so resilient to make sure that you throw a Node.js library to it, and it will just work. For example, Duck Pie has invested pretty much some time into providing a compatible support for the required function to make sure that the dependencies resolution and so on works exactly the same as Node.js. And so I did it. I did it some time ago, so it might be that the situation changed. OK, yeah. All right. I think that was our last question. Thank you very much. Thank you.