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

21–30 of 51 posts

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

#21

Post by bryanrasmussen »

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.

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 framework than those developers back in the day that just knew jQuery.

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

#22

Post by rualca »

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…

> 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 besides the point and even it's regular use. In fact, I worked in projects where Sass was introduced just for it's support for nesting and partials alone.

Mixing content and presentation in scripts misses any of the lessons from the last couple of decades. It feels like yet another example of the cargo cult of javascript, where people mindlessly argue that dragging everything into a script solves anything at all.

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

#23

Post by christophilus »

There are already quite a few alternatives in the comments, but I’ll just add that I have really come around to the Tailwind way of doing this. On my current project, I haven’t had to write much CSS at all other than a handful of animations, and it all looks consistent and custom. It’s a breath of fresh air.

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

#24

Post by mStreamTeam »

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?

There's nothing wrong with runtime CSS. Frontend devs just like to come up with elaborate solutions to problems that don't exist

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

#25

Post by jokethrowaway »

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 see it all the time.

Tons of developers coming out of bootcamps (and even a few designers with no coding experience) who know how to string together a few react components but have problems with basic JS.

It's not necessarily bad, it's just higher level coding. What's bad is when these people get hired as engineers.

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

#26

Post by simonmales »

mStreamTeam wrote: post #24
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?

There's nothing wrong with runtime CSS. Frontend devs just like to come up with elaborate solutions to problems that don't exist

From my understanding of frontend performance, JS parsing is blocking.

So reducing the JS "load" is a performance win on the client.

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

#27

Post by austincheney »

bryanrasmussen wrote: post #21
ljm wrote: post #20

Earlier quoted context omitted.

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.

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 Chrome), are about 460x slow than the old DOM methods. All the jQuery approaches would be slowness that multiplies on top of the already slow query selectors. In Firefox query selectors are about 10,000x to 250,000x slower than the standard DOM methods.

From a standards perspective there is no incentive to go down that path as it cripples the interface it describes.

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

#28

Post by 5350-uiop-1130 »

why is there such a prevalence of mawkish phraseology in the javascript community...

i was reading the landing page for a js library and it said something like "battery-pack included", makes me feel kind sick....or maybe i'm just a grumpy sod

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

#30

Post by iaml »

5350-uiop-1130 wrote: post #28

why is there such a prevalence of mawkish phraseology in the javascript community... i was reading the landing page for a js library and it said something like "battery-pack included", makes me feel kind sick....or maybe i'm just a grumpy sod

"Batteries included" was invented by rails folks IIRC.
Post reply on HN