CSS-in-JS: FTW || WTF? - Speaker Deck

Slide 1

Slide 1 text

@brucel

Slide 2

Slide 2 text

@brucel

Slide 3

Slide 3 text

@brucel

Slide 4

Slide 4 text

@brucel

Slide 5

Slide 5 text

@brucel

Slide 6

Slide 6 text

@brucel

Slide 7

Slide 7 text

@brucel

Slide 8

Slide 8 text

@brucel CSS-in-JS

Slide 9

Slide 9 text

@brucel document.tags.H1.fontSize = "20pt";

Slide 10

Slide 10 text

@brucel Cascading HTML style sheets proposal font.family = times font.size = 12pt h1.font.size = font.size * 3 h2.font.size = font.size * 2.5 h3.font.size = font.size * 2 strong.font.weight = bold space.above = 4pt space.below = 4pt space.first = space.left + 0.5cm # i.e. some extra indentation head.space.above = 15pt # straying from the 4pt default above https://www.w3.org/People/howcome/p/cascade.html

Slide 11

Slide 11 text

@brucel

Slide 12

Slide 12 text

@brucel Håkon Wium Lie When I first proposed CSS, JavaScript was not around so I couldn’t borrow it from there. Rather, the syntax was inspired by X resources from the X11 Window System. The reason for changing the CSS syntax from font.size to fontsize was twofold. First, the hyphen makes it look more like written English, which improves human readability. Second, DSSSL and DSSSL-Lite used hyphenated property names. https://dev.opera.com/articles/css-twenty-years-hakon/

Slide 13

Slide 13 text

@brucel Culture Clash

Slide 14

Slide 14 text

@brucel

Slide 15

Slide 15 text

@brucel John Allsopp

Slide 16

Slide 16 text

@brucel Gandallsopp: “Question after question, of course, is “how do I?”. But beneath questions like “how do I make my pages look the same on every platform” and “how can I make my fonts appear identical on the Macintosh and Windows” is an underlying question – “how do I control the user’s browser?” Indeed, the word control turns up with surprising frequency. Underpinning all this is the belief that designers are controllers.

Slide 17

Slide 17 text

@brucel Håkon One quite specific goal of CSS was to *not* create a programming language. DSSSL was emerging from the SGML world and that scared us. So did the Turing- completeness. In short, you can't tell if a program will terminate or not -- you could end up in endless loops. Therefore we chose a simpler model where you just made declarations. - personal correspondace, Bruce and Håkon Wium Lie

Slide 18

Slide 18 text

@brucel DSSSL DSSSL did, unfortunately, have the fatal flaw which would plague all Scheme like languages: too many parenthesis. Additionally, it was arguably too complete of a spec when it was finally published, making it intimidating to browser developers. The DSSSL spec included over 210 separate styleable properties. The Languages Which Almost Became CSS - Zack Bloom

Slide 19

Slide 19 text

@brucel Y U NO GIVE PARENT SELECTORS? A parent selector would mean that styles would have to be updated as the HTML document loads. Languages like DSSSL were completely out, as they could perform operations on the document itself, which would not be entirely available when the rendering is to begin. https://eager.io/blog/the-languages-which-almost-were-css/

Slide 20

Slide 20 text

@brucel Sir Uncle Timbo’s design principles I chose HTML not to be a programming language because I wanted different programs to do different things with it: present it differently, extract tables of contents, index it, and so on. Sir Uncle Timbo https://www.w3.org/DesignIssues/Principles.html#PLP

Slide 21

Slide 21 text

@brucel Principle of Least Power The choice of language is a common design choice. The low power end of the scale is typically simpler to design, implement and use, but the high power end of the scale has all the attraction of being an open-ended hook into which anything can be placed: a door to uses bounded only by the imagination of the programmer. Sir Uncle Timbo https://www.w3.org/DesignIssues/Principles.html#PLP

Slide 22

Slide 22 text

@brucel

Slide 23

Slide 23 text

@brucel Why does this conundrum resonate so universally with people who have used CSS? CSS is hard because its properties interact, often in unexpected ways. Because when you set one of them, you're never just setting that one thing. That one thing combines and bounces off of and contradicts with a dozen other things, including default things that you never actually set yourself. https://css-tricks.com/css-is-awesome/

Slide 24

Slide 24 text

@brucel Design creator “at the time it just blew my mind that someone thought the default behavior should be to just have the text honk right out of the box, instead of just making the box bigger like my nice, sensible tables had always done.” - Steven Frank https://css-tricks.com/css-is-awesome/#comment-1609829

Slide 25

Slide 25 text

@brucel CSS is bad “The picture fails to capture all the ways in which CSS is bad. You are right. overflow is easy to deal with. Others (specificity, alignment, box sizing models, maintainability of large stylesheets, obscure hidden rules and assumptions, etc.) are numerous and overwhelming.” https://twitter.com/JohnHargrove/status/985630830704852998

Slide 26

Slide 26 text

@brucel Inheritance and Cascade We also added [a] fairly complex mechanism to CSS: inheritance and cascading. Inheritance was/is is fairly well understood, it's used in many other computer languages as well. Cascading, however, was something new and in some ways it competes with inheritance. I can see reasons for not liking it, but to me the benefit of not having to provide complete style sheets makes up for that. Howcome, June 2018, private conversation

Slide 27

Slide 27 text

@brucel CSS *is* awesome! One rule of thumb for mitigating this is, never be more explicit than you need to be... Work with CSS, instead of against it. CSS is weird. It's unlike any other code, and that makes a lot of programmers uncomfortable. But used wisely it can, in fact, be awesome. Brandon Smith https://css-tricks.com/css-is-awesome/

Slide 28

Slide 28 text

@brucel The era of components

Slide 29

Slide 29 text

@brucel

Slide 30

Slide 30 text

@brucel

Slide 31

Slide 31 text

@brucel

Slide 32

Slide 32 text

@brucel

Slide 33

Slide 33 text

@brucel • Something about being convinced by component-based architecture

Slide 34

Slide 34 text

@brucel Because of • Re-usability • Composability • Testability • Shareability

Slide 35

Slide 35 text

@brucel Thanks Cristiano Rastelli (@areaweb)

Slide 36

Slide 36 text

@brucel

Slide 37

Slide 37 text

@brucel Why is CSS for components a PITA? • Everything is global • Order aﬀects cascade • Dependency system - @import • Relies on markup structure (classes, IDs, descendant/ strucural combinators) • Breaks silently

Slide 38

Slide 38 text

@brucel

Slide 39

Slide 39 text

@brucel

Slide 40

Slide 40 text

@brucel • There is a tremendous amount of memorization of unexpected behaviors, rules, names and other idiosyncrasies. It's amazingly powerful, for sure, but it is loaded with cruft https://twitter.com/JohnHargrove/status/985631372764221440

Slide 41

Slide 41 text

@brucel Et tu, Speciﬁcity? As we all (should) probably know by now, specificity is is one of CSS’ most troublesome features, and is an area that soon becomes hard to manage on projects of any reasonable size. Specificity is a trait best avoided, which is why we don’t use IDs in CSS, and we don’t nest selectors unless absolutely necessary. Harry Roberts, October 2014 https://csswizardry.com/2014/10/the-speciﬁcity-graph/

Slide 42

Slide 42 text

@brucel Good old CSS: • IDE support • syntax highlighting • code completions • validations • CSS generators • huge community

Slide 43

Slide 43 text

@brucel

Slide 44

Slide 44 text

@brucel

Slide 45

Slide 45 text

@brucel Designers, designers, designers, designers

Slide 46

Slide 46 text

@brucel What’s your biggest gripe w/ CSS-in-JS? “Always having to remember to camelCase properties then spending 10min pulling hair out when you do forget” “the cryptic domain-specific languages that each of the frameworks do just ever so slightly differently”

Slide 47

Slide 47 text

@brucel https://twitter.com/_philpl/status/935656757942251520 “When I test look and feel in browser, then I copy paste from inspector, only to have to re-write it as a JSON object” “Lack of linting, autocomplete, and css plug-ins for colors/ incrementing/ etc”. “Not a gripe. But a concern: Performance.”

Slide 48

Slide 48 text

@brucel CSS-in-JS costs us! • Loading JS library to handle CSS creation at runtime • Creating / modifying stylesheets at runtime • Server-Side Rendering = CSS × 2

Slide 49

Slide 49 text

@brucel

Slide 50

Slide 50 text

@brucel

Slide 51

Slide 51 text

@brucel Totez!

Slide 52

Slide 52 text

@brucel Totez!

Slide 53

Slide 53 text

@brucel Totez!

Slide 54

Slide 54 text

@brucel

Slide 55

Slide 55 text

@brucel

Slide 56

Slide 56 text

@brucel Ido’s dream • Modular • Dynamic • Performant • CSS capabilities • Tooling • Customisation

Slide 57

Slide 57 text

@brucel Introducing Stylable is a CSS preprocessor for styling components with typed CSS.

Slide 58

Slide 58 text

@brucel

Slide 59

Slide 59 text

@brucel Introducing Mr. Potato Mr Potato is a (React) component.

Slide 60

Slide 60 text

@brucel Sane APIs We use React and Typescript to provide an API for component logic

Slide 61

Slide 61 text

@brucel A bucket of parts The great thing about Mr. Potato is that all of his parts are reusable and customizable

Slide 62

Slide 62 text

@brucel Personalizing a Potato-Bruce Extending a component’s interface

Slide 63

Slide 63 text

@brucel {Mohawk: required;}

Slide 64

Slide 64 text

@brucel

Slide 65

Slide 65 text

@brucel Custom Pseudo-Elements Exposing internal parts all the way down

Slide 66

Slide 66 text

@brucel Custom States Use custom states with parameters

Slide 67

Slide 67 text

@brucel Custom States Use custom states with parameters

Slide 68

Slide 68 text

@brucel CSSWG > “A future version of this specification may allow multiple pseudo-elements per selector." > What's the reason for that? What's the reason it's not currently allowed? Pseudo-elements aren't just filtering which element is selected: they actually create structure in the box tree. So if we have a pseudo element attached to a pseudo-element, it creates a box structure that doesn't currently exist, and pseudo-element box structures can be particularly intricate and complicated to implement since many of them don't fit into the box's tree structure. Therefore we intend to only allow specific combinations--those that are needed for particular use cases.

Slide 69

Slide 69 text

@brucel Latest Spec (30 May 18) https://drafts.csswg.org/selectors-4/#pseudo-element-structure

Slide 70

Slide 70 text

@brucel Mix it all together

Slide 71

Slide 71 text

@brucel

Slide 72

Slide 72 text

@brucel Extra happy in Amsterdam .backdrop:in(amsterdam) ~ .potatoBruce:mood(happy) ::mouth::after { content:”??????” }

Slide 73

Slide 73 text

@brucel

Slide 74

Slide 74 text

@brucel

Slide 75

Slide 75 text

@brucel

Slide 76

Slide 76 text

@brucel Try it out! potatobruce.io stylable.io @stylableio

Slide 77

Slide 77 text

@brucel A type system for CSS • §

Slide 78

Slide 78 text

@brucel A type system for CSS • CSS Superset • Inner parts as Pseudo-Elements • Create custom Pseudo-Classes • Type aware dependencies • IDE & Build support • Optimization - "ruleset shaking"

Slide 79

Slide 79 text

@brucel Status of Stylable • Pseudo- Elements & Classes • Imports • Mixins • VSCode Extension • Integration - React, Webpack, Jest, Node ...

Slide 80

Slide 80 text

@brucel W.I.P. • Declaration Interfaces (allowing/ disallowing overwriting of styles) • MOAR Integrations • Dogfooding and battle-testing • Web Components Compatibility, Houdini (Roadmap)

Slide 81

Slide 81 text

@brucel Number One Priority • 120 million registered users • CSS Grid

Slide 82

Slide 82 text

@brucel James Kyle “pretty sure all the CSS-in-JS libraries just died for me ... CSS could be perfectly static if given the right tools, that's exactly what stylable does. It gives you the tools you need in CSS so that you don't need to do a bunch of dynamic shit in JS. Making it static is a huge performance win” core team member of Yarn, Babel and TC39 https://twitter.com/jamiebuilds/status/929675977067655170

Slide 83

Slide 83 text

@brucel

Slide 84

Slide 84 text

@brucel

Slide 85

Slide 85 text

@brucel

Slide 86

Slide 86 text

@brucel Get ‘em while they’re hot • Stylable docs - Stylable.io • Stylable repo - github.com/wix/stylable

Slide 87

Slide 87 text

@brucel

Slide 88

Slide 88 text

@brucel James Kyle again https://twitter.com/jamiebuilds/status/988839821887107072

Slide 89

Slide 89 text

@brucel

Slide 90

Slide 90 text

@brucel “CSS Blocks implements a strict subset of CSS.” This means we've intentionally restricted some of the features you're allowed to use in a Block file to ensure we can optimize your stylesheets as much as possible! https://github.com/linkedin/css-blocks#its-just-css-mostly

Slide 91

Slide 91 text

@brucel “Stylable is 100% CSS, and then some” “In case I didn’t say it before, I’ll say it again: with Stylable, you get CSS, and every part of CSS. This seems like a “duh” observation, but this is significant if you’ve ever battled with a CSS-in-JS framework over a lost or “hacky” implementation of a basic CSS feature. If this is all you’re looking for, stop reading here and try it out!” Drew Powers https://blog.envylabs.com/stylable-the-good-the-bad-the-weird-f1ee137311a4

Slide 92

Slide 92 text

@brucel

Slide 93

Slide 93 text

@brucel

Slide 94

Slide 94 text

@brucel Goodbye, :shadow and /deep/ These were shadow-piercing selectors that allowed you to target any node in an element’s Shadow DOM. Apart from being terribad for performance, they also required the user of an element to be intimately familiar with some random element’s implementation, which was unlikely and lead to them just breaking the whole element by accident. Monica Dinculescu

Slide 95

Slide 95 text

@brucel Hello, ::part and ::theme Unlike :shadow and /deep/, they don’t allow you to style arbitrary elements inside a shadow tree: they only allow you to style elements that an author has tagged as being eligible for styling This is a lot of effort on the element author, but easy on the theme user. https://meowni.ca/posts/part-theme-explainer/

Slide 96

Slide 96 text

@brucel

Slide 97

Slide 97 text

@brucel

Slide 98

Slide 98 text

@brucel

Slide 99

Slide 99 text

@brucel Houdini: JS-in-your-CSS! Custom Paint: .myThing {background: paint(nice-thing);} Custom Layout: .myMasonry div {display: layout(masonry);} .. and many more! (Ask Greg!)

Slide 100

Slide 100 text

@brucel

Slide 101

Slide 101 text

@brucel b • web comping

Slide 102

Slide 102 text

@brucel

Slide 103

Slide 103 text

@brucel Thank you! Håkon Wium Lie, John Allsopp, @wixeng Stylable team (especially Tom and Lichtash) ! https://pixabay.com/en/potatoes-vegetables-erdfrucht-bio-1585060/ ! https://www.pexels.com/photo/photo-of-eiffel-tower-paris-811715/ ! https://thenounproject.com/icon/38411/ ! https://pixabay.com/en/eiffel-tower-long-exposure-lights-1156146/ No potatoes were harmed during the making of this presentation.