Why I would avoid materializecss for my next app?

Material design is taking over the UI/UX by storm these days so I also decided to give materializecss, a CSS framework, a try. I heard about this framework through my colleague and it did surprised me with its tons of cool effects.

So for my app, Fuitter, I added the framework using the materializecss gem because I was not able to make the fonts work by manually adding the links to files.(it was a bummer)

Materializecss have everything I needed for my app`s design, like the side nav bar, wave in the buttons and more. While the materializecss team is doing a great job with its framework, I am planning to not use it anymore in the future.

I wanted a select field for the TLD in the domain section and I rendered it  using rails form helper but after I refreshed my page the select field was not rendered, it was present in the DOM but it was hidden. I had to spend a good one hour before the Eureka moment hit me. The default select field in materializecss overrides the browser default property, so to render it I had to use javascript and that is not cool. So why the heck this is not cool? What if I had dynamically created select fields? Meteorjs renders view on the fly , so I would have to write tons of logic in each template to initialize the select every time the view loads.

<%= form_tag() do %>
    www.
    <%=  text_field_tag(:domain_name) %>
    <%= select_tag(:tld, options_for_select([['.com', '.com'], ['.org', '.org']])) %>
<% end %>

This will be hidden until you add some javascripts.
<script>

$(document).ready(function() {
    $('select').material_select();
});

</script>

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


By the way, the wave effects in the buttons also has the same problem.

While materializecss provides a lot about all the 'effects' modern apps will demand I'm not sure those types of designs and concepts fit into large scale software just yet.