Negative.

You already failed at your first 2 sentences.

JSS is a better abstraction over CSS

Better how? Why you even need an abstraction in CSS ,omg?

It uses JavaScript as a language to describe styles in a declarative and maintainable way.

This is how CSS already works?

So, in one sentence regarding CSS what main, real world problem JSS solves?

Please, stop making another pseudo-temporary-solution. If you consider there should be something changed in the Web Standards, please participate in discussions, working groups, contribute.

CSS, of course, is not ideal, however, overall I don't have big problems with it. I have own simple, maintainable CSS architecture based on ITCSS and BEM principles.

What I can consider, on the other hand, is the idea of CSS Houdini working group and upcoming spec.

First off - I love to see people playing with CSS. For now the best way to play around with new concepts and ideas for CSS is by using JavaScript, so I'm happy any time anybody releases some kind of CSS-in-JS or JS-in-CSS solution. We need more of this!

Another thing I like about this project is the name: JSS 😍 Back when we were starting EQCSS the original name we gave to our alpha version was JSS

<script type="text/jss">

@element "#widget" and (min-width: 550px){
  #widget {
    background: red;
  }
  #widget a {
    background: yellow;
  }
}

</script>

Eventually we settled on the name EQCSS for 'Element Query CSS', and because it sounded like 'excess'.

What do I think about JSS

When I use CSS and find it lacking, it's usually in the areas of finding ways to apply styles to elements with better responsive conditions, finding new ways to select elements, and using element-based units to work with layout. I'm not having issues getting my CSS written, sorted, or named. I think generally CSS is very fit for purpose and when I think of ways to improve it I always come back to minor ways to extend CSS, instead of partial (or total) replacements. But my mind is very open. I'm curious about using 100% totally custom script types to style layouts, it's just hard to make something better than CSS. I'll be trying that some time this year (wish me luck!)

It looks like the CSS-in-JS approach of JSS helps with style scoping, it should be very flexible as JavaScript should make it simple to use anything to help make responsive. It should be possible to make responsive styles that change based on the hour of the day, or day of the week. All that power and flexibility is cool and helpful, and CSS and JS do seem like a match made in heaven.

I started researching solutions for element queries and style scoping a few years ago and I was pursuing a CSS-in-JS approach but over time I ended up with the exact opposite: JS-in-CSS. What started out as our JSS proof of concept eventually turned into a fully featured CSS-like syntax for a way that JavaScript can apply styles in all kinds of novel situations that CSS is powerless to reach without a little help from JavaScript.

Another revelation as I've journeyed along that road is that there's a big divide between 'styles that can be rendered in advance' and 'styles that must be interpreted in realtime'. If you're trying to limit what you can to with a CSS-in-JS approach to just stuff that can be rendered in advance server side, you're missing out on some really wild possibilities!

The kinds of things you can do with EQCSS aren't possible to do in vanilla CSS, and definitely can't be pre-rendered in advance (like server-side). I've been wondering if it would be possible to 'compile' EQCSS syntax to 100% JavaScript that could run without being interpreted by a plugin to accomplish equivalent styling behaviour. My compiling experiment is on Github at tomhodgins/eqcss-compiler. Currently it only supports a fraction of what EQCSS supports, but I'm hoping to work more on it to discover if this sort of tool could perform better than interpreting the EQCSS syntax in realtime by the browser. (I'm not convinced it will out-perform realtime interpretation though, so all this could be for no benefit).

If you were going to do any kind of server-side rendering I would hope you'd explore something similar - taking a CSS-in-JS approach and outputting the JS you'd need to accomplish the same thing on the page, getting the full power of CSS with the added smarts of JavaScript - the best of both!

Other Thoughts

CSS was not designed for components and large sites.

I feel like you're not giving enough credit here, CSS was designed for large sites. I hear this fallacy be repeated almost daily but there's no evidence for it. CSS can be frustrating to figure out at moments, but that doesn't mean it wasn't designed with very large sites in mind.

Even it's full understanding doesn't allow you to scale it in team and code size in a robust way. Its global nature with documents in mind works just for relatively small projects.

There is so much flexibility built into CSS that we hardly make use of. With HTML5 you can create custom attributes, and CSS can make use of these attributes and their values to select things. You don't have to just set classes, different components in your site can each have their own 'namespace' for values by using as many custom attributes as you want to make up. The only limit is your imagination!

I will publish an article soon which explains the difference between scoping and isolation. They are very different terms.

I would be really interested in reading anything relating to style scoping in CSS. Here's an explanation of how I use style scoping, and the section in the element queries spec that covers style scoping so you can see where I'm coming from and how I put it to use :D

Thanks so much for sharing JSS, and hope you can make some really sweet demos with this!

Thanks @sandeep for the invite! Writing CSS in javascript is becoming more and more popular. It makes it easier to bypass CSS specificity wars, autoprefixing, dead code elimination etc.. And that's great! However, most implementations seem far from ideal. Writing CSS in Javascript should be as easy as writing CSS! But projects like JSS have some cons:

• Some javascript properties require 'quoting' (like '&:hover').
• It's difficult to read.
• No native syntax highlighting for editors.
• Everything needs to be camelCase.

I personally like how Vue approached these problems. They created a 'vue-loader' Webpack loader that simply scans for <style> tags within a Vue component file. It also accepts a 'scoped' attribute for scoped selectors. It can also use different CSS preprocessors by using the 'lang' attribute (for SASS/ Stylus/ LESS/ whatever you want to use). And in the end you can just write CSS like you're used to.

Instead of writing this:

button: {
  fontSize: 12,
  '&:hover': {
    background: 'blue'
  }
},

You can write this (when using a SCSS loader):

<style lang="scss" scoped>
button {
  font-size: 12px;
  &:hover {
    background: blue;
  }
}
</style>

No need to quote properties, using camelCase for everything or create a new Syntax highlighting plugin that understands JSS. It also makes the code more readable, thus making it easier to maintain.

TLDR; JSS does a great job at solving some problems with CSS, but the implementation can be more elegant.

My opinion might be kind of unstable. For my projects in the company I would choose write CSS alone or something like SASS or LESS. But for my personal projects I use inline styles with ClojureScript merge functions as well as inlined <style> elements to handle media queries and pseudo classes.

The problem inline styles does not fix is like handling media queries and pseudo classes. I see JSS showed a really interesting way to solve the problem and I would say: awesome!

Nowadays people treat the browser APIs like a virtual machine. Everything is compiled and we just need better compilers. Before JSS we use inline styles to write properties to Element.style directly. The drawback is it's only values. If we have 100 elements sharing the same styles, we have to write the styles for 100 times in all elements. Because we don't have variables like in JavaScript. However with the help of JSS, now we have basic support for variables. It's really interesting now JavaScript is compiled to JavaScript plus CSS!

I guess we can have more things like that in the future by treating the browser like a VM.

so let me recap :D because I love it ... "you can write declarative" .... CSS by nature is declarative and maintainable. If you actually understand what you're doing.

But I know that a lot of devs actually don't know what they are doing and create super complex structures coupled with almost everything just to add a new button color :D ....

that's why I'm willing to make this trade-off because I understand that some don't like to think about CSS when they work :) and I don't get upset reading 20times !imporant

to me it's useless overhead :) but if you don't really understand CSS it's a nice tool to decrease the complexity hence the sideffects of CSS ....