-
Notifications
You must be signed in to change notification settings - Fork 288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Roadmap #73
Comments
This is awesome, thank you very much @stereobooster. |
@MicheleBertoli any preferences for 2, 3? |
Thank you very much, @stereobooster. |
I found this gem https://github.com/milesj/aesthetic. This lib lists a lot of syntax/features with examples. Also found another edge case: JSS + rehydration
Yeah JSS has SSR for styles, but on client they are used only before JS app started, after JSS generates styles again. |
Nice benchmark http://necolas.github.io/react-native-web/benchmarks/ |
New hotness - |
(personal vision)
Everybody would agree that MicheleBertoli's comparison table is the widest (number of libraries being compared), but not the deepest (number of features being compared). I want to fix this.
First stage
The first stage is to implement a website for comparison table because it is hard to show and maintain a big number of features in markdown table.
So I did a basic website, which presents the same data as current readme. But as of now
Obviously, we need to automate website deployment. We can use CI to push updates or something like Netlify.
Information should not be duplicated in JSON file and Readme.
I have this idea that every feature should be proved with code example, so every change in the table will be accompanied by PR to master branch. Hence the question:
Second stage
It is important to define features precisely. I tried to do this here. CSS-in-JS is so new and fast-moving field, so it is hard to track everything and unprecise definitions make life harder. For example, Radium supports
:hover
, but this is not actual CSS pseudo class, but faked with JS listeners, so it will not work with disabled JS (no progressive enhancement). Disclaimer: I haven't checked what it does right now, maybe this changed.As soon as we come up with proper definitions, we will need to come up with a code example for at least one library to show how it suppose to work. After this we can add a new feature to the table and mark our one new example as "positive" (or green color) every other library in the table will get "unknown" state (or gray color) until somebody will provide "code proof" of "positive" or "negative" result. Example of icons: #80
Improvements
We can make life a bit easier by implementing screenshot testing, to make sure every example looks the same.
We can implement benchmarks. Examples: 1, 2, 3, 4
Calculate footprint of CSS-in-JS solution with something, like size-limit
Other comparison tables
The text was updated successfully, but these errors were encountered: