Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Compiled, buildtime atomic CSS in JavaScript and all your favorite APIs

compiledcssinjs.com

Post reply on HN
Print view View original

31–40 of 51 posts

Re: Show HN: Compiled, buildtime atomic CSS in JavaScript and all your favorite APIs

#31

Post by mattlondon »

rualca wrote: post #22
jitl wrote: post #13

Earlier quoted context omitted.

Well, in the long run we’ve learned that maintaining a large and complex UI’s CSS by hand is very tedious and error-prone. A miss configured style that, for example, makes the Airbnb “Book It” unreadable for some % of the population can lose millions of dollars, but never throw a stack trace. So, engineers working on UI toolkits often reach for CSS code generation to ease maintenance. At first it was all PHP template…

> The next step is to move all the UI definition into a single place, i using a single language that abstracts the underlying HTML/CSS/JS files & semantics. That sounds like a gigantic step backwards, and one which does not follow the example you've mentioned. The point of Sass was to introduce backwards-incompatible changes to CSS which adds nice human-readable syntactic sugar to CSS. Being turing-complete is beside…

> Mixing content and presentation in scripts misses any of the lessons from the last couple of decades.

Agreed - although this is not a JavaScript thing, but a react thing I think (maybe also Vue? No idea about that). E.g. Angular still has CSS (actually SASS) and HTML in separate dedicated files, and then a another separate file that contains the JavaScript (actually typescript) for the logic itself.

I do not see the benefit at all of putting all these things in one single file, apart from trivial tiny simple things (angular allows you to create single-file components for instance) or for making "To-Do with React" type tutorials look easy. Once you get more than 100-200 lines of code + html + CSS then it is time to separate the files.

Re: Show HN: Compiled, buildtime atomic CSS in JavaScript and all your favorite APIs

#33

Post by lucideer »

Traubenfuchs wrote: post #32

Could someone please explain the following line to me? export const Button = styled.button``; Why is there a string right after the field "button" of the object "styled"? How is this valid JS? What does it do?

I don't know why that space is there, it could be accidental or a deliberate stylistic quirk of the author, but it seems harmless (if not idiomatic).

> How is this valid JS? What does it do?

I'm curious if Python (or a similar whitespace-sensitive syntax) is your first/familiar programming language.

The extra whitespace here does nothing.

The semicolon in JS is an (optional) expression separator, similar to in Bash/Shell. It can occur at the end of a line or at the beginning of a line, or in between lines. Or in between two expressions on a single line. Any whitespace chars before or after it are irrelevant/ignored.

Re: Show HN: Compiled, buildtime atomic CSS in JavaScript and all your favorite APIs

#34

Post by commotionfever »

Traubenfuchs wrote: post #32

Could someone please explain the following line to me? export const Button = styled.button``; Why is there a string right after the field "button" of the object "styled"? How is this valid JS? What does it do?

checkout javascript "template literal tags"

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Show HN: Compiled, buildtime atomic CSS in JavaScript and all your favorite APIs

#36

Post by jokethrowaway »

jitl wrote: post #13
swiley wrote: post #2

So you took something written in a regular grammar and made it into the same thing except with a very complex context free grammar with support for recursion? I hate to be a grumpy puss but using this sounds like a step backwards.

Well, in the long run we’ve learned that maintaining a large and complex UI’s CSS by hand is very tedious and error-prone. A miss configured style that, for example, makes the Airbnb “Book It” unreadable for some % of the population can lose millions of dollars, but never throw a stack trace. So, engineers working on UI toolkits often reach for CSS code generation to ease maintenance. At first it was all PHP template…

Then you go back to HTML with attributes to control style, which is where we were before CSS.

It's good to have a level of separation between style and content. The problem with HTML and CSS is that often times you need to change your HTML to change the style of your application.

This is because HTML+CSS was meant to be for documents. It took ages to evolve into what we have today and it still has a lot of baggage. Designing apps with it is a hack which became mainstream.

If we want to improve the situation, I think we need a couple of standards to define application content and application style which can be compiled to HTML + CSS (as browsers are probably going to stay around for a bit longer).

Component based libraries (like react) are well placed to do something like this and it would help developers faced with this uneven separation of style, content and markup.

Re: Show HN: Compiled, buildtime atomic CSS in JavaScript and all your favorite APIs

#37

Post by jitl »

mattlondon wrote: post #31
rualca wrote: post #22

Earlier quoted context omitted.

> The next step is to move all the UI definition into a single place, i using a single language that abstracts the underlying HTML/CSS/JS files & semantics. That sounds like a gigantic step backwards, and one which does not follow the example you've mentioned. The point of Sass was to introduce backwards-incompatible changes to CSS which adds nice human-readable syntactic sugar to CSS. Being turing-complete is beside…

> Mixing content and presentation in scripts misses any of the lessons from the last couple of decades. Agreed - although this is not a JavaScript thing, but a react thing I think (maybe also Vue? No idea about that). E.g. Angular still has CSS (actually SASS) and HTML in separate dedicated files, and then a another separate file that contains the JavaScript (actually typescript) for the logic itself. I do not see th…

I would rather have my files be Page.component, Header.component, Details.component, Article.component than have my three files be Page.html, Page.css, Page.js.

What is the benefit of separating code by file type? If your reasoning is to reduce coupling, I think this is false simplification - again, in complex applications with lots of interaction, there is no escaping the coupling of DOM nodes, JS logic, and styles. Any feature changes change is going to need to modify all three. Maybe for a mostly read-only site de-coupling these things makes sense, and you can achieve your goals with something like Bootstrap, where you compose a bunch of reusable CSS classes. But for the majority of work I’ve done over the last 8 years, that decoupling model doesn’t work. It’s an even harder nest of snakes when you multiply 3 screen sizes x 2 input methods x N pages where CSS could be used - again for something simple, it’s fine to just collapse columns on mobile (the typical CSS column-css-6 style) but frequently you want this stuff to be much more responsive to user device and input than decoupled styles allows.

Re: Show HN: Compiled, buildtime atomic CSS in JavaScript and all your favorite APIs

#38

Post by jitl »

pestatije wrote: post #14

What was wrong again with runtime CSS? By the smell of it seems to be performance, so: can somebody point to performance comparisons, or give a brief of the advantages?

It’s all about time to interactive.

For a big complex app (eg, https://www.notion.so which I work on), a significant fraction of JS code size is spent describing styles. There can also be JS cycles spent doing color math like lighten, darken, hue shifting on base colors, etc. With runtime CSS-in-JS, all of that style JS code must be parsed and executed by the JS runtime on every page load by every user. That’s a lot of CPU time and user wait time multiplied out.

Zero-runtime improves page load performance by moving this extra code from the JS vm to static CSS files. The majority of style computation happens at build time. The CSS can then be downloaded and parsed in parallel with the JS (woo threads?). The separation may improve caching compared to all-JS solution as well, depending on how granular the CSS and JS output files are.

Re: Show HN: Compiled, buildtime atomic CSS in JavaScript and all your favorite APIs

#39

Post by jitl »

austinjp wrote: post #19

Personally I'm a fan of cxs [0] which is (or purports to be) atomic among other strengths. From the readme: - 0.7 KB (gzipped) - Zero dependencies - High performance ("fast af") - Deduplicates repeated styles - Dead-code elimination - Media queries and pseudoclasses supported Works with any framework or with none, apparently, although I've only used it with Preact. Supports themes. Everything I need and nothing I don…

I think csx is probably the best choice amongst the compute-styles-at-runtime CSS-in-JS libraries. The brutal simplicity has a lot to offer. For most projects csx is perfectly fine. However it can’t beat a more complex zero-runtime precompiled styles system on paper — but it’s an optimization tradeoff you could choose if you need it in the future.

Re: Show HN: Compiled, buildtime atomic CSS in JavaScript and all your favorite APIs

#40

Post by jitl »

jokethrowaway wrote: post #36
jitl wrote: post #13

Earlier quoted context omitted.

Well, in the long run we’ve learned that maintaining a large and complex UI’s CSS by hand is very tedious and error-prone. A miss configured style that, for example, makes the Airbnb “Book It” unreadable for some % of the population can lose millions of dollars, but never throw a stack trace. So, engineers working on UI toolkits often reach for CSS code generation to ease maintenance. At first it was all PHP template…

Then you go back to HTML with attributes to control style, which is where we were before CSS. It's good to have a level of separation between style and content. The problem with HTML and CSS is that often times you need to change your HTML to change the style of your application. This is because HTML+CSS was meant to be for documents. It took ages to evolve into what we have today and it still has a lot of baggage. D…

I view the current Cambrian explosion of CSS-in-JS approaches as a distributed search for the “new standard”. Better to have 1000s of developers working on the problem then have 6 people on a committee make another bad, short-sited standard that becomes “cruft” in 4 years.

If you views React’s JSX as the “content” part of content/style break, then we’re not too far off. It compiles down to HTML :)

Post reply on HN