Comparison with jss?
klarezz opened this issue · comments
Is it possible to have a comparison with jsstyles/jss? It is being adopted for elementalUI (elementalui/elemental#53). It could really help for decision making.
+1 Why not JSS?
I think there are a lot of comparisons out there that exist, but looking at the READMEs and recalling from memory, here's the points (from the context of Free Style, since you made the issue here):
- Simple usage - JSS has 5 plugins I see in the README that will work in Free Style without plugins
- Small source size - even given that JSS defers to a bunch of plugins, the core size is surprisingly huge (for context, Free Style is under 500 lines total - even including the type system overhead - compared to https://github.com/jsstyles/jss/tree/master/src)
- Singular styles - I disagree with large object "stylesheet" approach and opted in favor of registering one style at a time, the latter works better with existing tools - like linters and tree shaking to remove unused styles (if you want the same thing in Free Style, just make an object yourself)
- Built in rule minification - Free Style does stylesheet de-duping by default
- Styles are hashed - it looks like JSS uses manual namespaces, which means styles can be output inconsistently whereas Free Style guarantees style names everywhere (server/client doesn't matter)
- Simple - to be honest, for what JSS does, it's heavy and confusing and tries to enable a lot of stuff that just isn't (or shouldn't be) used realistically
Does that seem like a reasonable comparison?
To be honest, I don't think either are adequate for a third-party UI to use yet, though Free Style is closer since it's not opinionated by the "attach" step (not to mention much lighter). Personally, it'll take some time (which I have no yet invested in) to solve a UI libraries style re-use across the full ecosystem. But that's a separate discussion that I'm welcome to have, just open a separate issue 😄
Edit: Some points were written from JSS's context.
thank you @blakeembrey for the answer. There is indeed at least two comparisons: one in css-in-js and another in radium. I wanted your personal opinion about the subject and maybe a deeper analysis (server side rendering, scalability, css extraction, dynamic properties, composability...) 😄
As always, I guess that it is better to test both then make an opinion... of course a further analysis is always very welcome 😄
You listed "Singular styles" and said "it'll take some time (which I have no yet invested in) to solve a UI libraries style re-use across the full ecosystem". Does this mean that new and upcoming CSS features like CSS-Grid will not work? With CSS-Grid we have multiple rulers working together across a app and all it's regions, not just singular items.
Maybe JSS is in a much better position to embrace the future, also it eliminates CSS files and uses JSON, which I think in a huge plus. Also JSS is a more general API, so it is possible to use it for more than just CSS. You can use it for rules of all types if you like, like rules for a Canvas2D renderer.
server side rendering
Hashed styles will work the same, so this is fine. Theoretically across other languages too, though I have not written a spec for that (I will if people are interested in this).
scalability
Subjective, I feel CSS-in-JS is more scalable for web applications regardless of the approach taken.
css extraction
CSS-in-JS fundamentally suffers from this, and for web applications I don't actually see this as a concern. As long as you can write to CSS, which both can, then it's ok.
dynamic properties
Can you elaborate?
composability
Comes down to JS and discussion around third-party integration which no one has really solved yet.
You listed "Singular styles" and said "it'll take some time (which I have no yet invested in) to solve a UI libraries style re-use across the full ecosystem". Does this mean that new and upcoming CSS features like CSS-Grid will not work? With CSS-Grid we have multiple rulers working together across a app and all it's regions, not just singular items.
To be honest, I don't know how you got to this assumption and those two statements have no correlation with each other either. Singular styles, if you look into the library and my statement above, is referring to registering a style on at a time. JSS uses an object with properties that can not seamlessly work with existing helpful tools (like tree shaking or linting dead code). Both libraries output to CSS, so this works fine.
Maybe JSS is in a much better position to embrace the future, also it eliminates CSS files and uses JSON, which I think in a huge plus. Also JSS is a more general API, so it is possible to use it for more than just CSS.
Please provide references with statements like "JSS is in a much better position to embrace the future". I don't see how that's possibly true, but I'll give you the benefit of the doubt and assume I'm missing something. Did you look at free-style or did you visit to post popularity +1s? Free Style does not use CSS files (what?), and it loads from JavaScript objects the same as JSS. "Also JSS is a more general API" - this sounds particularly subjective and untrue, the API for Free Style is actually much simpler than JSS.
You can use it for rules of all types if you like, like rules for a Canvas2D renderer.
Really? That sounds like a terrible idea, to be honest. Just because you can, it doesn't mean you should.
Edit: Removed propaganda, it's a very harsh word. I think "popularity +1" might better describe how it felt, sorry 😄
Just some points about jss:
- minified, not gzipped core size is 12KB right now, plugins are very small, maybe 1kb all together.
- yes its not tiny, but it offers a lot: scalable plugins architecture, swappable rendering backends, proper abstraction inside (let me know if it can be better).
- I am really trying to make the api as non opinionated as possible, feel free to create an issue if you have a use case which is not supported or not documented.
- I could use some help, there is a lot of things to do. Right now I am trying to get a better documentation.
- integration into elemental is an ongoing process, due to my limited time, but it will happen, I am on it.
- consider jss something like static stylesheets, things that need to be changed dynamically for e.g. animations should be done inline.
- serverside rendering is possible, there is just no good documentation/example.
- basically everything in jss ends up with generated classes, one can build components with class names passed via props, so css can be written using anything.
@kof Thanks for visiting. I'd prefer not to have some big debate and I see you're pushing JSS very hard (at least, compared to what I've done).
Right, I looked into the size and saw it's actually not that much bigger - I was just surprised initially as the plugins are omitted and since to CSS is actually a fairly trivial operation. I can maybe look at why, but it's not my focus right now.
On the non-opinionated API, I don't have any qualms with it - but 99% of my use-cases don't need the things there. For Free Style, it's even extra that there's an inject method which is opinionated (E.g. requires the DOM). For JSS there's retrieving rules, props, rule conditions (media, name) and even plugins seem a bit redundant. To me, it shouldn't feel like a framework, but something I can just use if it's what I need. Free Style has two public methods, registerStyle and registerRule, which covers all of operations I need (even registerRule is more than needed).
I agree with doing things inline, and I also have bad documentation on server-side rendering (though, also, it "just works" since styles are hashed anyway). Also, free-style is generated classes too and works exactly the same. There's a lot of overlap in the two approaches, I just feel like (biased, of course) I thought out how Free Style would be used more.
Also, there might be a better medium for posting JSS summaries than in here. Feel free to continue the discussion if there's more questions about how I approached CSS-in-JS, I think it's truly interesting. For now, I'm going to close the issue since I think I answered the original question.
Also, looking at the types of issues in JSS, it seems our approaches are different. You seem to be trying to build an entire framework around CSS, whereas Free Style is intended to stay as it is now - a small, un-opinionated library. If you want more, there's probably someone who has already done what you want in JavaScript and I'd like to promote people building other libraries for needs they have (like vendor prefixing, this is something I wish had been solved one time in a library cleanly - not 100 times).
Edit: You can always build opinion on top of this, such as https://github.com/blakeembrey/react-free-style, which is one of the first things I wrote (React being the reason I was finally able to do CSS-in-JS fluently).
I'm glad we are learning more about CSS-in-JS. Just wanted to clarify on the following:
"You can use it for rules of all types if you like, like rules for a Canvas2D renderer.
Really? That sounds like a terrible idea, to be honest. Just because you can, it doesn't mean you should."
From my point of view it's great that there is HTML + CSS, this bodes well for the outer surface of my app, except I use HyperScript-in-JS instead of HTML where ever possible. However, there is also the inner content of my app, made up of layered Canvas2D elements.
Because it is an app with variable rendering options I came up with an idea I borrowed from CSS, to have rules for Canvas2D rendering. So for my content I have my own data structure defined as JSON instead of HTML (my own datagraph/custom DOM) and then CSS-like rules for rendering that to a Canvas2D instead of other DOM elements.
To make this happen I think JSStyles is therefore more suitable for my all around use case, where I would be needing CSS rules for the outer surface and CSS-like rules for the inner content.
Hope that clarifies that bit for you :-)
Right, but HyperScript is a way to render to the DOM - just like React, etc. Can you share the Canvas solution that's using CSS-in-JS? Just because I think it's a terrible idea, doesn't mean I'm right - I'm definitely interested in being wrong and learning more about what you are doing. Maybe there is a better way to do things there, and you've obviously done more Canvas rendering than I have.
I'm still confused by this JSON idea you have though. All CSS-in-JS solution use JSON, but that doesn't matter. Are you saying that JSS supports outputting into Canvas or you've built a compatible solution? If it's the latter, that makes way more sense and it's a less terrible idea to me 😝
JSS does not support my CSS-like rules for rendering to a Canvas element, that is my idea and they may protest too but I hope to make it work, as long as JSS does not try a process everything to to CSS automagically. So essentially, I just like the mechanizm by which JSS works and that the format is JSON. My Canvas targeted rules also do not necessarily follow CSS syntax.
If JSS can not be leveraged in this way I will make an alternative solution, because I have many rules I've abstracted for rendering what I'm rendering to a Canvas. These rules are consumed by the Canvas renderer. So to render the type of graphic I'm producing there are several things involved: data, rules, fonts and then of course the Canvas API drawing primitives.
Because there are so many variations to how the data can be rendered for my industry I thought it would be best to abstract that aspect out to rule-sets and font-sets, instead of having a super complex renderer. That way users can just exchange rule-sets and voila they have the painting as they like. It's just the swappable stylesheet idea applied to rendering complex data that is better suited for Canvas than the standard div based DOM.
@HighOnDrive I'm not sure what the confusion here is, but Free Style also uses JSON - as I said above. That's how all of the CSS-in-JS libraries work. Personally, I wouldn't try to bake it into some CSS-in-JS library and I'd roll it as a compatible thing, because you're going to need to a lot more work on your side than CSS-in-JS libraries. But it's up to you, and you should make an issue on JSS.
Feel free to share a link when there's something I can look at, until then it's only theory on my side.
I guess what I have going on is something that echoes with how HTML and CSS work together, but instead it's JSON and my rules, which I can use on any 2d/3d canvas. It's my role to leverage what I can and close the gap but I've found all this CSS-in-JS stuff to be rather limited in scope.
What I mean is that it is just rules in JS we are taking about but the general idea out there is that it is exclusive for CSS, mean while I think the DOM basically sucks and so I only use it for frills.
However, how everyone uses rules in a limited way is really not my problem, I was just being friendly and reaching in with a few more use cases. What I will do is build my own rule engine (if JSS does not work out), simple enough to do. I leave you in peace as I venture past the DOM into the world of the raster.