Doing the impossible:

Choosing a Material Design Framework

The story starts like this: I am about to start developing a native-looking mobile App. And I would like to use Material Design for it. Since its awesome and I want a native look and feel.

And just as a precursor: Similar to Paul Lewis, I am also known to hate everything that looks and smells like a framework. Even though Material Design is just about styling, most of the Material Design Frameworks do come with some baggage in the form of JS and Framework lock-in. I am also extremely opinionated when it comes to JS Frameworks and Conventions. I kind of feel like I am chasing for perfection instead of getting shit done. But well that’s just how I roll :-(

So I was mainly looking at Materialize and Material-UI and the paper elements of Polymer. And then just during my research google released Material Design Lite. I also looked at some other smaller contestants, but those four came out top.

Before I start dissecting the choices, lets just say that every one of those is missing some things that I kind of need. It is kind of disappointing really. So many contestants, but all are lacking in some ways. :-(

So lets start.

# Materialize

Seeing how materialize was a bunch of jquery plugins, I quickly removed it from the list of options. jQuery was nice ten years ago, but I think we can do without it by now.

I actually did try the other three, Material-UI, MDL and Polymer.

# Material-UI

While I do like the concept and the composability of a react-like library, react itself is a bit too big for my taste. Putting material-ui into the mix, a simple page with just an AppBar comes to 1M of code. As opposed to all others, I actually talk unminified ungzipped code here. LOC would be a better measure but I don’t have exact numbers, except that it is HUGE.

It also has some kind of boilerplate:

import React from "react";
import injectTapEventPlugin from "react-tap-event-plugin";
import { Styles, AppBar, IconButton } from "material-ui";

injectTapEventPlugin();

const ThemeManager = new Styles.ThemeManager();

class App extends React.Component {
  getChildContext() {
    return {
      muiTheme: ThemeManager.getCurrentTheme()
    };
  }

  render() {
    return (
      <AppBar
        title="Foo"
        iconElementLeft={
          <IconButton iconClassName="material-icons">arrow_back</IconButton>
        }
      />
    );
  }
}

App.childContextTypes = {
  muiTheme: React.PropTypes.object
};

React.render(<App />, document.body);

As far as I understand, this means that you can change the theme dynamically, which would be awesome. But the boilerplate is a bit annoying nonetheless.

On the plus side, Material-UI has some nice special elements like date and time pickers. It seems to be quite complete.

What I don’t like about React is that you can’t have arrays of elements, except for children. But you can only have one children array per element. So Material-UI passes some children as props, which just feels wrong to me. I know that a lot of React libraries use this pattern, but it still feels wrong to me.

# Polymer

I started out with the full polymer starter. Maybe that was a problem, since its also HUGE. It was downloading 300M of npm packages, plus a lot of things from bower. It just generated hundreds of files and I have no idea for what purpose. I simply couldn’t understand all that code. And that’s not even library code. It’s supposed to be your own app code.

Also, I’m not really a friend of html imports. I would rather have ES6 modules and wire up as much through JS as possible, maybe even CSS. But having everything as HTML modules with code inside script tags just feels kind of backwards to me. Maybe I should start with an empty project so I wont be overwhelmed from the start.

I am also kind of ambivalent when it comes to web components in general. Sure, it is supposed to be implemented natively in the Browser. But you still have to pay high costs for it. The browser will have to (recursively) resolve the imports and load the things. HTTP2 Push will help a lot, but still. Also there is a lot of JS involved at app start. While it does not matter for the project at hand, I think think web components, depending on the way you use them might not be that great for SEO, serving static html and load times. But I might be mistaken completely. For now the whole machinery with html imports and the tools that are used to vulcanize them seem to be a little overkill for me.

I actually haven’t looked into how big the resulting code is, but I would probably have to use it in conjunction with a React-like library anyway so that would grow the size considerably as well.

# Material Design Lite

MDL was actually released right the moment when I was starting my research. Being mainly about CSS, with just little JS involved (sadly you can’t quite do without), and directly from google, it felt like it might be the best contestant. But it is also quite new and incomplete. It has no list components as of yet. And the Appbar kind of has a menu button hardcoded, I’m not sure how to replace that menu button by a back button.

Also something that really annoys me is that it is not yet easily embeddable in a typical app based on CJS or ES6 modules. The JS code relies on being globally imported, which I don’t particularly like. Hopefully this will be fixed, but until then its just annoying.

The JS Code comes to roughly 110K unminified and it is not too bad to read. The CSS also amounts to roughly the same size.

Again, I would use it in conjunction with a React-like library so that would add some weight. All in all, it feels to be the simplest base if I happen to do a lot of custom things. And since it has no lists yet, I would have to do at least those myself.

# Conclusion

I am still not happy with the choices I have to be honest. And I still feel like I’m standing in my own way. Since I want to use something that I actually like to use, as in feeling like I’m doing the right thing as opposed to getting things done but feeling like its all a big hack.

So I’m basically standing still for now. Maybe I will give a clean Polymer project another chance, maybe I will go with MDL and just implement certain things myself. Most likely I would have to implement quite some things myself anyways.