Material Design is a design standard proposed by Google. It’s not CSS but a set of rules on how things should look and feel.
So you got the Materialize team building out a CSS framework based on those rules.
Then you have Google building out a CSS framework based on those rules.
Since Google wrote the rules, it makes sense to use Google’s implementation of material design. It’s going to be long supported and straight from the horses mouth.
That is a basic point of view. The more I think about the question, the more i realise that it will all depend on the level of support over time. IMO, MDL is too early to adopt. Materialize has an established community with non core devs committing a steady stream of PRs. I’m going to wait a month and monitor the git pulse. If MDL can establish the same support over the next month or so then i think Materialize will soon be obsolete.
I agree with @dcworldwide. That would mean a lot of devs would also have to re-develop some packages that will use mdl instead of materialize, that would include such things as useraccounts:materialize and autoform:materialize, which i use. (but it might get away their unstylized versions, but i havent tried) Besides, as i see it, mdl based its idea of non-jquery usage, so that you can use it without having a jquery package… But meteor heavily uses jquery and has it as part of its standard package… So using bootstrap (as the standard defacto css framework design in all tutorials) and its material design counterpart materialize makes sense. It took awhile for materialize to gain some ground in the community… Might took some time as well for mdl (once it has a very stable and semi-official package to offer)
@zodiase You rock! man.
Adding the following piece makes it work with iron router.
Template.myTemplate.onRendered(function () {
componentHandler.upgradeAllRegistered();
});
meteor add zodiase:mdl 
Hey thanks @nobso. By the way I don’t think you need to call upgradeAllRegistered as my package does that for ya. If it does not work that way for you then… well… we obviously have a bug somewhere.
I don’t see any issue as of now with your package. It works cool!
I just tested initially with that code and removed that after adding your package.
@nobso
Good to know. If you encounter any issue later (I believe there are a lot) and would like to help make the package better, feel free to fire them up in my git repo, better with some code example to reproduce the issues.
Of course! I will do
What would be the benefit of using the MDL package vs. the CDN ?
In my opinion, MDL package will take care of the event attachments to the DOM elements. If you use the MDL from the CDN directly, only the CSS will work and not the MDL’s JS functionalities. So the work around is as mentioned in the Material Design Lite. But you dont want to mention that for every template in your project if you use MDL package as its handled at the global context.
@richenglish & cc @nobso
There are issues with using MDL directly with Meteor. I listed a few in the Readme file in my repo. For example, if you have some template code like:
{{#if someFlag}}
<button class="mdl-js-button">Button A</button>
{{else}}
<button class="mdl-js-button">Button B</button>
{{/if}}
Assume someFlag initially was set to true, and it would look fine if button A has been rendered already at document.load. Now at the time when someFlag is set to false, this portion of the template will be re-rendered by Blaze. And since the official MDL only scans for upgradable components at document.load, it won’t do anything for the newly rendered button B. The CSS may still work, but the js part won’t be there. If those buttons had ripple effects then they are pretty much useless unless you find your best timing to upgrade them.
My package does (or at least tries to do) this for you.
Hey @zodiase , how do we choose a different theme? For now, i’ve included the CSS from the Google CDN in my page level template.
Isn’t there any configuration in your package that i can use to choose the theme?
@nobso
I actually thought about this. I think instead of supporting dozens of pre-defined themes that the official MDL build contains, most of the users might end up using their own themes. I mean, even 100 options are not better than unlimited freedom. Also the extra support for that many options would add unnecessary weight to the package.
Not sure if google will go for it, but I’ve asked them to add autopublish support (https://github.com/google/material-design-lite/issues/1040). This will bring the MDL in line with MaterializeCSS which also presently supports autopublish.
Just made this forum post:
I’ve just tested all of the available MDL packages with this meteorpad and none of the packages support ripples with {{#if}} statements, including yours. I installed your package anyway, as you seem to go a bit deeper than the rest. And gave you a star for the activity
@KristerV
I had a look and it seems for some reason MeteorPad is not able to load the latest version of my package, which should be 1.0.0-4 at the moment. (Seems like MeteorPad is only able to find version 0.0.1.) I believe if you test locally that demo should work just fine.
We have just published a package that makes it easier to use MDL with Meteor. It wrapps the MDL elements in Blaze block helpers and handles upgrades and reactive values automatically. Check it out at https://atmospherejs.com/synka/mdl.
Material Design Lite is sleek! Check out Google’s new app, called Primer which uses cards and a lot of MDL features. Nice use of buttons and added effects for a better UX.
Just for the record of this, and as previous commenters have already brought this up. You can create a wrapper template to wrap your MDL components like so:
Template
<template name="mdl">
{{> UI.contentBlock }}
</template>
JavaScript
let tpl = Template.mdl;
tpl.onRendered ( function () {
componentHandler.upgradeAllRegistered();
} );
Usage
{{# mdl }}
<!-- Your MDL Component -->
{{/ mdl }}
Usage: Alternative
{{> mdl }}
<!-- Your MDL Component -->