6 ms·

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 m

by Fiahil 11y ago

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.

onion2k 11y ago
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.
- juandazapata 11y ago
  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.
  - prezjordan 11y ago
    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.
    - majewsky 11y ago
      Okay, but then, since you're already animating individual elements, what's the benefit over jQuery's $.fn.css?
  - onion2k 11y ago
    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.
- david-given 11y ago
  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 http://famous.org. But I've never heard of anyone using it...
kristiandupont 11y ago
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.
- Fiahil 11y ago
  > 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.
  - kristiandupont 11y ago
    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.
  - auvrw 11y ago
    >> 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
seivan 11y ago
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.

by Fiahil 11y ago

onion2k 11y ago

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.

juandazapata 11y ago
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.
- prezjordan 11y ago
  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.
  - majewsky 11y ago
    Okay, but then, since you're already animating individual elements, what's the benefit over jQuery's $.fn.css?
- onion2k 11y ago
  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.
david-given 11y ago
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 http://famous.org. But I've never heard of anyone using it...

kristiandupont 11y ago

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.

Fiahil 11y ago
> 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.
- kristiandupont 11y ago
  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.
- auvrw 11y ago
  >> 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

seivan 11y ago

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.