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

41–50 of 51 posts

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

#41

Post by rualca »

jitl wrote: post #37
mattlondon wrote: post #31

Earlier quoted context omitted.

> 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.…

> 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.

...except that Page.css at most only adds minor tweaks that cascade over the site's styling, and arguably already should be a part of the site's main styling definitions.

> What is the benefit of separating code by file type?

Separation of concerns. This lesson was learned the hard way. Must we keep on relearning it?

> 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.

This assertion is quite wrong and misguided. Styling is a property of a site's visual identity. It is not a property of a component or a specific interaction state. Any well-designed site follows a uniform visual identity which spans over all aspects pertaining to user interactions. Moreover, UI components are also uniform and reused. There is no excuse.

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

#42

Post by robertoandred »

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…

React doesn't require mixing styles and content. You can use regular CSS files just fine.

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

#43

Post by RobertKerans »

ljm wrote: post #20
tobr wrote: post #18

Yet another case of documentation saying “JS” when they mean “React, specifically”. Every single example I can see here uses React, but if this deserves the CSS-in-JS moniker, please give at least one example of usage with vanilla JS. It’s like peak jQuery all over again.

We're probably at that point again where a developer 'knows' React but will completely flounder when faced with anything outside of that ecosystem. Same with jQuery, same with Rails and Ruby.

I've started seeing this quite a lot recently when working with beginners. Worst one recently was someone who had extreme difficulty understanding how to make different web pages using only HTML, but much more mild versions of this have been cropping up in frequently for me over the last year.

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

#44

Post by ratww »

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

If you're using React or Vue, chances are your content is coming from JSON in fetch requests, etc, not from the HTML/JSX in your components. In those cases HTML/JSX is the presentation. The content/presentation separation still exists.

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

#45

Post by pestatije »

jitl wrote: post #38
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…

Oh!, now I get it: CSS static was not good, so welcome JS generated CSS.

But that was not good either, so welcome buildtime JS generated CSS.

Brilliant!

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

#46

Post by samb1729 »

lucideer wrote: post #33
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/S…

It is not clear how this response is meant to answer the question in the post you replied to; there was no mention of whitespace.

Their question was:

>Why is there a string right after the field "button" of the object "styled"?

which unambiguously refers to the double backtick characters between "styled.button" and the semicolon in this expression:

> export const Button = styled.button``;

That is, in JavaScript, an empty string. There is not whitespace and Python has nothing at all to do with the question. Similarly, an explanation of what a semicolon does in JavaScript does not answer the question.

I also can't answer the question for them as I haven't kept up with newer JavaScript standards, but I thought it important that you realise you misunderstood something here.

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

#47

Post by bryanrasmussen »

austincheney wrote: post #27
bryanrasmussen wrote: post #21

Earlier quoted context omitted.

Since JavaScript evolved to incorporate many of the APIs that jQuery pioneered at some point knowing only jQuery was not such a problem. But even before this evolution much of jQuery was just sugar to make cross-browser problems manageable. I am not actually aware, I think, of any developer that just knows React but if they exist I suspect they would have an even harder time of it when deprived of their favored frame…

Query selectors likely came from jQuery's Sizzle engine, but most of the jQuery APIs, all methods, were never adopted. The best I can think of that did get adopted is closest which uses a query selector to find a matching ancestor node. The reason why most of the jQuery approach is not adopted is because it is so incredibly slow. First you have to consider that query selectors, at their best performance (Google Chrom…

I was pretty much thinking just of query selectors as I think that would be the most problematic thing for a jQuery trained developer to do without.

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

#48

Post by jitl »

pestatije wrote: post #45
jitl wrote: post #38

Earlier quoted context omitted.

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…

Oh!, now I get it: CSS static was not good, so welcome JS generated CSS. But that was not good either, so welcome buildtime JS generated CSS. Brilliant!

Yes, best of both worlds

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

#49

Post by lucideer »

samb1729 wrote: post #46
lucideer wrote: post #33

Earlier quoted context omitted.

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/S…

It is not clear how this response is meant to answer the question in the post you replied to; there was no mention of whitespace. Their question was: >Why is there a string right after the field "button" of the object "styled"? which unambiguously refers to the double backtick characters between "styled.button" and the semicolon in this expression: > export const Button = styled.button``; That is, in JavaScript, an e…

Possibly a HN formatting issue (or the commenter typed wrong first time and later edited) but the backticks weren't showing up previously.

Sorry @Traubenfuchs for the misguided explanation.

As another commenter posted, this is a template tag. Technically equivalent to doing something like styled.button('') but the template tag syntax would be used for consistency with other calls in the code (where parameterised template strings would be passed to the button/element/component method)

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

#50

Post by Traubenfuchs »

commotionfever wrote: post #34
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...

Thanks! So it's a special way to call a function, with the functions arguments being the parts of the given template literal string as split by the template literals and the template literal values themselves?

JS syntactic sugar complexity is getting out of hand.

Post reply on HN