 Oh, yes. So who learned something new about this neighbor, about their neighbor? I learned a lot. Yes. Did you all talk to somebody who you already know? Okay, let's see. Yeah, can we start? Awesome. So welcome, everybody. I'm going to talk about CSS and JavaScript. So you might ask, is it the right place to do that? Because there is also a JavaScript meetup. Maybe it should have gone there. I hope we can figure out where it fits better. Just this one was, a spot was available. So I'm like indulging you guys with it now. Yeah, probably we'll have a look. So who has used CSS in JavaScript before or knows a bit? Oh, a lot. Nice. So I'll skip over all the examples. No. Okay, cool. Let's go into it. So very quick introduction. I'm Dominic. I'm originally from Switzerland. And I moved here about one and a half years ago to Singapore for my company, Silke. We are like a consultancy. We do, we are a service provider for mainly software projects. So we help customers develop their software if they don't have the skill set or the manpower to do so by themselves. And I'm focusing mostly frontend recently. I'm like full stack originally, but the recent projects more frontend. So right now I'm working on a large React application. And yeah, so we just started like two years ago here in Singapore. We're about 25 people now. And we're trying to grow in total in Europe. We're about a thousand people. So you can see we're trying to reach the same numbers here. Not there yet, but we never know. So let's go into CSS. So does anybody know or like what kind of problems do you usually encounter when you do CSS? Anybody? Okay, it's very hard to say something. I know. I know. I wrote some down. So this is not my list. It's from one of the core developers of React. One thing we encounter very often, I think, especially if you do large projects where like a lot of developers are involved, you have a global namespace in CSS. You don't really know if the same class name has been used before by somebody without grabbing over the whole code and maybe going over multiple files and things like that. So that can be kind of an issue. There are ways to go around it, as we will see. You have other things like it's hard to do dependency management. That code elimination is hard if you just use plain CSS. You don't really notice when a class is not used anymore. Or you have minification, which is hard. You can't just rewrite class names that easily or make your bundle size smaller. It's kind of hard to share constants that are used all over the code. And then you have those kind of that are a bit trickier even. Most of the time, you only find out too late or when you have three importance already spread around your code. So it's kind of hard to know the specificity of different selectors. And then you end up doing those weird hacks because you don't really understand how it works. So that's like non-deterministic resolution and isolation. It's really hard to write classes that cannot be overridden by other things or you quickly end up in problems with those kind of things because you can just do A. something and then a diff inside. And then it messes up all the styles that somebody else wrote. And you won't find out because your QA doesn't know how it should look like. And I don't know. So looking at just one of those a bit more, I'm sure you heard about Bootstrap. It's great. I mean, it looks nice and it's easy to use. But still, you have 600 global variables in Bootstrap. So, okay, Bootstrap, they spend a lot of time making sure they don't conflict with each other and things like that. But if you try to come up with something this big by yourself, you'll certainly have very inconsistent naming and things like that, which is not so great. So at least nowadays, they're not using pure CSS anymore. They're using SCSS. But even there, we can still go better, I think. So one question that has been coming up more recently with all those huge web projects, web applications by the big teams is how can we scale CSS nicely? And there are a few options to do that. And I'd like to go, like, gradually from the easier ones and the older ones to what the talk is about in JavaScript. And we'll compare a bit what the advantages and disadvantages are of those. So does anybody have an idea what we can do if we just use pure CSS? What can we do to make sure that we, like, keep those problems in mind? Or, like, to the minimum? Ooh, nice, see? Bam. Who knows bam? Okay, okay. So bam is, like, bam and also a few other ones. They essentially without changing anything about CSS, they just tell you how you should write your CSS. For example, you use buttons or you have naming conventions, how to name your CSS styles and classes, how to structure everything and what belongs where and things like that. So this actually works very well if everybody does it and everybody knows how to do it. Thing is, I've never really seen a project where that works out too well with, I mean, as soon as there's 10 developers, there will be conflicts there. So why, that's why I'm asking, like, does it really scale? I'm not sure. And that's why then later on there were some new things. I guess you've heard about them. Like, you can do pre-processing of CSS and you can do post-processing. So pre-processors, you've probably heard about SAS, SCSS, stylus, less maybe. Everybody kind of, yes, a lot of knots, yes. So there you essentially do something like transform from something CSS-ish to actual CSS. So often you have, like, more language constructs to enable you to do more fancy things. You have variables. You have mix-ins. You have things like that. And then you have actual CSS. And then from there you can do even one more step to go to the super CSS that is optimized. For example, you can auto-generate prefixes for different vendors or you can optimize certain things to be shorter or so based on certain rules and things like that. So a few examples. It's not exclusive to those steps. You can also, some of them you can also do after or before. But generally, yeah, you can do like imports, resolving functions, variables in your CSS superset. And then after you can do something like unit conversion, browser support integration and things like that. So this one is actually quite cool because you end up writing more efficient code. But you still have the same problems with globals and minification that is a bit hard and things like that. So let's look at a few code examples. For example, let's build some simple buttons. They are actually bootstrap. So some primary, secondary, some large and a small button. And, you know, it all starts at the beginning. If you write this in plain old CSS, you write a lot of code. And you end up doing things like, I don't know, WebKit user select none, MS user select none. I mean, who likes to write those kind of things or like look up in the documentation for which CSS properties you have to and for which you don't have to. Or you do like a lot of constants that are around like duplicated everywhere and then somebody will misspell one and the text color will be slightly off and you'll never know. And you also have those global variables. So a few issues with those global namespace. You have vendor prefixes you have to know by yourself. You have constants. And then you also have kind of inefficiencies in your CSS because you end up having a default style, which is like the font size of one REM, but then the button large has to override this. So essentially you define your font size twice in the style sheet for that one at the override, which can make it very hard to understand where the actual one is coming from now. This one is actually the CSS that is used in bootstrap for those two buttons. So when you use it, it looks something like this. You just add those button classes and you do that overriding. So you add two classes to make it a button and a primary button or the same with the large and primary together. So the next evolution, you know, this CSS you can do a bit better. I left out some of the code because there's even more for the primary. But what it allows you to do is like mixing. So you can do certain parts of your styles. You can extract out and have a more core logic about how it should look like. I'm pretty sure most of you are probably familiar and have seen something like that. Anybody never seen mixins? Okay. Let me quickly. So the idea is one part of your styles, instead of actually writing it out here, you just create a generic function which has some arguments and it will actually add the compile time when it converts this SCSS to actual CSS. It will take it and it will fill in those variables based on how your mixing is defined here. So what it ends up doing is it takes the constant here, padding y, padding x, and so on. Those are constants and uses those as the default button size styling stuff for the default button. And then your button large just uses other constants. So this one uses padding large and font size large and border ideas large, which will end up giving you the other style. And then you can even do more fancy things like iterating over an array of constants or so. So you can do all the different styles with the different colors by just defining the colors once and then iterating and automatically generating those styles. So this is actually quite fancy if you want to do some different styles and a lot of them and so on, which is quite cool. But we still have the same problem. I mean, there's still a global namespace which, believe me, if you have a large project, it will always come back at you maybe way later than you expect it to be, but it will not be nice. And naming conventions have never been a good thing or like have never been respected by everybody, I think. And yeah, you can do code reviews. I do it all the time. I always like comment comment. Maybe some of those guys can tell you. Yeah. So how many of you are using like front end frameworks like React or Angular or View to develop applications? Cool. Okay. So the next one might be familiar to some of you. Have you heard about CSS modules? So some smart guys thought like this namespace problem, we can actually solve that. We just for every component we write, be it like a React component or an Angular component, we just put the style right next to that component. And then it will only be valid locally for that very component. And nobody else will have access to that. And how that works is essentially you have your CSS file or your SCSS file or so right next to your actual component. So for React, for example, you have your button.js and then you have your button.css. And you just import that. And then you can use all the classes that are defined inside this with like dot style.button and style.primary. And then you just assign those to the class name in your JSX. So what happens behind this is the actual class name that is being used in your production code will not be button and primary, but it will be something that is automatically generated in the build step so that it will be unique and can also be very short. It can analyze everything first and then do the shortest possible one to be able to represent everything. So this is actually quite cool because it can minify. It is locally scoped per component and yeah, minify less in auto generated. And it also works with pre and post processors. So instead of CSS, you can also use less or you can SCSS or whatever you'd like to do. So now we've seen all of these. But why would we want to move it even one step further into the JavaScript? Because so far it's been CSS-ish at least. And usually like in a separate file, why do you want to move it in there? Does anybody have an idea why we would want to do that? We can discuss about that. So why is it a terrible idea? I think a lot of times the case against CSS stems from not really understanding exactly how it works and why it was designed in that way. To be fair, this is not widely documented, but the fact is that CSS as a stylesheet language was designed. It was designed by a group of people who put a lot of thought into it. And the issue here is that it does not behave like a lot of programming paradigms that people who see themselves as programmers and do this as part of their job. It doesn't fit in a general programming paradigm. And a lot of people find these hard to wrap their heads around. So in order to make it work for them, they try to fit CSS into a paradigm that they are familiar with and can better use in their day to day. So it's not to say that these people are wrong for doing it because they are finding a way to solve a problem that they face. It's just the objectively looking at the nature of CSS and JavaScript. It's a case of trying to fit a square pack into a round hole. I have, that is very well formulated, I think. I do agree with most of your points, I think. It's more like the developers are maybe not all ready to do actual CSS. And they don't know it that well. And you are faced with those challenges, so they come up with possible solutions. And that's why I think we're going to see a few scenarios where maybe it makes sense to do that. But if you had developers that are all your super unicorns, then probably you don't need it. But I think reality looks a bit different in a lot of cases. And so that's why some people came up with this. But we'll see what works out, I think. So I'll show you a graph which is the most used libraries for CSS in JavaScript. It has a bit of weird tip here because I think they lost data. So it's not that everybody stopped using that in December. But this is like the downloads of the NPM packages for the last six months, for the most popular ones. Yeah, but do you really think that, but it's not even 25th, it's more like 30th, I don't know. But maybe. The thing is, have you heard about style components before? Yes, have you heard about CSS or emotion? Okay, we'll look at those three quickly to see how they work. And you can see they are actually very heavily used. So this style component is like 600,000 downloads for NPM. It's like if you look at React, they have maybe 5 million or something like that. But a lot of people using React are also using style components, I think. And we'll do the UI thing to do that. So let's look at that first. So don't be too biased. Forget about everything you learned about doing CSS. So it's now in here. So have you seen template literals before? Maybe I have to explain them. So those ticks on the top and the bottom, essentially what you can do with ES6 is you call a function with a template literal and then the function will get not just that string inside, but also the information about all the dynamic elements inside. And that is being used by style components to know what parts of this will have to be dynamically evaluated. It looks kind of neat because it looks very similar to CSS, but it's in your JavaScript file. And it only looks like that because Visual Studio Code has some plugins to make it also syntax highlight, even though it's inside a string. And also autocomplete if you want. But yeah, so what you essentially do is if you know React, you do essentially always create components. So a React component called button at the top left is created, which contains all those styles that are defined here. And if you want to have some part of it be dynamic, then you can make use of the props of that component. So if I render a button with the prop primary true, then everywhere where you see a function argument here, this is actual JavaScript. So you do, this one gets the props and the checks is the prop primary true. And then it uses a constant colors primary or it uses constants secondary, if not. And you can do that for primary and you can do that for large. So you can also support the large button that you just put in more CSS, depending on that. So it allows you to do a lot of things, which is a good and the bad thing, I think, because you can't put it as much JavaScript as you want in here inside your CSS. And one thing where I think it can help is if you do those nifty things where you have your components accept some styling props and so on, then you essentially have a variable that has to end up in your styles, which is defined in CSS in JavaScript. And like this, you can actually share those very easily. Some part of your state you can share between CSS and JavaScript. Another question is, is it, does it make sense to do that in the first place? But this is a way to do it. And then as this grows, obviously, it might look ugly. So you might create your helper JavaScript functions to help you do that. And the cool thing about this is it supports media queries, it supports pseudo classes, and it supports all kinds of things, and it's automatic prefixing for vendors and so on for you. So you don't have to write that user select or mods user select and things like that. So yes, this template literally it has access to all your props of your components. It has JavaScript capabilities. And if you use VS code with the right plugins, it can also do syntax highlighting. Yeah, it is green because it's good. The other one was red because it was not good. So there are also bad things about it. We'll come to that later. Let's quickly look at CSS, which the idea is the same, you put your CSS in your JavaScript, but instead of having the nice fancy template literals, you just do it in an object of JSON. So you do define your classes like this, so you have your styles object, then you have a button class, and you have a primary button class, you can do extend like this, and you can obviously then use all your constants and so on. And you can put in all of those what kind of changes compared to normal CSS. You do camel case instead of dashes, you do commas instead of semicolon, you do quotes around everything. So it looks a bit different. It's more like what you would do for React styles. Personally, I think it looks a bit ugly. I mean, it's not CSS at all, if you look at it. Some people prefer this over the other syntax if they do CSS in JavaScript. But even here, you also have integration for React, so you can access the props in a similar way with functions. But you can also use it without React and then just do something like access those classes that are generated. But again, because this is all done at runtime during JavaScript evaluation, the class names that are actually used are being other generated for you, so you don't end up having that problem of naming conflicts and so on over all your components that you have. So whatever is defined here, it only has to be unique in that file where it is defined. And all the other files can theoretically use the same names. And the third one that we saw on the list is Emotion. So I think it wins the best logo award. But it is kind of similar to styles components in that like the API is basically the same. But they also have APIs to be compatible with that JSON format, if you prefer that one. And it has been coming up recently and gained a bit more traction because it's much smaller when minified and much faster in processing than style components. And it can also generate a static file out of all your styles that you have all over, which is quite neat because then you don't need to always regenerate it. It's very good in caching then. So if we quickly summarize those things, what we get for CSS in JavaScript is we have the full power of JavaScript. We can share state with JavaScript into our CSS at will. We can have completely deterministic styling. So at least if we follow some very basic ground rules, we won't like conflict styles from one file to the other and things like that. So it is isolated as well. And we can do a lot of optimizations to make the code smaller, to make a bundle size small, to make it efficient. And we could even do like code, that code elimination. If there is no CSS in your file anymore or no component anymore, then you can also delete the other part because it's most likely not used anymore. And yeah, so there are also cons. You have the full power of JavaScript. It can be very bad because you can do whatever. In the end, you still probably want to follow some basic ground rules. You still need to design your code and your CSS as well. And yeah, you sometimes have some very unusual syntax that JSON thing. I think you have to get into it if you really want to use it. Right now, the editor support and so on is not that great, but it's coming up. So you don't have all the tooling around it yet. But a lot of it is already in the actual frameworks you're using. And then some framework has shortcomings. So some don't support service side rendering on the React or they don't support vendor prior fixing automatically and things like that. But there are some that too. So just choose those, I guess. And yeah, I think the main takeaway is it's not like the silver bullet that does everything for you. Even if you use it, you still need to know CSS. So you still have to fight the exact same problems with putting your boxes in the right place and aligning them right. So if you consider using it or you've been using it already, what you should look out when you choose a framework is you probably want to look out which syntax do you prefer. I think a lot of people are split between style components and CSS just because of the syntax because all the other things, they basically support the same use cases otherwise. You want to look at the feature support like vendor prefixing pseudo class, media queries, things like that. Probably if you do service side rendering, you want to look if that works as well or if it has to be in the DOM with a real window element and things like that. You want to see if it has static file generation which can be helpful and the performance generally. So does it really, if you ship a whole CSS in JavaScript library with all your bundles, then maybe it is just 20% bigger or something like that? So that might also be a problem. Well if you do the traditional CSS, most of the time that doesn't change as quickly as your app file maybe. So you don't have to download the new one when you update your app or things like that. So that might actually help in caching in the browser and speed of the site and so on. But keep in mind if you want to do that, maybe ask one question first, do you really need to share state from your JavaScript app into your CSS or the other way around? Maybe you can also do it without. If so, I would recommend maybe use CSS modules which is very well supported with just Webpack. So you can just add some Webpack configuration part. You have your own files. You can add pre-processor very easily and post-processing and then you're also well-served I think because you still end up with the problem that your styles are spread around everywhere in your files. So for the last three minutes or so, I'd like to quickly give some insight about what we experience in our project. We're using styles components for a video streaming platform. I counted yesterday there are 100,000 lines of JavaScript code. It's a lot. I think about 30,000 is for video streaming and maybe, I don't know, 10,000 is for CSS. I don't want to know. So what we encountered when we used it, I think there are a lot of pros. It is actually quite quick and efficient to create new components and to do styling of those because you just add that file, you add the styles in the same file. It's nicely and tight together and that has some benefits. It's very easy to find the styles that are applied to your components rather than looking through globally shared states and so on. And then when you change some part, it might affect something in a completely different place in your app. Challenges are like, yeah, the first one, it's very nicely formulated because there is some memory leak installed components, server-side rendering. We're trying to find how exactly we can go around it, but there are also GitHub issues. So we're not sure. Right now, the server just restarts every few days. So that's okay. It might also be because we're using an old version because we're kind of behind in the React version upgrades. But still, I mean, if you want to have high-quality code, you still need discipline. So the same kind of rules that you have, if when do I create the React component that is reusable, you also have the CSS to share then and to look out for. So in the end, you still need to use good CSS and look over those things. And I think one of the other drawbacks, because your styles are so spread around your whole app in all the files, you quickly have duplication all over. So you add a new component, you import some kind of helper you had for font styles. And because you didn't define them globally, because you do everything in the components, you have the font style defined in every single component. So your CSS is also too big. What I think is actually a potential of this is if we think a bit further, you can do very fancy stuff in analyzing all those CSS styles that you have. So you could actually extract those and share them in one single class that might be applied to everything. So your CSS still gets smaller, whatever is shared in a lot of places. So those are a few of the things that might come in the future. So I talked a lot already, I think. But what I'd like to know maybe a few minutes, you can share your experiences that you made, what was bad or what was good when you used CSS in JavaScript. And yeah, maybe anybody wants to say something? There were a lot of hands earlier who used it. Yes. Okay. First of all, let's give you a round of applause. I think it was a really measured presentation. Just disembodied voice in the video. Okay. So I think here Dominic already raised the point where he said that even if you use something like CSS in JS, you still have to know CSS. I think that's the most salient point. And at the end of the day, all these different techniques and all these different, I would say, ways of handling CSS, they are mainly tools. I think what's most important is the people, you actually sit down and consider the choice of approach, whether or not it fits your project. Because sometimes I believe that CSS in JS, there are valid use cases whereby CSS in JS is the best approach for that particular project. The thing you have to ask yourself is, is that your project? So I think the issue here is people, this process of evaluating what you really need is not an easy process. And especially if you're not, if you've just gotten started, that's even worse because it's just confusing. And then you're just tired and you just want to pick one and use it. So it's a very legitimate concern. But I feel that as you have gone through, you gain more experience, it's really worth the effort to be more considered in picking these approaches. Don't pick it simply because it's the most popular approach. Because even the most popular approach might not suit your particular project. I think there's a lot of, and there's always a lot of value in understanding how CSS works. Because without that knowledge of exactly how it works and how it behaves, you won't be able to make an informed choice. Yeah. Cool. Thanks. I mean, I completely agree on that one. Evaluate first. One of the very common examples about don't pick what is the most popular is probably Redox, if you do react. Everybody uses it, but I'm not sure it's quite overkill in most applications, I think. Another one, if you look at Git, even Linus Torvalds, who actually wrote Git says he doesn't understand why everybody's using it because it's way too complex for the use cases most people have. So I mean, we can maybe learn from that. But yeah, I mean, you really need to know CSS to do it right. So that's also why I think it's more appropriate to have this talk in the CSS Meetup rather than the JavaScript. Good choice. Does anyone have other opinions? You wanted to use Apollo? No. Okay. Yes. Okay. Applause, please.