Hacker News Reader

Comment by Fiahil | Hacker News Reader

Despite being a nice experimentation, I don't think there will be any practical use in a real project. CSS preprocessors already allow us to style things with minimal structure and complexity. We already have a large set of tools to do exactly that, and if you want to add JavaScript to your CSS, just don't. It doesn't add value to anything apart from making it slower.

View on HN

One advantage that a JS system could have over a preprocessor is the ability to use real values from the browser; for example you could set things to be equal to page height.

It'd definitely be much slower but that's irrelevant so long as it's still fast enough.

To set an element height to the full viewport height, you can use `height: 100vh`. That unit is available since 2011. Please do your homework.

No need to be pedantic, onion2k's original point that you can use values from the browser is spot-on. If you've ever tried to interact with CSS transitions/animations with JavaScript you'll find rather quickly that doing the entire thing in JS is the only reasonable approach.

Okay, but then, since you're already animating individual elements, what's the benefit over jQuery's $.fn.css?

I didn't mean the viewport. I meant the page eg the full height of the rendered window content including everything outside of the viewport's scroll region.

The two things I find myself persistently wanting to do in CSS, which I've never found a way to do, is:

- how do I make this element the same size as this other element?

- how do I make this element the same size as this piece of unwrapped text?

To be fair, these are both require multipass layout, which (IIRC) CSS is explicitly specced not to do. But it's still necessary for complex layouts. Unfortunately it doesn't look like Descartes can help with this.

...way back when there was a thing called famo.us, which was a pure Javascript layout engine; it claimed to be faster (and more flexible) than traditional HTML and CSS. The company that wrote it went bust, and it seems to have turned into http://famous.org. But I've never heard of anyone using it...

I think this makes perfect sense. JS is a much more powerful language than the normal preprocessors, so it will allow more meaningful abstractions. I can't predict where it will go, but it seems clear to me that there are situations that we currently describe with multiple styles (wrappers and containers and their inner parts), which would make sense to abstract away.

> JS is a much more powerful language than the normal preprocessors

Sure, but do we need it though? You already have media queries, keyframes, mixins, and you can already build meaningful abstraction using SCSS partials, Web Components, and probably a myriad of other tools and technologies.

Why try to reinvent the wheel when you already have the tools, the documentation and the conventions? No need to pollute the landscape of front-end development tech more than it already is.

To me, replacing SCSS or the like with JS would feel like a refactoring/streamlining of my build pipeline. I'd rather stick to one language unless there is a compelling reason to choose another. In this case, it looks like the JS syntax is just as easy to comprehend as LESS or SCSS but with added power, so I think that it would make sense. Of course, I haven't actually used it yet and I know from experience that problems tend to appear that I never thought of, so I am the first to admit that I could be wrong.

>> JS is a much more powerful language than the normal preprocessors

to add to the points in the parent post, i'd add that the word "powerful" is being tossed around w/o much consideration here. GOTO is a "powerful" statement in the sense that it lets you "do more" w/ you programs. otoh, it can make programs a lot harder to read about.

that example is probably hyperbole here. i can see the use of mixing "styles" w/ "code" (this is pretty standard in cljs). however, does a decoupled design team really need more than sass/less -- or another way, do the time-savings from the cases where something else would be useful offset the potential complications of the cases where it could muck with other parts of the process?

tl;dr JS "power" may shoot foot

One thing I appreciated about Clojure's Garden library is you build your CSS in Clojure itself. A Clojure dev can learn Garden in about 5 minutes, then apply the entire power of Clojure as they see fit. I wouldn't mind an equivalent to that in JavaScript. Server side though, so not Descartes.

Managing state in CSS is not that good. I would have to add/remove class names from a DOM element. Styling in JS allows you to manage that in one place keeping the component intact with a few dependencies like external colors, fonts and images.

Reply on news.ycombinator.com