Similar project: Gem.js

[fresheneesz]

I know this isn't the best place for this, but I thought @kof might be interested in taking a look at my take on javascript rendered styling. Like this project, everything is properly isolated by using unique css class names, has mixin inheritance, and modularity. Unlike jss, Gem.js is both a view library and style library, and the styles are built as javascript objects where a full style set cascades (rather than individual style properties). Gem.js can put javascript into styles and create custom css properties and pseudoclasses.

But it sounds like we had very similar goals in creating these libraries, and started building them around the same time, so I figured I'd let you know. You have impressive support for this, congrats.

I found this when I was trying to look for this module: https://github.com/Box9/jss .

[kof]

where a full style set cascades

What does this mean?

You have impressive support for this, congrats.

Thanks!

[kof]

I will close it, but we can continue talking here.

[kof]

It seems like your idea is similar to styled components, to create "styled" primitives? Here is some pseudo code to do the same in jss.

[fresheneesz]

"a full style set cascades... What does this mean?"

It means that if you have a style like:

Style({
  $dropdown: { 
    color: 'green',
    backgroundColor: 'red'
  },
  $innerThing: {
    $dropdown: {
      color: 'orange'
    }
  }
})

dropdowns will be green and red by default, but dropdowns inside an innerThing gem will not have a red background. By defining an inner $dropdown style, it overrides the entire style set (including nested style sets). This is how gem.js allows you to style many different gems the same without allowing style property leaking.

"It seems like your idea is similar to styled components"

Mm, no I'm not creating styled primitives like that actually. Gem.js keeps structure and style strictly separate (more separate than any other view system does since you can separate out javascript). Components in Gem.js can inherit from each other, and so can styles, but they're two very separated aspects (in the interest of separating concerns). You certainly could create pre-styled gems, and can even give them alternate default styles than the global default style, but that's not the goal there.

In my current project, I have one main style that defines the whole tree of styles for the application. Some of those styles are parameterized via functions, some are separated into modules, but it gives a much more easy to manage way to organize your styles hierarchically in a way that matches the structure of your application (and therefore also the DOM).

[kof]

It sounds like what we do in jss-nested plugin with slightly different syntax. Do you have inheritance isolation like jss-isolate?

[kof]

I think you got lots of good ideas there, but you are going a very opinionated path about everything and will have problem to make others use it.

[fresheneesz]

"Do you have inheritance isolation like jss-isolate?"

Yes indeed. Every gem gets the default class which overrides inheritable properties.

"you are going a very opinionated path"

I'm curious what you mean about this, and what I could do about that. I certainly don't want to make it hard for people to use it.

[kof]

Well, you already go against react + cssinjs. React is a leader, it will be very hard (or almost impoosbile) to convince people to use your library instead.

[fresheneesz]

Yeah, if I could separate the style part of it so that it works on raw dom nodes, it would be much more accessible to people using any view library. That might be doable actually.

[kof]

Or you just take this library and contribute to it with your ideas)))

[fresheneesz]

I find it difficult to understand how I would extend this library to do what I want to do. I'd have to spend a lot of time thinking about this - time I don't have at the moment. Maybe I'll revisit this in the future.