Hacker News Reader

Comment by JelteF | Hacker News Reader

Why would you ever use this instead of an easier preprocessor like sass or less?

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.

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.

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.

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.

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.

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.

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.

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.

I suspect if you're OK at CSS and great at JS, this would have some appeal. Conversely, if you're great with CSS and OK at JS, this will not.

It doesn't help that in most of the examples the Javascript implementation is more complex than the css implementation.

If you are bad at CSS and good at JS then this tool will not really help you. In the end it generates CSS, which you have to know to some degree to be able to create the JS version of it.

I agree on the complexity issue with the examples, I don't see how the 30% savings claim would hold up.

saving come from 1. code reuse. less/stylus will generate everything dozens of times 2. vendor prefixes are added effectively at runtime

CSS allows for code reuse, it always has. It's called cascading and classes.

Preprocessors will generate bloated CSS if not coded properly, same as it's possible to hand-code bloated CSS.

There are libraries that generate vendor prefixes at run time. If prefixes are really a bother (they're not as much anymore) then preprocessors and other compiling tools have solutions for that as well. Which will be more efficient for the browser.

1. Stop assuming I am stupid.

2. I know code reuse technics in css, they are mentioned in the presentation. Cascades do not work for component based development. Adding multiple classes to an element leads to awkward code and also will lead to namespace conflicts if you don't name everything very specifically.

3. Vendor prefixes are there and will be used for new features too. They will not go away. Precompilers can't avoid generating all prefixed variants.

I don't know, doesn't make much sense.

Reply on news.ycombinator.com