 We're going to have an interesting time here because This is the first time I've given this talk and usually every time I give a talk for the first time It's got some rough edges around it because I prepared it within hours of giving it so The good news is that I'm giving this talk tomorrow So if you feel like not watching me fail potentially here You can come to LinkedIn in Mountain View tomorrow and watch me give the same talk over again Or you can go to New York in a week from Thursday, and I will be giving the same talk there They're gonna get a really good show so So and and Rob's gonna be everywhere with me So you can also see Rob speak at in Mountain View and in New York as well He's gonna be talking to us about something just as cool if not cooler than what I'm gonna be talking about so My talk is titled taming CSS and Ember JS apps and really This is like burying the lead a little bit. I think of a title I Have been Well, I should introduce myself Bryn, I see a lot of familiar faces in the crowd. I've trained a lot of people probably here I do ember training and consulting. I've been doing that stuff For basically five years almost now if not over that I've been involved in the ember project basically from the day it came out and I've been a longtime member of the Ember JS core team so Warning I have a lot of controversial controversial viewpoints about CSS that you're going to be subjected to during this talk This may be one of the talks that I regret giving but somebody needs to give a talk like this I think and So here I am to kind of share with you The thoughts about CSS that I've been formulating over the last year that I've been in seclusion I Was at Ember conf and many people were like, where have you been man? And the answer is I've been thinking very deeply about CSS And and it's not been necessarily a great time It's had its ups and downs, but I'm very excited to be sharing with you what I've what my current thoughts are on CSS today So It's quick plug. I'm doing a very cool little advanced Ember JS mentorship program check out this page If you're interested it starts June 7th, it's kind of innovative It's six weeks two days a week for two hours a day and we're gonna build four apps It's pretty cool. So if you're looking for advanced training, this is the place to go so Who likes CSS here raise your hand Good There's a lot of reasons to like CSS I'm going to hate on it a bit But not too much really, I think CSS is a remarkable technology and you can see Our friends in native land Like CSS quite a bit and they like it so much that a lot of times Mobile and native apps will just do a ton of stuff in web views because it's easier to lay out content on The web than it is on any other platform Okay, so CSS is something to be cherished But it needs some help to scale I would say So It's awesome, right? Metaphor This is how I write CSS usually I mean, you know, I've actually been very spoiled by CSS and Primarily, I shouldn't say I've been spoiled by CSS I've been spoiled by the teams that I've gotten to work on because I usually Probably over the last five years of being like an Ember expert the amount of CSS I've written is probably ridiculously small in comparison And I want to change that and that's kind of why basically I feel powerless To some extent when I want to build a web application and I want to do it on my own over a weekend I feel powerless to do so because I didn't accumulate the wealth of knowledge that the really great CSS wizards on the teams that I've worked on already had and I want to build something that lets me as somebody who doesn't want to be an expert in CSS Do amazing things like they can okay, so I Feel like I'm doing web development in assembly still despite the fact that we have all this great tooling on the JavaScript and markup side with Ember and HTML bars and You might as well I feel like I might as well just kill myself right now instead of write CSS For a reasonably complex application So I think I'm perhaps better title for this talk might be CSS the good parts I pay homage to Those who have come before me With this title, but I think really my controversial viewpoint probably number one of the evening is that Basically the number one best thing about CSS right now are classes Classes are amazing. I'm gonna touch on this a bit more I have a very controversial opinion, which is that you should basically write no CSS that is not a class So do not use IDs Do not use element-based selectors and in fact I would go so far as to say do not even use Descendant selectors in any way shape or form treat CSS as if it was a key hash The keys are your CSS classes The values are your property buckets of rules What's the second best thing? Basically nothing. All right Classes are the way you should write CSS You should not write it any other way and I'll try to elaborate on this a bit more But I have some patterns I think that I that are the way you should write CSS and I'm gonna try to touch on as much of that in the 30 minutes that I have so Again, my name is Eric I have a problem and that problem is CSS and I think the first step to Solving this problem is to accept that you have the problem and I'm curious How many of you raise your hands if you feel like you have a CSS problem? Right, I mean I feel like who so when I do training and stuff usually when I ask a question in the affirmative People will not raise their hand So I'm curious are there too many people do if you do not think you have a CSS problem Raise your hand, please. Who does not have a CSS problem? All right Well, do you guys keep your hands raised if you think you're an expert at CSS? Right, so basically the people that don't have CSS problems are the CSS experts, right who have figured out the right pattern For them to write CSS in as bulletproof of a manner as possible, right? I Want to bake patterns like that into the way that we write CSS in ember applications So that if you learn ember you learn how to write CSS in the maximably You know successful way that you will avoid every possible you know Pothole that you're gonna run into right so we're gonna try to talk a bit about what I think that is right So we have a problem. What are the problems with CSS? This is a short enumeration of the high-level problems. CSS is globals based programming What do I mean by this? Every CSS rule you define is like defining a global variable on the window in Javascript Okay, the rules that you define are Tech debt Every rule you write becomes tech debt the second you write it And the worst part about this is that they're globals, right? It's a disaster so I Have a controversial viewpoint which is that basically you should not write any global CSS The only global CSS that I believe is allowed is like font Font and font size on the body or HTML element. That's the only global CSS you should probably ever write so What else so it's obviously globals is a problem and the reason that globals are a problem is because we lack Modularity we lack mechanisms to have encapsulation and isolation in CSS. All right, so I'm gonna prescribe some ideas for that Dead code removal who has ever successfully deleted CSS without breaking your application raise your hand All right, that is a problem We should be able to do that who has ever successfully refactored CSS that other people relied on and did not break What they were doing raise your hand All right, nobody raised their hand We have a problem here people, right? This is general programming Stuff that we should have a grasp on in 2016 yet. We do not yet with CSS, right? This is very problematic a lot of my initial thinking was influenced by this talk by a member of the reacjs core team I think this is a great talk if you haven't seen it the slides slides are pretty good They enumerate a lot of the problem space That we're trying to tackle and they do prescribe some solutions I do not agree with some of them, but I agree with others To be clear you might notice this thing is called CSS and JavaScript. I Do not think CSS and JavaScript is the answer. I think it's actually a bad idea, but I Understand why they think it's a good idea and I've been there at times That's like hitting the you know, that's like writing CSS and JavaScript is like the extreme escape valve For kind of solving some of these problems, but I've challenged myself to not Go that route and to find solutions that work in CSS today Pragmatic things that we can do today to start challenge to start solving this problem. So globals so Everything in CSS is global. So the best thing we can do is to write globally unique class names right There are conventions like BEM or smacks or whatever that prescribe rules for naming classes globally I think those are generally good ideas I'm a fan of BEM personally, but honestly, I think that it's ridiculous to have to write them by hand And so I want to prescribe a tool that will auto BEM all of our component styles All right, so I'm going to talk a little bit about that later, but that tool does not yet exist I'm in the process of building it and actually you have in potentially to help to thank for helping build that tool over at nest Shadow DOM is another possible solution. These both have caveats Because there are kind of solutions here Most of the existing solutions are not perfect for one reason or another Shadow DOM unfortunately is one of those solutions that I do not believe is perfect and I think that I've gone to a lot of Effort to like defy is a system that works today without shadow DOM But is somewhat forward thinking about shadow DOM and is compatible with that world Why what's the there's I'm not gonna talk a lot about shadow DOM But I'll give you one brief description of why shadow DOM is kind of not ideal Shadow DOM is a little bit too much like an iframe for your CSS. What does that mean? It means that imagine in your ember components you had to import all of the core styles that you used every single rule right so basically it's not awful but it's hard to iterate towards and I feel like in fact if you write CSS the way that I prescribed shadow DOM kind of falls out Because you don't write global styles So you don't have global stuff you don't have a lot of shared styles and you're gonna write component specific styles You're not gonna have a lot of stuff to import in your shadow DOM I have some concerns about performance of shadow DOM to these are mostly unfounded I'm just suspicious because if we're gonna tell everybody on the web that they need to like import Their common style sheets then we've got a lot of duplicate style sheets loaded in memory And we're potentially we have hundreds of those on a page at a time And then I think they don't really have a fully baked shared memory system in mind for these shadow dot root boundaries and stuff But I'm sure that's gonna come with time. So I don't want to put who shadow DOM. I think it's a great technology I just don't think it's as iterative of the technology as we could ideally have And I've tried to advocate for having some kind of intermediate Step, but I've unfortunately not been able to get much traction with that idea on the the standards and on the browser vendor teams so TLDR is I say we can write we can have conventions for Writing our class names globally unique and we can have tools that make it easy for us to do that by default Modularity so this is a bit media of a topic I would I would I would challenge you to rethink the way that you write CSS completely and try to draw parallels With the way that you write JavaScript code CSS is unlike anything It's it's really a kind of bizarre programming System programming. I dare call it a programming language. It's not it's kind of a weird declarative System, but it's unlike anything else And I think this is a lot to blame for the problems that we have with it at scale And so what's an example of this? Well Basically, there's no concept of a module in CSS, right? We only have the global scope. There is no such thing as like a Sub-scope. I'm gonna talk a little bit more about this I think though the good news is that we have preprocessors today that kind of give us faux modularity and It's not perfect, but it it's a thing we can use to do our jobs today and it'll be interesting to see there are some there's a bunch of you know Alternative like systems that are doing good work in this space But I unfortunately don't think most of them have quite cracked the nut fully And hopefully I'll have enough time to convince you that maybe I have a little bit Or at least get your interest because honestly this talk is probably like one in a series of three There's a lot of stuff to talk about here So I'm gonna try to scope this down to the bare essentials. So I Want all of these things to be true. I want to be able to delete and refactor CSS Just like I would JavaScript code and I ideally wanted to do that feeling confident When I'm doing it. I Am a strong believer that runtime overrides. This is pretty controversial runtime overrides should be avoided at all costs Now that is pretty crazy sounding. What do I mean by runtime overrides? I mean Basically, I am not a believer in like the bootstrap model of CSS So bootstrap, let's say beat button has a BTN class Do you like BTN you do BTN default and then maybe you write your own class that overrides some of things that BTN default did I think this is generally a bad idea Why because you can't actually like look at the markup and Really like understand what that thing's gonna do You almost certainly have to open up the dev tools look at the style inspector and like look at what actually happened Right and and it's not fun to live in this kind of Unconfident world of writing styles and writing apps So I would like to see tools that like Linted and when we could actually catch ourselves when we're trying to override a rule that already existed and It would yell at us and say, you know Kind of like how JS hint would if we'd like to clear the same variable twice in a function, right? I think we probably need something like that And runtime overrides reek they wreak havoc on our ability to refactor Why because when somebody overrides us if we're bootstrap who's done a bootstrap upgrade does anybody done a bootstrap upgrade It's a disaster especially if you didn't have the foresight to use variables to do most of your customization If you did runtime overrides, you're playing whack-a-mole. You're like, why did this rule exist? Oh, it was to override the behavior of bootstrap to that's not no there in bootstrap 3 Right, so it's it's insane And that's why I believe that styling needs a public API For overriding. Okay, so we're gonna talk a little bit about what I mean by that This is a this is the like core tenant. I think of my belief system around CSS is that we need public APIs For our CSS We need to treat our CSS like we would treat our components Components have public APIs Why don't our styles? I think functions are a really good metaphor to think to frame your thinking around this stuff Here is a function What do functions have they have arguments and they have return values? Right So you pass data into a function and then it returns something That's likely dependent upon the arguments you passed in right Maybe even it's a pure function. That'd be great No side effects Here's a component a Component is like a function you pass arguments into it. What does it return? It returns some rendered markup some rendered DOM that gets appended to our document body Right where it's paranoid CSS does not have functions. This is very problematic This is I believe the nail in the coffin of CSS Good news sass does What are functions and sass? They're mix ins so I dare to Suggest that perhaps a pattern like this is Quite good for implementing your component styles What does this give us? Well, it gives us a function Right, what can these functions have they can have arguments? What does a mix in return in sass it returns a set of rules? right Those rules get here's our function getting called with that include Right now we could be optionally passing parameters here It has positional arguments and named arguments. It's quite nice What's gonna happen? Well, whatever rules we define in that mix and are going to get Added into our my component class, right and here we're gonna have a convention We're gonna say that your component should have a you know your component has a unique name globally at the minimum We should have a class that Is coupled to our component name and that is the you can almost think of it as like the namespace It's actually a prefix for all the rules That are component are all the CSS rules that our component has right So I believe funk so functions are units of work You cannot have composition without functions You can building ambitious apps requires composition. We know this already with components They're great We need the equivalent in CSS for composition Mixins are the closest thing we have to that today Building ambitious apps also requires conventions to do it at scale so I've met my first foray little did I know I actually wrote this add-on ember components CSS like during ember conf last year and I Got I was like man CSS really grinds my gears and I was like, you know what? There's a lightning talk spot. I'm just gonna build a thing and I'm gonna start talking about CSS and I Wish I should have gotten a screenshot I released this thing and I started posting issues on it about my my ideas and then it became like big-ass threads of everybody bike shedding the hell out of my ideas and Telling me why I couldn't constrain CSS the way that I wanted to basically it's too Too crazy and so that was that was unfortunate. I don't think that people are I Part of the reason I want to give this talk is just to make you aware of the problems You might already have and I'm gonna lightly some prescribe some stuff in further talks I'm gonna actually talk a bit about some of the stuff that I'm building that's gonna make hopefully some of these things baked into ember and maybe even become part of ember if I can survive the bike shedding of the core team so Component base CSS this ember add-on ember components CSS what this was really about which I don't think was that Shocking of a concept was that We've got JavaScript files and it handlebars files for our components We should also have a CSS file right most people do this already, but they do it in an ad hoc way They're probably not diligent about their naming. You know, it's annoying So this was a system that piggybacked of concepts of pods And ember sale I and gave you the ability to drop in a CSS file in your pod directory And it would automatically slurp them all up So you didn't have to write manual at imports or any of that stuff yourself, right? And it did have one I did the easiest thing I could in the hours of time that I had you know Prescribed for this before going up and talking about it ember count and that was to basically say the good first step for behavior that this component could give you is to automatically nest All of your component styles in a globally unique identifier. Okay, so what did that look like it basically just meant, you know Everybody's probably familiar with sass. It meant like you have my component and I actually generate some kind of random number So that you can't guess the name of it and Then I wrap that thing around all your styles. So they're all descendant selectors though, right? I knew at the time that was not ultimately the endgame, but It turns out the endgame that I've wanted to get to is quite complicated and it's actually difficult to pull off Around the constraints that have existed in ember CLI actually And there's a lot of unknowns and it's taken me basically I wrote this out on like what March 2015 here I am April 2016 Still not done executing on the vision that I have for this add-on, but I'm here to tell you What I'm thinking so that hopefully I can enlist your help Or convince Robert and then he'll just do all the work for me. It's quite amazing So Component-based CSS I think is a really important concept and it's not controversial. Everybody's pretty much on board. I Also prescribe as a convention BEM It ultimately doesn't actually matter as long as you have a consistent naming structure that will get you Globally unique class names, right? What the heck is BEM for those of you who do not know it stands for it's an acronym for block element modifier What does this mean? Well block basically means component and ember element means some Subarea of functionality inside of that component. So let's say you had a button that happens to have a label Modify the modifier the element is like the label tag that you might have inside of your components template, right? And then modifier is things like states like disabled or active or focused or whatever the different states that any That a block or an element might be in and so you can check out get BEM calm. It's really really basic stuff. It's pretty simple Basically, though what it prescribes is a pretty bulletproof way of I have the wrong page up It gives you a pretty bulletproof way of naming things where you will not accidentally make mistakes of like using Dashes only as delimiters because you actually want to make sure like dashes are valid in component names So you don't want to like Accidentally define rules that happen to end up being the name of a component later on And so for example here, we've got a modifier modifiers use double dashes So imagine this would be like my dash component double dash hidden or disabled or whatever There's also Elements and those use underscores The reason we're not we're using double dashes and double underscores here is to differentiate from a single dash Which might end up being the name of a component that gets created later on Right, so it's important to have some kind of delimiter here I envision a system that is not just BEM But it also adds GUIDs that people can't guess and this gives us Imulated encapsulation and isolation a la shadow DOM and I'll talk a little bit more about that but So my auto BEM add-on would an ember component CSS kind of does this But basically the idea is that you don't know what the hell your class names are And I'm gonna write you a clever add-on that you get to write nice CSS The way you would expect to write it in a globally scoped environment. You can write dot urgent And that's automatically gonna become My component dash dash urgent or underscore underscore urgent or whatever, right? And then if you wrote urgent in your components template and I also transformed that for you as well automatically, right But then I also added these hash these extra random digits Because that prevents somebody who doesn't understand the naming system from accidentally using the CSS somewhere else That was only meant to be used inside of a component itself. Okay, so long story short on that Let's dive into some code. This will be the interesting piece so Let's see I didn't really plan this part out too well So Let's look at a very simple example So this is without an auto beaming tool so Here's what a button might look like this is a fairly complicated button And unfortunately it has a lot of it has some theming information baked into it. So it's not super abstract right now And there's some funky stuff going on here But basically we've got a mix in name the same thing this now I'm starting to prescribe some possible solutions, and I'll try to recap a little bit We got a mix in name the same thing as the clone it All right, I'll turn I'll come back to why this is important later And we got a bunch of rules that are nested inside of that now note most of them if not all of them are using ampersand Right. Why is that? Well, because wherever you mix it into Now these rules are going to be concatenated onto the class name that the mix in was applied to Right and though this is doing prefixing for us, right? So inside of our Our button we get to kind of write It's a little ugly with those ampersands, but we don't have to write my component dash dash We use the ampersand to kind of do that for us, right? So Let's see Here's a very simple example, right all in a few lines Nothing too fancy here. Now what is nice about this? This mix in has a public API Right, what is its public API it's these parameters that you can pass in So if you want to override my simple button You can include my sass file and you can invoke my mix in in your own Components class name and you can provide any overrides that you might want into it and Now I have created an abstraction Right and this abstraction is very important because I don't want you to write CSS rules for my component Because what if I let you do that if I let you do that then I can never refactor my component Out from underneath you ever again Because you've done the same you've created the same problem that you had with bootstrap 2 to bootstrap 3 Right you wrote a bunch of rules that were hard-coded to the assumptions that I had of my implementation strategy at the time Right with something like this. I can actually abstract myself now just like a component does right? You invoke my button component. You don't have to care how I give you a button how I render it and handle the behaviors You just get the care that you got a button and there's a click action or something right? This is the same kind of principle for CSS as well I think functions are a minimum like the minimum requirement to create this kind of abstraction Let's take it up a notch and let's do some composition. Let's see us actually doing something interesting with these mix-ins So I have a default button type. Oops wrong file. I have a default button type that actually is pretty complicated It's a pretty a cool button I've been talking a lot at you. So I'll throw you a bone and show you some demos. So here's my buttons here They're pretty cool This is a default button and It has nice active state Right, it has nice focus ability right Here's my primary button really the only difference between my primary button and my default button is that it has a blue border with some gradient Right, so actually this is a very cool example because this is actually a gradient border Who knows how to do this in CSS a few of people I'll tell you what it ain't border colon 1px gradient. Okay? It's actually really it's actually challenging. Luckily. I have a wizard CSS wizard helping me build this shit so This actually requires Different markup to pull off properly all right now Big teaser I've actually come up with a great abstraction for how we can do that too All right, but that's out of scope for this conversation if you're interested in theming Come talk to me afterwards and I might hire you to help me so theming I think is next-level shit and Theming requires Not just assuming that you can override CSS properties to theme because theming requires sometimes different markup for implementation strategies So you need a delegation pattern for layout to do that well and if you're Clever you'll figure out the name of this project and you'll see it's wide open on GitHub. You can see what I'm doing so anyways point is though basically Primary buttons just have a like a different font color and a different border, right? So ideally I Don't have to rewrite or duplicate any of this CSS that went into the default button. I should be able to just use its mix-in and compose in CSS right well guess what I Can here it is I Got my primary. I use the mix-in of my default arguably I might I should probably have an ad import here, but I don't currently Button default here and it has parameters it has a public API It has like a background color and a color arguments and I can pass those in now the cool thing about this is that My button default knows that borders are gradients and it actually does some relative stuff Like you passed in the color, but it's gonna use Things like lighten in sass to automatically generate the gradient based off the single color you gave me Right now this is this gradient border stuff is purely a concern of the of the button default variant and It actually doesn't exist in the base class. There's actually a base class of this button, which is simple And simple doesn't know anything about fancy gradient borders. It just knows Very simple stuff. This is what a simple button looks like right now It's just like a square Right and the hope is that simple is the base class. I can compose its mix-in into default I can extend it perhaps as well and then primary can extend default and We have a reasonably robust system of composition that is akin to what we can do today already with components right so There's a little bit of code. Maybe I'll have I'm probably way over time already, so I'll try to show you some more Conventions really need to be the default. We need to help you fall into the pit of success when writing CSS You shouldn't have to be a wizard to do it. Well, it should just be the default of the framework. I Want to release a version of 1.0 of ember components CSS that fully integrates my current thinking on these things and at the minimum that will be the the bastion of sanity of CSS in the ember world but I am Excited because and part of the thing that's blocking my my work here is that we actually need to ship our New pods RFC, which Robert probably hates me calling it in that but there's a great modules RFC has anybody read seen this yet If you're an ember developer every day and you haven't seen this get on it right now because we're Completely reorganizing your app folders for you So you might want to know what it's gonna look like and tell us if you think it's a bad idea So check out this RFC It's actually and we've got an automated tool. You can go to this RFC. You can check out this rendered output It's pretty great stuff I couldn't be happier and thank you to you can all think Robert and Dan get part on the core team for championing this this effort, but We've got a I think really really great if you've used pods You probably have felt some pain around them. You're using the standard layout. You're probably feeling pain around that I think this is as good as we can get To bring the two worlds together and have a beautiful file structure for ember application Development from now on and the cool thing about it is that add-ons Engines apps are gonna all just be the same damn structure There's not gonna be any more wacky like app folder and add-ons and all that stuff We're gonna have namespacing so your add-ons don't clobber the global If you have the add-on that installs a component name the thing in your app it doesn't like have a clobbering problem apps win, but You can actually will be and it'll be able to invoke components with a namespace Prefixing them and it's gonna be great great great stuff. So check out this RFC and I'm gonna my solutions are all built with this in mind Their future thinking in that regard and there's actually a great link in here You can actually see ember my Robert wrote a migrator and this is ghosts open source admin app ember app You can actually navigate it The the thing of note here is like UI is where most of your UI code lives in now There's some folders here that are useful. These are kinds of like, you know This is akin to like the app folder today kind of except the routes has got a pods like behavior to it now It's very very cool. I really can't I can't really say anything more about it other than I love it And it's going to enable some really really awesome stuff I'm going to be I have some crazy ideas about single file components Meaning file components that everything for the component can live in one file CSS it JavaScript and markup all in one file using the JavaScript module system. I know on bonkers, but this system is actually Planned for that it actually just works seamlessly and it's heat. It's all just beautiful So please review this RFC and we'll hear Robert talk about it tomorrow at LinkedIn so I Intend on writing an RFC To ember with my viewpoints in them I Don't know when I'm gonna get I'm gonna get as many core team members on board first primarily you who done I've already been kind of like thought leading yahoo to about some of this stuff Because as like basically if you win you'll do to you're pretty much likely to win the rest of the core team over He's usually the hardest one to battle He's the ultimate bike shatter so I intend on taking these opinions To the core team at some point in the near future Via an RFC and hopefully getting these things baked into the framework now You may hate me for this if you do not like the way that I write CSS but I Think it's important that we have something and so if you don't like this stuff Please let me know and I probably I'm a few steps ahead And I know there's some faults that you might think this system has but there are actually solutions to those things as Well, particularly I'm curious how many of you already worried about the bloat of the CSS that will be emitted from the system Is anybody worried about that yet? Yes, what we're gonna build the best freaking optimizer that ever existed for CSS Because we have whole system knowledge. We know what the classes are you're actually using we could tree shake unused rules in your CSS We could do anything we want here So really It's just a matter of putting in the blood sweat and tears to make this system work and be as optimal as Possible on like the emitted CSS output, but we've already I'm already thinking about that stuff And there's a there's a plan for how we can do that. It's really just a resource problem. Like we just need Volunteers to help build this stuff because I can't do it all myself And so I think reponsive Reponsive design needs everything Responsive design actually the way we do it today. Here's another controversial thing. I think it's actually just wrong It's like really bad respond the way that we would do responsive design Flexi is actually a thing that already exists out there. This is based off of so I've been gone for like a year I started writing some of these things as Add-ons that never got released flexi is actually an extraction of my layout system that I was building and It has the responsive design concepts built in if you have not seen flexi yet. Go look at it. It's pretty cool It's not perfect But what if I told you you could have templates that were specific to the breakpoints in your application? And they automatically just rendered when that breakpoint was hit So you can actually have you can use if statements if you want to you'd say if it's mobile show this if not You can do that kind of stuff in a grand and like one big template Or you can break out the mobile view for your component as a separate template the tablet view of your component as another one They have these kind of stuff in iOS. It's called adaptive layout and they have storyboards that are specific For different platforms. This is kind of taking some of those ideas and bringing them to ember and the web And also flexi is an abstraction on top of Flexbox So I'm really interested in ups in layout as well layout's a huge problem Wouldn't it be great if you could just have a two-column layout by saying H box Box box. That's what flexi is. It's a two-column layout. It'll be 50 percent. It has a grid system check out flexi It's really cool, and it's I'm thankful that runs fired for taking some of that work and making it real so Like I said, I need your help and I'm even maybe willing to hire you to do so I have some budget for this the thing is I've done a lot of consulting at a lot of companies every Company I work for has problems these problems and I'm really fed up with it And so I'm actually like spending my own damn money to fix some of these problems And I'm getting my clients on board to to help fund this work And so if you're interested in helping, please get in touch so I Flew through that I'm sure you guys have some questions Let's fire away. How much time do we have? Three questions great. Yep the HTML bar stuff So let me let me I think I skipped over some important bits in the name of time so The optimizer so here's the big problem with this system. I'll tell you the fault with it right now And I'll tell you how we're gonna solve it when you look at the output at CSS of This system with mixins You are going to end up with a ton of duplicated CSS rules Mixins aren't doing any kind of clever optimizations currently in sass Basically every time you include a mixin every time you want to create a sub component That's gonna use its parent component styles You're gonna get a complete copy of all of the styles from the parent component and that can be cost prohibitive Right, so let's take a quick peek here. I think this stuff lives in vendor CSS So here's like my simple sass output close the console So hey, what the hell? So Let's see if I can find some duplicate styles. So here's default button So here's all the default button styles guess what? We keep going a little lower. We're gonna find primary button Here's all the same duplicated styles that are actually mostly identical With default button sass has a mechanism to solve this problem called placeholders We can be clever and I'm hoping some of the automation that Ian and I are gonna do is gonna enable some of these things to Automatically become placeholders in your mixins and then that will allow placeholders will actually are pretty cool And sass if you define rules as placeholders They will share the rules and you'll just get like comma separated selectors for everything that shares The common set of rules now this can be problematic with sass You actually need to actually the way you can do this effectively is you actually the way you do this today manually There's a great article. I should link to you basically separate the static bits and the dynamic bits as two separate placeholders And then the the static rules will get all shared across every subclass, but the dynamic bits will be unique per class I think we can automate that. I really think we can automate that stuff away So Tools are gonna be important to kind of making this succeed What else can we do well placeholders are cool and all but they're pretty manual What if we can actually just analyze the rules that are emitted and actually find all the common rules create Classes that just define those rules and if we understand we've got Ember CLI We've got this great build system We have full system knowledge about the markup and the JavaScript and the CSS We can actually look at the dependency graph of your CSS rules find all the common stuff Create hoisted we're gonna hoist the rules up to like global classes And our templates can automatically include those classes What is this thing? It's basic who's used ever who's ever done functional CSS or comic CSS? There's some people. I'm sure anybody no Basically, they're kind of an interesting group of people that are saying every property combination of CSS rules should be defined as its own unique class It's kind of a little out there, but the cool thing about it is that actually It's basically just the optimization by that. I'm envisioning by hand if you can find all the common sets of rules and hoist them and Create classes for them You can even minify those classes with this optimizer by the way You could minify your CSS classes and the templates will automatically get rewritten to use the modified classes and stuff like that Anyways, I wish I had I don't have a demo of this. It would be cool to see but hopefully my description makes sense Yes, it's absolutely Yeah, I agree Sorry Yeah Yeah, so right now we're planning so there's a few different ones out there right now We're planning using Salesforce wrote a great SS SCSS parser that we're planning on using SCSS parser So this lets you just give it SCSS and it will create an ST for you that you can transform and you can analyze and basically We've got like an ember or the ability to build the mother of all ASTs We can build an AST of your CSS we can build an AST of your HTML We can build an AST of your JavaScript We can analyze the whole system and we can optimize the crap out of it for you automatically it's just gonna take effort to build that and It's valuable because we get to then write our style I mean, it's a lot of effort you might think maybe atomic CSS or functional CSS is better in the short term But ultimately we want to be able to write our CSS like we write our components Right like we write functions like we write JavaScript and that's gonna mean having concerns localized on The in the components CSS file right like you're gonna just want to be able to write the simple rules and then let the system deal with optimizing it for you Post-css has a CSS parser. There's a numerous number of CSS ones I'm basically what the controversial thing I'm thinking is basically as sass is one So we should probably just use sass by default. Sorry post CSS fans. I Like post CSS honestly, I we're gonna use it for some of this work because it's easier to transform the ASTs with post CSS than sass directly right now, but sass is I think kind of the winner although I Would like to write my own CSS preprocessor on top of glimmer too, but I don't that's a whole nother level of crazy So anyways Yeah, so one last question and then I'll leave you alone up. No no more questions. Anybody have one pressing all right We can talk afterwards so I Hope I was not so ridiculously over time Thanks everyone for listening to me ramble about this stuff. Hopefully I've piqued your interest You're gonna see me giving more talks about this. I'm gonna keep these talks are gonna get recorded I'm gonna keep honing my message and hopefully You'll make sense out of all this stuff that I've been saying and it will make sense to you And you'll want to use it and maybe you'll even want to help me build this stuff because I think it's really important for the future of web development, so thank you very much