 I'm Frank. What do I do? Well, this is me hiking. So I'm an architectural drill instructor. So that means I talk a lot and I nag a lot about building larger applications. I love writing JavaScript, haven't figured out why, but I like doing it. Also, I am product design obsessed, big data juggler that just get some buzzwords in there. And also a game dev enthusiast. So if I have some spare time somewhere, I write stupid little games that nobody plays, but one day and also a coffee addict. So I already had like four cups today. So if I'm shaking, it's not from distress. It's from the coffee. Okay. My background, well, like I said, a freelance at the moment. So I've been around a lot of places. So I've been in very small teams, meaning me, myself and I. Also in bigger teams, enterprise, I've done vanilla. Yes, I've done frameworks. Again, like WebGL, game development, converse audio. I've done pretty much not everything, but let's say I have a broad spectrum of what JavaScript is and I'm going to talk about how you can scale larger JavaScript applications. So first of all, first question. Who writes JavaScript here? Okay. Who writes Angular? Okay. React. Okay. Purely vanilla. Okay. So I will have watch out that I don't say stupid stuff. People know what they're talking about. Okay. First of all, scaling. Everybody thinks scaling is for big teams, for enterprise, for like 30, 40, 50 people working on one team. Well, I don't think this is scaling. Scaling is the moment you start working with more than one developer. So one developer, more than one feature, more than one week of development. This means doing more than what just one people can think of. Why do you want to scale? Well, most of the times, well, if you want to scale, what do you need? Well, you need a system. Why do you need a system? Well, you want a speed of development and you want predictable results. What is a system? Well, a system is a, let's say it's a collection of patterns that help you create predictable results. And most of the time, this is a combination of hard and soft systems. What I'm going to talk about is, first, JavaScript as a language and what are my systems and what I learned. Then second part is structural patterns. How did you go into structure your application? This will be the hard part. So I think half of you guys will be asleep after this part. But then again, we'll end the talk with some lighter stuff, some soft systems, some non-IT stuff. Okay. Questions here? So no. And at the end, you can all ask a question. Okay. First of all, JavaScript. Well, JavaScript as a language, like you might have noticed it's, there are some bad parts and some good parts. So first of all, and this is one I want to repeat a lot, is don't forget that JavaScript has a pass by reference. Who knew this? Okay. So quickly, quickly. If you would be passing around like stupid stuff, like strings or integers, or you know, the simple, the primary, doesn't matter, small stuff. It is pass by value. The moment you start like passing around objects, it's passed by reference. So before you know, you will be editing like one object here in the application. And on the other side, that will be also updating. And it gets very weird results. Just remember, JavaScript also has prototype. Anybody uses prototype really? Okay. That's a minority. Well, I don't like prototype. I like to avoid it because I have, well, later on you will see why I don't like it, but I don't like inheritance in an application and in general. This is a very strong opinion, but don't be, don't fear. Third one. Okay. This is just JavaScript. Not the number is toxic. This means if you throw any, if you get an error somewhere in your calculation, your calculation is fucked by not a number. No is an object. And most important one, numbers are floats. This means that you can do like price calculations or anything in JavaScript. There are libraries who help you for this, but it will give you very strange results in rounding. If I'm going to quick this, you can later on watch the slides and just go over them point by point and then reference a look them up on Wikipedia. And this is again, a sync by nature. And this is something I noticed. And why I'm added the slides in general is a lot of people don't recognize or know that JavaScript is very a sync. So there is no guarantee that each line will be procedurally printed out or run. If there is one call like to a backend and that's not returned with an instant, instant, instant, it can just skip that line and just go to the next. Why do I need to slide? Well, next question. Who of you ever read JavaScript, the good parts? Yeah. That's a minority of the people who are using JavaScript. Who of you say not a good part, just studied the language in general, just the pitfalls or anything that's... Okay, so you're writing JavaScript and you don't know what you're doing. And then you get the message, this is... So I never told you I was going to be nice. Okay, step one. So you want to build scalable JavaScript application just by the book, the good parts. It's this thick. And I think only the first half is about the good parts. So the rest you can just skip and ignore and do not use unless you really, really, really know what you're doing, but even I don't know. Okay, second part, building an application. Fear the global. Again, this is same that Crockford says, don't use the global. This is a very common practice. That's a lot of applications, mainly in Drupal world use is like, okay, let's just create window dot, put the data there, and then on the other side of the application, we can just edit there and just use the global as an environment variable. Well, this is a bad practice. This will have give you problems. What will it do? Yeah, first of all, namespace collision. So what if your application, you implement another third party who is in the same namespace as you? Well, you have problems. It's also way too easy. So it will be too easy to have bad habits. And then again, the bad habits was like using a data, multiple parts of your application influencing each other when they shouldn't. Most important one, watch out for accidental globals because you can create globals without even knowing. So if you forget the var before any variable, your compiler, your browser will just create a global. So you can be like editing each global. I had this problem with low dash. I use modules, but I accidentally forgot to var it and that the application started crashing, crashing, crashing. I had no idea where to look and I had to go to every line of my application just to figure out I forgot to var. It happens. Okay. Yeah, this is just going over the language. So who of you who write JavaScript uses this a lot? So this, this. Well, figured out you probably shouldn't except if you really, really know what you're doing. So why is this not a good option? It's mainly for security. So if you have an object, would have a... No, I don't have a detail. Okay. Why don't you want to use this security? If you have the file and JavaScript, you have the functions like call, bind or apply which allow you to change this. So if anywhere within like say you have this function and it uses this, I can change that. So say this gets token or this get function. I can just pass in the, then change this object. So I can like hijack. I know this is security stuff and I should have had a slide to explain this. Okay. But except from security predictability. How many times I've been through a JavaScript application and it was like, yeah, this dot get, this dot get this, this dot get. And then by the time it's this dot name, this dot name, you're like four levels deep and you have no ID. What's inside this, where it's coming from and it's just changing all over. Anybody has recognized this problem? It's a mess. Again, avoid the call and once you start using like this, you have to start to be sure everywhere. You cannot use just regular functions. You have to start using call, apply, bind or if you're using ES6, the fat arrows that why you're forcing the new this object. And again, again, it gives you weird errors if this, if you would be, if you would be using like this inside a, let's say in X HR request, it can lose that context again and then it will fall back to the window. So you will, no, it changes a lot. So how do you solve this? Well, don't use this, just use private variables. So whatever you declare within your function or within your module, just bind it once. Or if you want to use this, just type once for that equals this and this is solved. Okay, where does this make sense? If you're writing like TypeScript or writing like ES6 classes, there you have of course the Java thingy, not the Java thingy, but they use it a lot in Java. Is the, you have classes and there you have always, this is referencing to the current instance. But again, this is not security proof. Like in Angular 2, they use TypeScript a lot and even Angular had to fix this problem. And I have to stop saying this. Okay, an easy one. Okay, who uses gulp, grunt, webpack, any? Who still uses grunt? Ah, there are better tools on the, well, if it works, it works, but again, keep it simple, use a small building tool. But an important part is seen with a lot of clients and a lot of teams, teams I joined is I enter and they have like this very big grunt or gulp file and nobody understands it. And then you ask who wrote this? Well, we copy pasted it from somewhere on the internet on Stack Overflow and nobody has any clue how it works and if it breaks, they're fucked. So please, I cannot advise you this, just write it yourself. It's a small documentation, don't do, and this will also hold you back from like writing these over complex builders. Again, keep it simple. Even if you do building tool, I've seen this way too much in teams is symbolic linking. Well, there are copy, there are other ways, symbolic linking, I mean, there's one folder with some assets here, some folder there, there are copy functions, there are many solutions to this, but not symbolic linking. Again, why do you want to use a building tool? Well, you can run automated tests, you can run quality checks. Again, you can, I think everybody knows what the benefits are, optimize and minify. Yeah, do not overdo it, keep it simple. And again, do not copy paste setups. This is very important. Next, this is one, this is a slide especially edited for the Drupal con because damn, you guys use way too much jQuery inline templating. So if that's, I know, mainly in Drupal 7, there was no template engine. So everybody uses jQuery and that was fun, but then you start really like this big concatenation. So if this happens, then, okay, then now add this string to this bar, then if then, if then, if then, and at the end, you just don't get it. And if you want to change one little thing to it, it just breaks. So use a template engine. There are many way and many out there. There is like moustache, you have virtual DOM if you want to be fancy. React is kind of a render engine, but it does a job. You also have now ES6 template strings. Another mean that somebody pointed me to because I was writing everything also in line is use template files. Why is this important? If you start using like a template engine, you create nice if, if, if, but not everybody writes the JavaScript or whatever jQuery framework as well as you do. So there are designers out there who don't write JavaScript or jQuery, but they still want altered like just the HTML of a template. This I don't have to explain to a Drupal audience with the whole twig end, but just write it. Okay, this is important one for me because again, I was bashing on the dysfunction. If you're writing a JavaScript application, keep it simple. That's again, this goes against the advice I'm giving about the prototypes. JavaScript has the most awesome thing that a lot of languages don't have. There's function first class citizens so you can bind the means of function you can easily bind them to object and you can do everything with them. So just use literal objects. What does a literal object mean? And I don't have a example for that. Well, well, roughly literal objects means you can, everything is just an object. If you just say like open the square bracket, I know the, I don't know what the brackets, the brackets are, you have an object. Easy, the fun part about this is that within this object, you have a, like a private scope. So anything you declare inside that private scope is private for that object. Fun part is, that's very simple and particular code. You don't, fuck it. I will explain this in the next slide. So, okay. If you thought this was a hard part, well, let's start looking at the structural patterns. So once you mastered the JavaScript as a language, it's fun, you can write strings, you can do fun part, but then at a certain point you will hit a very hard wall because you don't know how to structure. You have two options then. First, you start using a framework that solves all these problems for you. So if you recognize any of the next stuff, it's probably because you use it in a framework like Angular or React, React is not a framework, it's a render engine. So, or Amber, or you can be like me and get phonetic about it and research what design patterns are and try to write your own frameworks and then in the end learn that it's a bad decision. So, but I learned a lot and that's why I'm presenting, making presentation about it. First of all, if you're writing any JavaScript today, there's no reason to use, do not use modules. Who have you written modules in JavaScript? Okay, modules are like little containers like a clover, they're like the, all the good things of a class than in a JavaScript. That's the thing, just how these little containers that facilitate modular code. They mainly used first, I don't know, but they mainly used in Node.js. Fun part is, you can use them also in the, you can use them in just in the browser. What are they? Well, easy as this. This is just a module. What does it mean? Well, you have, it's just a function that has functions and that you have a very defined return. Nothing more, nothing less. This is a function. This is something you can export if you use a module loader. What does this give you? Well, this gives you the opportunity to write private and public functions to only reveal what you want. So if you look at the bottom, I could have written any private variable, any private function I have wanted. I would only, at the end, I will only return what I need. This again, this is a very opinionated way of doing this. So you can also just return or just add it to my module, but I think this is a very clean way. This is the revealing module pattern. What else can you do? Really private variable. So this solves the security issue and it's highly testable because you have a very small snippet of code with an input like params, a couple of functions and that's it. So it does not have any knowledge outside its scope. It shouldn't also. And if you combine this with not using global, it becomes a very structured way of working. Okay. What next? What does it give you in structure? Well, it's a little bit, yeah, it's a little bit like having these little containers of code. So this is an example of an application where I have a very simple JavaScript, web audio player. So I have a small module, which does the audio, a small main. Every application has a main. So you're just whatever loading the services you need, the data and you're creating the elements and you're including the audio module, the controls module and then the main module doesn't know about the controls about the play button or the progress button, but it just, the controls will include the play button and the pro. It's a way of structuring your codes. For example, I'll leave it on, I will show this. Important and this is very important. If you start writing like modular code and this little modules, is do not access the globals. The moment I've seen this too much in third party libraries that I use and I go to the codes and what they do is like, they start accessing the global object and then you just beat in the point of using any code encapsulation. And then they start extending the globals. So yeah, important part there is also alter input params, do not do this. So if you go back here, I am using params. So just data as in a module, I would, if you want to stay sane, respect your data you get in from the top and don't try to alter it. If you want to alter it, copy it, do it. Just again, watch out with the pass by reference so you don't know where the data is coming from and it's the altering and before you know, you start screwing up your own application. There are solutions and later on I will discuss those. What's super long modules? Yeah, I tried to stick around max 200, 300 lines but those are, I'm not gonna say I'm gonna write anything longer but just keep them small, keep them focused, keep them really stupid. And this is very hard also. I think I still suck at it. So I constantly refactoring, rewriting my application just to be a little bit more structured, a little bit more encapsulated. Okay, so what do you do with the modules? Because this is fun but my browser does not do a lot with this. So okay, I have a function and so I, so you use a module loader. Since ES6 you will have also have modules system so it's in there but that's there are sync modules, of course. So I prefer using browser file but lately I've been using a lot of webpack. That's a good reason for that. First, they do, what do they do? Well, they help you load the modules so they load all the code and then they start gluing everything together. So okay, this module needs this module. Okay, let's load that code and let's inject it here. It resolves the dependencies for you. So again, import, if you import the code, fun part is, so if I would, for in the play button, if I would need the play button in my controls, the only thing I have to write down is import and then the path of the module, that's it. Then the module loader will just resolve this for me. Whatever you want. So you've got the required yes which is an asynchronous module definition. This is, as the name says, browser file which is common yes, which is mainly like no yes way. So import, export, like no yes does it. So one of the main benefits of a module loader is so you can have very large folder structure with a lot of dependencies here and there. In the end, you just say browser file, webpack or whatever, build my application and it will just squeeze everything together and get it in the right loading order and give you one small file that is usable and that can just be thrown in there. Okay, and why do I use webpack lately? Because again, like JavaScript, there are multiple standards, hooray. And sometimes I have this application, I write mainly common yes and some third party services. I third party plugins use AMD, webpack solves it for you, it's just universal loader so you don't have to care about it anymore. Most important part is when you start using like browser file or webpack is that you can link them up with NPM. So NPM is the package manager for node so you can start using all the node modules also. The only thing you have to do is NPM install this module, of course NPM in it, whatever in your project, NPM install this module and next thing you have to do is just write import this module and webpack browser file that will just solve that for you. So you get a very modular code. For example, if this is load dash where they have every function that they have, they have it as a NPM packages separately. So you don't need to load the whole load dash application at once, you can just like load one function and all its dependencies. What gives you, well, this gives you velocity. So it's package manager, you do not need to read the intervention wheel and again, easy deployment and testing. So you don't have to like all commit all your dependencies, you can just use NPM. No more uses of power, no more including the library in the Drupal libraries, just all of everything is perfectly packaged there. What would this give for our example application? Well, let's say if my play button would have, would you be fancy and use virtual DOM and load dash for each, for example, the only thing I would do is play button import virtual DOM and play button import for each, which would not look like this, okay. Okay, that's it, this will compile, the browser file will solve this for me, I will have one small build which is minified. Again, this works together with something like grunt, gulp or anything you want. Okay, I told you this is gonna be a lot of content. So you have dependency injection. Who knows dependency injection and use it? So it's Drupal, who used Angular? Not much, you're not Angular lovers. So Angular uses a lot of dependency injection. Well, dependency injection is a very, very fancy name of, like, well, in JavaScript you can, is a very fancy name of injecting your dependencies. So for example, I have a library, the mediator, which we'll explain a little bit later, and I'm injecting this in this module. So if you look at it, so see at the bottom is just a small module that I wrote, it's equals a function. And then I pass in as param, parameter, a mediator. What is a mediator? This is an event system. This can be come from ever, this can be just a jQuery event system, this can be whatever event system you are using. Here I'm injecting it and I'm using it. Fun part is you can, like, use different mediators or have multiple instances of a mediator for multiple parts of the application, but you can still reuse this small part of code. Of course, there are pro and cons to using dependency injection. Well, first of all, it's reusable, so you can build like this really, really small, little factories of code, and you can just inject, inject, inject what you want, and then reuse it all over your application. Okay, it's stupid components, which is important in programming. Limiting the guilty knowledge. This means everything that the module needs to know needs to be passed in by the parameters. And again, testability. Why is this, and this is the main pro point for dependency injection is testability, because it does not get any knowledge outside its scope, so you can easily test just get the, and like, if it has like two data services or external services, you can inject like easily mock data. So you have everything under control and testing becomes a breeze. Of course, there are really problems with that. First of all, you have tight coupling because you have to inject everything that the thing needs. So dependency injection is fun in the beginning of your application, but before you know the button, the one button needs like 10 services. It needs to know about the audio. It needs to know about the render engine. It has like this, I'm betting that Drupal has this problem that Angular has this problem, like you're injecting like 15 parameters or services or whatever render engine you're using. You're injecting it and it becomes a hell. Another problem is circular dependency, but I know it's a lot today, but if you would ever start using dependency injection and you start having problems with a lot of dependency injection, do not use service locators. Just remind, remember to store this and this will help you one day. Inversion of control is the way to go. I know these words on say much at the moment, but just remember it. And this is my favorite, yeah, I've come to the point where I have a favorite pattern. This is my favorite pattern. This is the mediator pattern. And what does this solve for me? Well, we're almost there. Well, let's say I have, again, same application. I have a button at the first part. If you go back, the play button, the playback rate, progress bar, this is an audio application. Had a tight coupling with audio elements. Well, later on the client wants a video element. So I add the video element and you start seeing that the playback rate button now we need to know about the video, about the audio. You're starting to get a lot of dependencies. Well, this problem has been solved a lot for years in the UI by the mediator pattern. What is a mediator pattern? Well, it's this. So there is no direct communication between any parts of the application. Trust me, this is very hard to write, but once it works, it's awesome. So what does it mean? It's like the play button, if it plays, well, the only thing that it does is send out a stupid event. So play button does not know about any of the rendering, does not know about what audio element or video element is attached or what state it is. The only thing it does is, am I playing or am I not playing? If I want to play, I send out the event play. If I do not want to play, I send out the event pause and I change state. That's it. So I can have 20 buttons, they will just update. The only thing they're going to do is send out events. What will this mean is, I can change YouTube audio and video whenever I want. So on the fly, I just, the play, they like say start playing and then the audio element, I say, okay, now I want YouTube. YouTube start playing. Well, the play button doesn't know, doesn't care. Same for the playback rate, progress bar or the mute button. They will just keep on sending events out. This is also, again, very testable. No, of course, there are pro and cons. That's with everything. That's life. The biggest pro I got about this was debugging. Because it's like every, you can, especially if you use this for the UI side. So this is not for like sharing data between parts of the application. This is more of capturing the interaction of users. So, but you can start like debugging and printing every event that happens. So whatever, and you can do it to your console. So user starts clicking, for example, audio starts playing, event goes audio play. User presses a button, click, event goes click. So you're getting a backlog of all the events. So wherever the error happens, you will see what the last event was before the event was sent. Easy. Regression testing, same refactoring becomes very easy because none of the elements, none of the modules or any small part of the application have knowledge of each other. So you can just add them, throw them out as long as you expect the same event code. I use the same event messaging. Fun part, this is for the marketing department, it's measuring. So you can really easily like hijack an event. So if you would add like Google Analytics here. So the marketing department wants to measure every click on the play button. Well, you can just, you know, this button, you know, you can just like hijack. So say the marketing one every play. Well, you can do is just listen to the mediator and listen to every play event and then just Google Analytics this. Every time somebody clicks anywhere, just Google Analytics this. You just have like this one event system in whole your whole application. This is nothing new. There are many implementations now. I think like at XES is one of them. They use more of an event system, more and more applications. Nowadays, JavaScript frameworks are using this way of building applications. And no more blob state objects. This means no more, and this is a very important one. There is no more like states. The state is something, wait, I'll say we have a web development, sometimes a very bad habit of keeping well, very big state objects where this isn't that state, this isn't that state, this isn't that state. Well, this is fun if you have like small applications, but this doesn't work once you start scaling. So in what I'm proposing here is that every little application has its own state and is never past the state. It will always determine the state from whatever happens later on, which makes development much easier. And it's always more important to always state is always a reaction or calculated. Counts, of course, single point of failure. Well, if your mediator breaks, everything breaks. Message overload, yeah. If you start sending out too much messages, you start to lose the ability to debug, for example. So you have to really think if you want to send out this message, just think about it. But the main part is the con is it's hardly to map the flow of data. This means if as a developer sometimes it becomes hard, if, okay, this happens here, okay, I know this service will listen to this and this will do that and this will do that. And you have to like, it's harder to do the paper trail of all your events. But yeah, it's the downside on it for it. Okay, oh, almost there. Single tons, single tons. Well, single tons are super simple. It's modules again. I don't need to explain this. This is just, what does it mean? Single ton is just a data. It's like a mini database for your data, for your application. Well, it's no, it's not the way I use them. It's like a mini database for your application. I store all my data in a single ton. This means I just create this function once in my whole application and this is where I store my data. For example, user.name.blop and I have gets and sets. If you do this again, this is easy. This is more structured. You have a kind of a contract, a predefined API. It is very self-documented. And again, it's easy to test or to mock because at the top you can dependency inject or you can do whatever you want with it. Again, again, most important, pass by reference. For example, if you would be here, if you would be returning like function.user, this will be pass by reference. So if I would be, so you get function.get and return user, if I would be like altering the user object anywhere in the application that I get back from this, I would be altering the user object inside this function. So that's a big problem. But solutions for this, you have immutables. Immutables, what does it mean? It means immutables. It means that you cannot, that you can not alter the data. This is simple. These are libraries for this. What they do is they freeze your object so you're not any, if you return the object, you're not able to edit the data after once you got it back. You have a object that free switches in vanilla, but it's only shallow, it's only one level. You have libraries like immutable.js or seamless immutable, which has better vanilla support. But you need to watch out. Most of the time there's a performance hits. So you start using like immutable objects everywhere in the application, you will get problems. It's cumbersome, it's a lot of code you need to write. And most of the times you can do just a deep clone or if you feel dirty, you can do a json.parse, json.stringify, which is a very easy way to copy data without, so you're just destroying whole link to the original object. So if you have a data service, instead of return user, I would just return a clone of that and that solves the problem also without using anything immutable. Okay, factories. So we have modules, we have dependency injection, we have magic because we have a factory. What does it mean? This is mainly for UI components. Like I said, we have the dependency injection, the params at the top. You have the whatever thing you're going to do and it just going to return a object. So what you can do is create an instance, you have reusable components, you have magic. And it's also very dry. But I mainly use it for UI components. So my structure is singletons I use for data, factories I use for UI components. You can use them interchangeably, but most of the use cases are these. Most important is, so you're not using the global anywhere. So how do you help, can you create an application? An API for this application create whatever you need. How do you can you expose this data to the user? Well, you just build a facade. A facade is nothing more than just a small service that exposes whatever logic you have inside your application, exposes this to user. For example, I have one facade function here that has the dependency injection, the services, let's say I just inject all my services here and it just return very strict play, get user, very simple stuff. Another main benefit of this is, you're not exposing your internal API to an external party. So you also have some level of security here. And because once this get minified, the only thing that will be readable will be the play, get name and get user strings for your whole application. Hide your inner workings. You don't need to do this, let's say on a whole application, you need to do this on a whole application level, but you can also do this in smaller parts, feature parts of your application. So you have one featured and then you write it and then you just wrap a facade around with a very simple API. So like, for example, you have written your own web audio implementation, you've written all these little modules and you just wrap around. So give me a URL, give me a play and that's it. It gives facilitates feature components in the feature communication against security. What does it give you? Well, all these previous steps allows you to test. Most important part again with testing is the 2080 rule. This means you don't need to write like 100% coverage, except if you work for a bank or something super, super serious, this will be enough. 2080, just get the whole idea of the application, get the important parts testing because 100% does not mean working application. Try to write good, well, let's say unit tests are good indication of architecture status. This means bad code is hard to test, so there will be no tests. The more tests and more test coverage there is available, the mostly the better and modular the code is, otherwise you cannot test it in the whole. Unit tests are contracts for you, but also for the people after you and be next to you. It helps you simplify your codes. Important part and this is seen a lot is central mock data. What I mean with this is I've seen there's a lot of unit tests where developers just, they have this small part and they wanna test it and they start writing their mock data and so whatever user object there is, they write it each test, each module again and again and again. Well, this is stupid, just create like one JSON with the whole mock data in there and then reuse it in all your tests and ta-da, you have a, you have end-to-end testing, just one mock data. In the business side, they say, okay, whatever the backend data, the data changes, the structure changes, well, the only thing you have to do is update your one mock JSON with your data and then you just have to rerun the test and watch where everything breaks. Okay, add a couple, again, this helps you. Again, don't forget the end-to-end system test, nothing very special, but just one or two simple tests that just start up your application and watch that everything is running. Night watch is very fun, I think there's a presentation about it. This Drupal call, you have test frameworks, mocha, jasmine, jq, whatever you want, test runners. Doesn't matter, so that was a hard part, yay. So now the soft systems. Well, first recap, the previous system was, the structural part was just helping you create maintainable code. So what else is it than knowing your language and knowing maintainable codes? Well, it's knowing each other, but no, soft systems. Important part, everybody knows a dry principle. Well, I think it's the most overused principle I ever saw. I've seen the duplication of code is better than a wrong abstraction. And this, oh, I've seen how many times, and then they start like altering, they create one abstraction, but it does not fit this use case, but they don't want to copy it. So they start altering this abstraction, again a little bit more, or extending it, or creating, and then in the end you have this one big blob of component or module that is un-maintainable, but nobody dares to touch. And if it was just like smaller parts, maybe some duplication, it would be easier to maintain. So do not dehydrate. Sorry, do not repeat yourself. No problem. It's the principle of trying not to copy paste around, so copy-pasting is bad, but if you write the wrong abstraction, you will get code that it's a maintainable, and I cannot understand, and you have to go like five levels deep before you get to the end codes. Keep it simple. Refactor early, refactor often. Well, I think Drupal could learn from this slide a little bit, because they done a big rewrite, and like everybody noticed, that's a lot of work, that's a lot of stress. And if you can, that's not always possible, but try to do like small refactors in your application. Keep it small, keep it simple, prevents messy and maintainable code. Voice control means whoever touches or passes by the code updates it. And again, if you want to refactor, first try to write unit tests, and then refactor, not the other way around, otherwise it will not really help you with that. But important, messy or different doesn't mean needs refactor, and this is a bad habit for programmers that they enter a project, and they see coded, and they wouldn't have written it that way, and they start refactoring just because they don't like it. If it works, it works, don't touch it. If it's going to break in the future, maybe refactor it. But remember, things just need to work, and, but you need to still understand. So it's a balance, so, and that's up to you. It's very vague, I know, but the thing I've learned the most is keep it small, your refractors. Keep it like a small pool request, a small patch. Okay, this is my favorite slide, be critical of frameworks. In JavaScript, there are a lot of frameworks. It's moving very quickly all together, and I have no idea which framework is the best, and I'm using a lot of them, but I've noticed that a lot of business solutions, a lot of applications I could have written, I didn't need a framework, and the thing was way over-engineered, and the framework just made it way worse. So, over-engineered, keep it simple, and that's a big one, and steep learning curve. So every time you're using a framework, you need to relearn it, but also every dev that comes after you, or next to you. If you just write it stupidly in small jQuery code, probably the next dev will understand your code. If you write it in a new framework, you need to educate as a developer, you need to, it costs a lot of time, because mastering a framework costs one to two years, I guess. Specific frameworks are hard. This is one more for the PMs and the business managers, but finding a specific developer for specific frameworks becomes harder than just say jQuery or vanilla, but this is where all the freelancers make their money, is because they know one framework very well, and they are asked for this. Like Drupal? Like vanilla. Yes. Shh. Drupal is not a framework. I'm always advocating for, if you can write it in vanilla, of course, in the context of using something like NPM or Node or smaller maintainable modules, it might be the better choice, and don't believe the hype, because if you're looking most of the JavaScript and mainly in think in Drupal, if you look at the amount of complexity and code you have, that you are probably here in the middle, and you're using like Angular or React or whatever flavor is next month, is built by Facebook or a mega corporation, and they have the resources, they have the documentation, and they have, for them, it's no brainer to use this, but for you, there is a very big cost, and you don't always need it. Okay. Simple one, document. I think this is hard one, but there are simple ways of two documents, just link your commits to tickets. Document every design decision. If you have like a discussion on JIRA, just say, this is the final implementation, or whatever tickets, this is what we've done, this is why. Three lines, four lines, just say why and how. Document your whole API. I know this is hard work, but just do it. The developer after you will thank you for that. Write a setup guide for new developers. How many teams I've entered that this was nonexistent, and somebody had to spend the whole day next to me, okay, now install this, yes, set this up, okay, this is Java, okay, this is the backend, just write it once and we will be done with it. Another important one, part about documentation is that you clearly explain this is how we do it here. When somebody news enters a team, they will have their standards, their way of working. This is easy communication, okay, we don't use this, we use this, this, and this. I don't care your personal flavor, this is how we do it, this is how we do it. If you want to changes, open a discussion, you're now writing it this way. This again will enhance predictability, standardization. Okay, how many of you are working at Scrum? Scrum doing stand-ups, how many like, do you like, how many of you like doing stand-ups? The mood is changing, yeah. No, I'm pretty cool. Some developers don't like doing stand-ups, stand-ups are important communicator, we are not super communicators, so just those 10 minutes, in the start of the day, just talk to each other, get out, it's okay to fail, going over a budget, it's okay, it happens. Assumations are only, we're only humans, and good communication, like you say, and this is more of a management slide, but hey, good collaboration is A plus B, good collaboration gives A. Oh, I know, I forget how to say it in English. A, multiply by B, oh, that's important part, for you developers, because some of you guys do development by day, do contract by night, and before, you know, you're only doing development. So, first of all, learn new language, of course, this again, use different frameworks, get out there. The most of the things I've learned about JavaScript and mainly like patterns is from doing game dev. It's a total different world, but it has its own problems, but in the end, I learned a lot about scaling and larger stuff, and just brought that back into my application and my JavaScript knowledge. Pick up some design basics, again, developers, how many developers I've met who, this button is there, okay, it works, it looks good, whatever, don't care. Do a hackathon, I really suck at hackathon because I need eight hours of sleep minimum to be functional, but I still do them, I learn a lot from it, a little bit, yeah, then a little bit basics, so sociology, psychology, again, working for humans, and do whatever involves not sitting behind your computer, and most important, last slide, nurture yourself. So, this may not sound sexy, but the best code I've written is on a Monday morning around nine with a pot of coffee, well rested, so treat yourself right, because doing those, like that's why I don't like hackathons, doing those long nights, keeping up all night, just working, working, working. In the end, you will just write shitty codes, okay, okay. Oh, fuck it. Question, I know it's, if you have a question, there's a mic, shoot, or you all want to go home and eat, yeah. So, I do have a question. Um, do you, it sounds like you walk a lot with Angular, right, because dependency injection, yeah, that kind of stuff. I don't like it, but it's an enterprise solution, so I run into it a lot, and I picked up mainly the dependency injection from Angular, and I really like it. All right, yeah. Um, so when you were talking about the mediator pattern, it's kind of, I mean, usually it's like the document object is the mediator object, since all the events, you know, bubble up and down from them, so, what's the difference between using documents? You can use, no, you can use the document event system, I just, I prefer my own event system, that's it, that's, okay, if you want to, you can use it, but again, the thing is, the fun part about choosing, I know it's not, it's really implementing the wheel, but the fun part is, you can have like two instances of one application, which have their own instance of the mediator, so you can reuse the same event, so you don't have to be afraid of collision of events, because you inject it everywhere, the mediator, or you can start like namespacing your events with like an ID or whatever, starting the event name with your app instance ID, that's another solution you can do. Okay. And I guess, two last ones, sorry. When you also came about state and keeping the state object like small and within, you know, the object that takes, that cares about it, but then after what do you talk about single tone? Yeah. And isn't a single tone like a big state object? Yeah, yeah. My, what I meant with state is more of, the state of the application, which that's the whole state that you would know what every button, like one object knows what every state of every button would have. That's what I mean with state. Of course, when you have like a single tone with data, it also has its own state. But what I wouldn't be doing is like watching on this, like this one button that would be constantly watching on the state of the single tone. What I would be doing if like, whether there is a data update, I would just send out a mediator event says, okay, data changed there. And then whoever is listening would get the new data and update its state. So that's kind of like what React is doing, right? Yeah. Yeah, like I said, you will recognize some parts of frameworks here and there. This is just more of the basic implementation of this. All right. And that's question. So you talked about Drupal being, you know, not great on templates and that kind of stuff. So what else can we improve? Well, can you repeat the question? What else should we improve? Oh no, I like it. Drupal JavaScript side of thing. Well, Mike, well, I have more of the, say, mainly my experiences from the seven. So I know a lot of changed, but it was mainly the... Yeah, not too much, but it's still... Yeah, I like the eight much more with the whole API first stuff. This is perfect for me. So I don't have to care about just, I have the CMS, which I can give to the clients and for improving, yeah. Well, I'm just happy there's an API. Okay, yeah, so thank you. That's all I want. It was a very good API, an explosion or exposure of that API. So I'm happy. Hi. Hi. So I was kind of confused on the slides you were talking about dependency injection. List the pros of testing and one on the icons. You mentioned that dependency injection is tightly coupled and you think it's a con to have inversion of control. So I wonder if you could explain exactly why you think that dependency injection... No, no, no, this was a bad slide. Inversion of control is a good thing. It should be on the other side. Sorry. And then do you think that dependency injection is tightly coupled and is that more from the error experience with AngularJS? Yes and no. Of course, yes, I read a lot of Angular, but the tightly coupled, even when I write vanilla, I use dependency injection a lot, I can mention. What I mean with the tightly coupled, it's the tightly coupled, I mean the, I'm okay with tightly coupled being like with the data, the data sharing between parts of the application. But once you start using like dependency injection in your components, UI components, it becomes a mess. There, the tightly coupled becomes very hard. So in other words, the way you're suggesting is when you inject dependencies, don't inject, do not inject state or... I prefer to not. I prefer that everything the user sees to keep its light and have no connection, direct connection. Because dependency injection is loosely coupled. That's the point. Yeah, it's loosely coupled, but then... Because everything you pass into it, it's the caller and not the class or the method doesn't know about its dependencies. Tightly coupled was maybe a bad explicit, a bad wording for it. It was confusing to hear that. It was not tightly coupled. You know, dependency allows you to inject whatever you want and at runtime and change that. But it's a sort of better set. I don't like using dependency injection in my UI components. That will be a better... Okay, thank you. Okay. Other questions? Do you use... So you use JavaScript in Google, right? Yourself or not? Yeah. Okay, so how do you first test that the JavaScript you write works well before writing? I mean, how do you debug it, do you? Because what I do, the practice that I do, I have a note server where I write my JavaScript and I make sure it works and does what I want. And then I import it into Drupal Adder through a module or a theme or external JavaScript file. How do you normally do it? I do the same. Yeah. Okay. Anybody else has any suggestions or anything? Or is that the best practice? I don't know if it's the best practice, but it was the most practical one. So... Yeah, okay, cool. I tried to write a second... Now I'm relieved. Okay, I do that. Okay. Thanks. Okay. Okay, thank you for your attention at this late hour. Small reminder to Friday, there are sprints. Yes. You're coming to the sprints? No, sorry. I need to be home again. And then important for the front end guys, 26 and 27th of May, there is an Athens and Greece is a new front end United. Yeah, everybody wants food. So, and if you want to evaluate, that would be kind. Okay. This would be a good tool to debug an application.