3 ms·

> 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

by 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
city41 11y ago
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.

by Fiahil 11y ago

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

city41 11y ago

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.