Materialize CSS - Select Doesn't Seem to Render

Because they override the browser default, the select styling needs Javascript to run. You need to include the Materialize Javascript file, and then call

$(document).ready(function() {
    $('select').formSelect();
    // Old way
    // $('select').material_select();
});

after you've loaded that file.

The design of select functionality in materialize CSS is, in my opinion, a pretty good reason not to use it.

You have to initialize the select element with material_select(), as @littleguy23 mentions. If you don't, the select box is not even displayed! In an old-fashioned jQuery app, I can initialize it in the document ready function. Guess what, neither I nor many other people are using jQuery these days, nor do we initialize our apps in the document ready hook.

Dynamically created selects. What if I am creating selects dynamically, such as happens in a framework like Ember which generates views on the fly? I have to add logic in each view to initialize the select box every time a view is generated, or write a view mixin to handle that for me. And it's worse than that: when the view is generated, and in Ember terms didInsertElement is called, the binding to the list of options for the select box may not have been resolved yet, so I need special logic observing the option list to wait until it's populated before making the call to the material_select. If the options change, as they easily might, material_select has no idea about that and does not update the dropdown. I can call material_select again when the options change, but it appears that that does nothing (is ignored).

In other words, it appears that the design assumption behind materialize CSS's select boxes is that they are all there at page load, and their values never change.

Implementation. From an aesthetic point of view, I am also not in favor of the way materialize CSS implements its dropdowns, which is to create a parallel, shadow set of elements somewhere else in the DOM. Granted, alternatives such as select2 do the same thing, and there may be no other way to achieve some of the visual effects (really?). To me, though, when I inspect an element, I want to see the element, not some shadow version somewhere else that somebody magically created.

When Ember tears down the view, I am not sure that materialize CSS tears down the shadow elements it has created. Actually, I'd be quite surprised if it does. If my theory is correct, as views are generated and torn down, your DOM will end up getting polluted with dozens of sets of shadow dropdowns not connected to anything. This applies not only to Ember but any other MVC/template-based OPA front-end framework.

Bindings. I also have not been able to figure out how to get the value selected in the dialog box to bind back to anything useful in a framework like Ember that invokes select boxes through a {{view 'Ember.Select' value=country}} type interface. In other words, when something is selected, country is not updated. This is a deal-breaker.

Waves. By the way, the same issues apply to the "wave" effect on buttons. You have to initialize it every time a button is created. I personally don't care about the wave effect, and don't understand what all the fuss is about, but if you do want waves, be aware that you'll spend a good portion of the rest of your life worrying about how to initialize every single button when it's created.

I appreciate the effort made by the materialize CSS guys, and there are some nice visual effects there, but it's too big and has too many gotchas such as the above to be something that I would use. I'm now planning to rip out materialize CSS from my app and go back either to Bootstrap or a layer on top of Suit CSS. Your tools should make your life easier, not harder.

@littleguy23 That is correct, but you don't want to do it to multi select. So just a small change to the code:

$(document).ready(function() {
    // Select - Single
    $('select:not([multiple])').material_select();
});