3 ms·

Javascript has superior facilities for scoping, abstraction, and calculation. Sharing a single scoping system between JS, HTML and CSS removes the need for glo

Javascript has superior facilities for scoping, abstraction, and calculation. Sharing a single scoping system between JS, HTML and CSS removes the need for global symbols (classnames or ids) to link the two together. Abstractions in preprocessors are implemented by means of macros, and can lead to large file sizes.

talmand 12y ago
I'm sorry, but there will always be a need for classnames and ids for multiple reasons. A tool like this doesn't remove them from being used, it just partly removes them from the initial code. Proper usage of CSS preprocessors will result in much the same code that this tool will generate. Because in the end they both generate the same CSS.
- boucher 12y ago
  That's not really the case. For one, it's incredibly easy to end up with very bloated CSS files if you use something like less/sass. But more importantly, those tools don't give you actual scoping. Although it's not necessarily the main way the author is suggesting interacting with this library, it can be used as a tool to apply inline styles directly to elements, which gives you total control over the scope of your styles.
  - talmand 12y ago
    If not done properly, anything code-related can result in bloated and inefficient code. I fail to see how introducing Javascript code that requires DOM manipulation is more efficient than a properly built style sheet. Injecting styles inline to elements is an even more inefficient way of doing things, you're likely to cause repaints all over the place during initial rendering. As I said elsewhere, if this were a system done on the back-end (or even in something like Grunt) so that it was part of a compiling process then it would have merit. But from what I'm seeing this appears to run only on the client side which I feel is a bad idea.
- jhpriestley 12y ago
  The site seems to be down, I don't actually know the details about this particular tool. However, you're wrong that classnames and ids are always necessary. You can set the HTML "style" attribute directly when generating the view.
  - talmand 12y ago
    They can be necessary for reasons other than CSS. Trying to do most of them, including CSS, without the usage of classes and ids is just a strange notion. There are several different ways to handle CSS and each has their own pros and cons. But I'm assuming you're talking inline styles on the HTML elements directly? If so, while useful and I do it myself often, it is not optimum. If you're talking about injecting the styles on or before page load for that particular view, of course you can; but that doesn't mean anything different than what I've been saying at all. In the end it is still CSS and if it doesn't done properly in the beginning it will eventually cause problems.
- malandrew 12y ago
  Not completely. With a virtual DOM based solution (which is where things are trending due to performance), the ids and classnames of HTML become far less relevant.
  - talmand 12y ago
    I agree, but that's tomorrow and in the end that only replaces classnames and ids with something else which will serve pretty much the same purpose. You have to have identifiers of some type, today it is classnames and ids; tomorrow it will be something else.

talmand 12y ago

I'm sorry, but there will always be a need for classnames and ids for multiple reasons. A tool like this doesn't remove them from being used, it just partly removes them from the initial code. Proper usage of CSS preprocessors will result in much the same code that this tool will generate. Because in the end they both generate the same CSS.

boucher 12y ago
That's not really the case. For one, it's incredibly easy to end up with very bloated CSS files if you use something like less/sass. But more importantly, those tools don't give you actual scoping. Although it's not necessarily the main way the author is suggesting interacting with this library, it can be used as a tool to apply inline styles directly to elements, which gives you total control over the scope of your styles.
- talmand 12y ago
  If not done properly, anything code-related can result in bloated and inefficient code. I fail to see how introducing Javascript code that requires DOM manipulation is more efficient than a properly built style sheet. Injecting styles inline to elements is an even more inefficient way of doing things, you're likely to cause repaints all over the place during initial rendering. As I said elsewhere, if this were a system done on the back-end (or even in something like Grunt) so that it was part of a compiling process then it would have merit. But from what I'm seeing this appears to run only on the client side which I feel is a bad idea.
jhpriestley 12y ago
The site seems to be down, I don't actually know the details about this particular tool. However, you're wrong that classnames and ids are always necessary. You can set the HTML "style" attribute directly when generating the view.
- talmand 12y ago
  They can be necessary for reasons other than CSS. Trying to do most of them, including CSS, without the usage of classes and ids is just a strange notion. There are several different ways to handle CSS and each has their own pros and cons. But I'm assuming you're talking inline styles on the HTML elements directly? If so, while useful and I do it myself often, it is not optimum. If you're talking about injecting the styles on or before page load for that particular view, of course you can; but that doesn't mean anything different than what I've been saying at all. In the end it is still CSS and if it doesn't done properly in the beginning it will eventually cause problems.
malandrew 12y ago
Not completely. With a virtual DOM based solution (which is where things are trending due to performance), the ids and classnames of HTML become far less relevant.
- talmand 12y ago
  I agree, but that's tomorrow and in the end that only replaces classnames and ids with something else which will serve pretty much the same purpose. You have to have identifiers of some type, today it is classnames and ids; tomorrow it will be something else.