-
Notifications
You must be signed in to change notification settings - Fork 331
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
To ember-cli-materialize or to not ember-cli-materialize? #17
Comments
i am using for my very specific needs a mix of materializecss and ember-paper. The problem with materializecss is that it is like bootstrap, all done with jQuery plugins and tons of external libraries included (the good of course is the very large feature set and an impressive commit activity). ember-cli-materialize is just a wrapper for materializecss, all the JS stuff is done by materializecss for the two components they have in the demo. Ember paper however is very elegant and in JS things are done the ember way and no external libraries are included or required, but the feature set is a bit limited right now. What about just using the CSS straight from materializecss instead of angular-material ?. That is more or less what I am doing, and I plan to add ember-mobiletouch (hammer/fastclick based, very active development) to the mix. If there is a big enough overlap between my own requirements and the direction ember paper is going, I would love to contribute. |
So, you're basically proposing something in the middle. Don't know how coupled these two things are, but it might be worth a try. |
+1 for @rsaccon 's comment. Doing things the ember way is the way to go, imho. |
+1 for @rotatingJazz 's comment. |
LumX looks like a really good option and it's written in SASS. Transitioning from their Angular directives to Ember components looks pretty straightforward. |
FWIW materialize isn't the most adherent to the spec ... angular material look much better. 👎 on materialize 👍 on current direction which looks a lot better. |
Angular material is much more complete and closer to the spec, indeed. Quoting from https://material.angularjs.org/
Besides this, I really like ember-paper's classes and overall architecture: Having ripple support/shadows in a mixin, extending from a base class (BaseFocusable) to get similar behavior, etc. I feel like the design concepts are mapped to the object model, and that's very sexy (and possibly more maintainable and performant). Would love to see other users input on this matter. I'd love to combine efforts. |
This is just nitpicking, but thoughts on changing prefix to Side-note: adding {{md-button label=controller.state ink=false}} |
I think that a point was proven that Ember Paper has its own value and therefore should remain existing. |
Materializecss looks really good and they adding very fast new elements and features. At the moment ember-cli-materialize with materializecss is much more complete then Ember Paper - for this reason I made ember-cli-materialize. If Ember Paper add more elements and features of angular material then I think it will be the main material library for Ember. And ember-cli-materialize will be only a wrapper for materializecss. Ember Paper should absolutely remain existing. |
A new css framework for Material design has emerged. It's called materialize: http://materializecss.com/
Their [github repository] looks really good: https://github.com/Dogfalo/materialize
Decent amount of commits, contributers and stars.
Additionally, ember-cli-materialize appeared. This addon goal is very similar to ember-paper, but using materialize CSS (which is really the hardest part).
I began wondering if it made sense to migrate all our efforts to ember-cli-materialize and materialize.
I like diversity, but I'm definitely not a fan of duplicated projects. That confuses users and it isn't efficient.
I would like to know ember-paper users thoughts on this question.
The text was updated successfully, but these errors were encountered: