Farewell WebTech
Or see you later rather?


End of this month, I will quit web programming and programming in general for some time, taking a much deserved time off and decide on my future direction.

It has been a nice ride, let me share a few things.

The beginnings

I edited my first piece of HTML back when using Netscape Navigator in Windows 95. It quickly grew into a hobby and starting in 2000, I was managing a few game-related fan pages.

Back in those days <table> based layouts with bgcolor and <img> were all the rage. There was no CSS back then, and noone was using JS for anything really. You basically did some PHP3, maybe with a MySQL 3 in the backend. No real classes in the backend code, no transactional database, no client side code.

At one point, I made the move from IE6 to Firebird as it was called back then, simply because it supported these semitransparent images called PNG. It was crazy, really.

Apart from some game-related fanpages, I also contributed to a browser-based MMO and did some occasional paid work when I was not in school. I also contributed to bigger pieces of software, both closed source and open source.

I was always the one embracing bleeding edge technologies. Table-less layouts, pure-CSS dropdowns, -moz-border-radius, etc. I actually wrote my Bachelors theses about WebGL, in a time when it was just an experimental thing in Firefox only, back in 2010.

Before that, I also switched to Linux full-time (apart from gaming), mostly motivated by the horribly bad Windows Vista. Well thanks for that actually :-)

Along the way, I developed a strong focus on frondend code and JavaScript. My Masters Thesis was about implementing a sophisticated code completion engine for JS. I know the language inside and out, hell I even wrote some of it. That refers to some of the ES2015 features I implemented in SpiderMonkey, the JS engine running Firefox. One of the achievements I am most proud of.

Problems ensue

But the web ecosystem itself moves in a direction I am not happy with and that I also do not want to be part of anymore, really.

One of the problems is the community that is increasingly moving towards a Java-esque mindset where it is ok to just layer abstraction over abstraction, all that after you have to install hundreds of megabytes of tooling, all while wrestling with packagers and half-broken solutions to things like hot module reloading and things like that.

You are left with either choosing library A that can’t handle usecase X you have, or with library B that sucks because of completely different reasons. Things are buggy and incomplete, and nodejs still has not figured out what to do about ES2015 modules, predictions are it will take a year to sort it out. It is a real mess.

People jokingly call all this JS fatigue, but it really is draining all your energy, especially if you have been at it as long as I have.

The web as a platform

Proponents always say that the web is a single platform that can finally achieve the “write once, run everywhere” thing we always wanted. Sadly, it is far from it. It is actually four main browser engines running on different operating systems on different hardware and form factors. All of those break in surprising ways and have subtle incompatibilities that haunt you any time you want to do anything interesting. Not to mention legacy systems.

For the last 2+ years I have been working on pagestrip, which provides a system for digital publishing which brings user authored content to the web and scales it to the available viewport pixel-perfectly. It does sound pretty easy, and that is the reaction I got from most people who asked what I (used to) do for a living.

But the devil is in the detail, and making those things work on all those different platforms with halfway decent performance and visual fidelity is, at least for certain things we want to do, simply impossible because of platform limitations. Chasing down all the edge cases is really frustrating work. Up to the point where I just snapped and said I could not take it any more.

(As a funny side story, a former collegue of mine quit a few month prior after a very long time struggling with implementing proper snapping in the editor part of our platform. He just snapped :-)

I am also jokingly referred to as the CSO of the company, the chief scrolling officer, because one of my recent projects was to implement proper scrolling with snapping support. You know, because browser-native scroll snapping is a changing spec that only has some incomplete, incompatible and buggy implementations in browsers. And we kind of need to have that stuff working.

But oh boy is it hard! With all those different browers, devices and input methods. Its a real mess, believe me! One might rightfully say that it really was what broke me at last.

The Future of Software

But lets get back to software development and programming languages in general. There is one big trend I see in recent times, which is to write more and more software in javascript.

Actually, I think the main goal was to have one language that you could use to write software for all platforms. Something Java failed to do (thank god for that), but now JS is kind of achieving, for better or for worse.

I can see this trend looking at the proliferation of both Electron for desktop development and react-native for mobile. And I really see the appeal of both approaches. You can share, say 80-90%, of your code across platforms. And electron itself is much more of a single platform than the mess of incompatible browsers is.

But I am deeply opposed to this trend. Simply because JS / web technologies is not the right technology to use for this. As much as I have worked with JS over the years, also my own opinion about things like type systems has changed a lot over the years. And by now I am ready to say that JS is a horrible language, just as the web platform is a horrible platform.

One of the reasons is the nature of web technology. It is extremely flexible and dynamic. But that is also one of the weaknesses. Because it is only ever going to grow. Let me give you an example.

The number of properties of CSSStyleDeclaration (aka Element.style) will only ever grow, it will never ever increase. There is no thing like deprecations or semver-major releases of web tech. Features will never ever be removed.

The goal of pay for what you use does not work in the context of web technology. It is impossible just by the nature of the technology. Browsers will only ever get more complex. They will use up more memory and system resources, just because of the standards development. And that does not even mention the ever increasing bloated libraries that pile up layers of abstraction in a language that has no zero cost abstractions.

I mean we now have 4 cores and 4G of RAM in our phones, and easily 8 cores and up to 32G of RAM in our desktop computers. Because we actually need that much to run all the bloated software. Sure, “unused memory is wasted memory”, but maybe I want actually multitask and be able to run more than one program at the same time.

Not to mention startup cost. I would argue that before the advent of SSDs, system bootup and app startup was mostly IO limited. But now with more and more desktop apps moving over to things like electron, things become CPU bound again and a simple text editor needs up to one second to start. This is simply unacceptable. I want the PC to wait for me, not the other way around. And speaking of SSDs, storage might also become a bottleneck when every piece of software needs a ~100-200M electron bundle. At least on linux distribution packaged software can deduplicate that. No idea how huge react-native packages are though, but I bet they aren’t light either.

Speaking of react-native, I am actually happy that it will hopefully kill this thing called mobile web apps. I think those were a terrible idea, contrary to what other Mozilla fanboys might think, related to Firefox OS.

Anyway, I think mobile web apps were a terrible idea, because they were never able to match both the performance and the look-and-feel of native mobile apps. React-native takes care of that by at least providing a native look-and-feel. And react-native is also increasingly moving performance critical things (such as animations) to native code, because, oh what a surprise, JS sucks when it comes to performance.

Electron is kind of the opposite. It rather provides a unified look (and themeable, that really is a plus) of one app across platforms, although electron apps will not really match the look-and-feel of native apps for each desktop platform. And like I mentioned, people are apparently happy with subpar performance on desktop for whatever reason.

The hero we deserve

Well I am personally betting quite heavily on Rust, a language that is extremely high performance (on par or even beating C++), but also safe (no crashes) and most importantly easy to use. Well at least once its ergonomics are improved a bit, which is an ongoing task. I am especially excited about non-lexical lifetimes.

I am also happy to see some progress for the general problem of 2D graphics and performance, a problem that former(?) Qt developer Zack Rusin was talking about 7 years ago. I mean it really surprises me every time why modern games can render millions of polygons and extremely high quality graphics at buttery smooth framerates but web pages still stutter. I do think that finally we have the proper technologies to move 2D content to the GPU. Not surprisingly, part of that stack is written in Rust. Pathfinder, a high quality GPU font renderer and webrender, a 2D scene graph renderer optimized for web content.

Also the GNOME/GTK community is making progress towards hardware accelerated drawing in GTK4 via GSK, and doing experiments around bringing GTK and Rust closer together, which I am very excited about.

Since electron clearly shows that desktop apps are moving toward a custom themeable look-and-feel across platforms instead of platform native look-and-feel, maybe the time would be ripe for a completely new toolkit powered by webrender, with a css inspired theming solution, but still with a clear strategy on deprecation and purging/detoxing of obsolete features.

Coupled with a language that actually supports zero cost abstractions and pay for what you use resource usage.

Or maybe it will rather happen in the form of react-native for desktop powered by WebAssembly, so you can still use a decent language.

In closing

Exciting times, certainly. Only time will tell, but I sure am too tired to be on for the ride. I will just wait this one out, practicing my Rust game in the meantime, hoping that things will turn out for the better in the long run.

Peace out.

Inadequacies of typed JavaScript
Some things can’t really be fixed :-(

The last week I have been playing extensively with both flow and TypeScript. And I have noticed two things that I consider to be bugs in both of them. So is there something wrong with my expectations maybe? Lets analyze both of the cases.

non-nullable class members

TypeScript (TS) introduces non-nullable types with version 2, and flow has had them for quite a while I think. There have been tons of stories about how bad the null type/value is. Some call it the worst mistake in computer science. And indeed, most of the errors we have at runtime are related to null. Accessing properties of null, or calling null. Having to check values for null all the time is tedious and as the runtime errors prove, null can slip through at all kinds of places.

It is even worse in JavaScript because it does not have one null type but actually two: null and undefined. To make things worse typeof null === "object" and typeof undefined === "undefined, so you can’t even check for both cases at the same time; well actually you can use value == null since that also works for undefined. Go figure.

To make more worse still, JS also has boolean coercion. Which itself can be convenient, but you can very easily trip up. If you have a value that has the type number | null, using a simple if (value) will fail for the value 0. Probably not the thing you intended. And you will get it wrong at some point. I have done so over and over again.

So, to come back to the topic at hand. Both flow and TS now prevent you from tripping up on most of the null issues, except for the boolean coercion. But both of them get one case wrong:

class A {
prop: string;
const a = new A();
a.prop.length; // typechecks just fine, fails at runtime

This simple code will typecheck just fine in both flow and TS, but will fail at runtime with a TypeError because you are accessing a property on null. I have reported this on the TS issue tracker but it was closed as a duplicate of a wontfixed issue. Apparently it is too difficult to correctly cover all the different ways in which constructors can behave.

As far as I see it, the root of the problem is twofold. First, JS objects were never meant to have a guaranteed shape, its only these type checkers that kind of try to enforce those things. And the second problem is that JS constructors work by assigning/creating properties on this, which can be aliased or delegated to other functions, etc…

In other languages with stricter guarantees, such as Rust, you do not have this or constructor functions at all. The language itself guarantees that creating an object of a certain type is atomic via an object literal that is guaranteed to include all properties. (You can still use object spread for convenience)

Ideas to solve the Problem

Both flow and TS can hold up the typesystem guarantees if you are using object literals instead of classes. Use plain functions and object instead of classes. I have heard that one before. The whole functional programming crowd advocates this. Maybe they have a point? But I do like having methods on objects/prototypes. So maybe we can combine object literals that are correctly checked for null properties with methods somehow. Well there is this special __proto__ property that was specified for ES2015. I tried using it with TS, but failed. The method works perfectly in JS, but typechecking in TS fails. Well unless I want to copy every method into the object, which completely defeats the purpose of shared prototype methods.

type A = {
a: string,
function A(a: string): A {
return {
__proto__: AProto, // can’t assign to unknown property
const AProto = {
method(this: A) {
return this.a.length;
const a = A("a");
a.method(); // can’t call unknown method

So no luck here :-(

Aliasing literal / union types

Both flow and TS have the notion of literal types and union types. Union types are really simple. The type A | B can either be A or B. But since those are not native to JS, you have to have some way to actually assert the type at runtime. For primitives its easy, since you can just check via typeof. But discriminating objects needs to be done manually with a property used to tag the object. In the following example, U is such a union type and it can be discriminated by looking at the type property. And here we are actually using strings as types: literal types. So in this case U.type has the type "a" | "b", so it can either be the string "a" or "b", but nothing else.

type A = {type: "a", propA: string};
type B = {type: "b", propB: number};
type U = A | B;

Both flow and TS handle these things quite well. If you use .type in a switch or if statement, you can match for the exact type. But both typecheckers fail if you want to alias that property, for example via destructuring: const {type} = X;. Here, the type of type is widened to string and it can no longer be used to discriminate the union type. I also reported this in the TS issue tracker and got the answer that is would be two complicated to implement this, because it would involve tracking the dependency between the two variables, increasing the depth of the dependency as more aliases are added.

Well at least this can be easily fixed by just always using the property instead of extracting it into a local.

Closing remarks

I wish one of the compile-to-js languages would actually support real union types and has a real match expression. Automatically tagging variants or even supporting null-pointer optimization so you don’t have to have unnecessary indirections if a simple typeof check would be enough.

There are already compile-to-js languages that support things like this. For Example Elm and PureScript (both based on Haskell). And possibly ClojureScript, even though I know too little about that language. With the recently released BuckleScript, you can also compile OCaml to JS, with quite readable code, although I don’t quite like that it encodes structures as arrays and thus misses out on hidden class optimizations of JS engines (I could be wrong though). With Reason you can even write readable OCaml.

And of cause, I am very excited to see steady, although very slow progress towards compiling Rust to WebAssembly. Although I’m unsure about the FFI between WebAssembly/asm.js and real JS. It relies on a preallocated ArrayBuffer as a kind of heap, which might be good for low level performance but does not play well with consuming and outputting plain JS objects.

So the future is still very much open. I really hope there will be a readable, convenient, fast and safe compile-to-js language that can solve all these problems and integrates seamlessly into existing JS projects. One can dream though.

Über Diversität und ein friedliches Zusammenleben

Aus gegebenem Anlass möchte ich gerne meine Meinung zu verschieden Themen erläutern die mir am Herzen liegen. Da ich schriftlich meine Gedanken besser ordnen kann ziehe ich das einer wörtlichen Diskussion vorerst vor.

Mich stört

Ich sehe oft Verhaltensmuster in Individuen und in der Gesellschaft die mich durchaus stören und die ich für gefährlich erachte. Hier einige Beispiel, manche aktuell, manche alt.

  • Person A schließt Personen aus ihrem Freundeskreis aus weil diese Partei X wählen.
  • Person B würde am liebsten Menschen verprügeln die Partei X wählen.
  • Person C geht zu einer Demostration mit der Absicht Menschen zu beschimpfen.
  • Personen D und E verarschen mich weil ich nicht gegen Organisation Y bin.
  • Personen boykottieren und hetzen gegen eine IT Konferenz weil auf dieser Person F einen Vortrag hält.
  • Personen hetzen gegen Person G weil diese Jahre zuvor Geld für einen politischen Zweck gespendet hat.
  • Person H will am liebsten Partei X verbieten.
  • Person G bezeichner alle Wähler von Partei X als dumm.
  • Website W löscht und zensiert Kommentare mit gewissen Inhalten.

Wenn man etwas verallgemeinert könnte man dieses Verhalten als Mobbing bezeichnen. Und glaubt mir, ich kenne mich mit Mobbing aus. Ich war mein Leben lang Außenseiter und wurde mein Leben lang gemobbt. Genau aus dem Grund will ich vor den Gefahren dieser Verhaltensmuster warnen.

Die demokratische Grundordnung in Gefahr

Auf den ersten Blick scheint es sehr weit hergeholt, aber ich finde das dieses Verhalten im Zusammenhang mit Politik die gesamte Grundordnung auf den Kopf stellt.

Mal angenommen Person H bekommt ihren wunsch und Partei X wird verboten. Vielleicht weil Partei X zu rechts ist. Als nächstes verbieten wir dann noch Partei Y weil sie zu kommunistisch ist. Dann Partei Z weil sie zu öko ist. Partei W verbieten wir auch aus irgendeinem anderen Grund. Und ehe wir uns versehen haben wir Scheinwahlen auf deren Stimmzettel nur eine Auswahlmöglichkeit ist.

Und wie sieht es mit Überwachung und Zensur aus? Es wird tatsächlich zunehmend zensiert im Internet. Unter dem vorbehalt rechte oder hass verbreitende Kommentare zu löschen. Aber es geht auch schon einen Schritt weiter. Ein Freund hat mir neulich geschildert wie er zum lösches seines Facebook Kontos getrieben wurde. Nachdem er einen Beitrag einer politischen Partei kommentiert hat wollte Facebook urplötzlich seine Identität durch eine Passkopie feststellen. Ich selbst nenne es einen meiner Lebensgrundsätze niemals bei Facebook zu sein und nenne schon seit Jahren Facebook als eine der größten Gefahren für das freie Internet.

Die Frage ist auch wo wir die Grenzen ziehen. Wir haben heute schon Person C die absichtlich Menschen wegen ihrer politischen Meinung beschimpft, wir haben schon Hetzkampagnen gegen Einzelpersonen, Parteien oder sogar IT Konferenzen. Wo ist die Grenze? Was ist wenn Person B tatsächlich anfängt Anhänger von Partei X zu verprügeln? Irgendwann sind wir so weit das wir deren Häuser anzünden, und sie schlussendlich ermorden.

Ist das alles so weit hergeholt? Vor 70-80 Jahren hat es sicherlich auch mit Mobbing angefangen. Mit dem ausschließen aus dem Freundeskreis. Mit Beschimpfungen und dem Boykott von Veranstaltungen. Wie es geendet hat steht in den Geschichtsbüchern.

Mobbing ist tatsächlich eine starke Waffe. Es kann dem Menschen den Gedanken in den Kopf setzen er müsse sich für seinen Körper schämen. Oder für seine sexuelle Orientierung. Und jetzt sogar für die politische Meinung? Wenn durch Mobbing dies auch noch manipuliert wird sehe ich auch deswegen die demokratischen Grundsätze in Gefahr. Noch gut das es ein Wahlgeheimnis gibt. Oder sollen wir dieses auch bald abschaffen?

Ein Apell für ein friedliches Zusammenleben

Ich habe zwar selbst viele Vorurteile. Aber ich versuche dennoch jeden Menschen mit Respekt und Würde zu behandeln, ungeachtet dessen Hautfarbe, Geschlecht, Religion und politischer Meinung. Sofern sie mir den selben Respekt entgegen bringen :-)

Ich finde es sehr schade dass viele Leute die ich kenne, und die sich selbst als ach so tolerant bezeichnen dessen nicht fähig sind und stattdessen Menschen mit anderer politischer Meinung beschimpfen oder am liebsten verprügeln würden. Eben von den Leuten erwarte ich das sie es besser wissen sollten.

Ich würde die Menschen in meiner Umgebung eher als links einordnen, falls ihr mir das Schubladendenken verzeiht. Aber das Maß an Hass den diese Menschen gegen rechte versprühen übersteigt meine Toleranz etwas. Und nicht nur das. Auch Menschen die nicht gegen rechts sind kriegen diesen Hass teilweise ab. So wie ich.

Ich bin nicht gegen rechts. Ich bin auch nicht für rechts. Ich bin dafür das jeder Mensch ein Recht darauf hat sich frei zu entfalten und mit Würde behandelt zu werden. Und ein Recht auf freie Meinungsäußerung usw, auch wenn die Meinung vielen Leuten nicht gefällt.

Dennoch muss man sich im Kopf behalten dass die eigene Freiheit dort aufhört wo sie die Freiheit anderer Menschen einschränkt. In diesem Sinne: Seid lieb zueinander :-)

The one killer feature icon fonts have over svg
OR: why github icons look like shit now

The reason I write about this now is githubs icons started to look like shit on my screen/system since a week or so. I asked myself why and looked at the source to find out they switched from using an icon font to inline svgs. There is quite some controversy about whether to use an icon font or svgs for icons. Just google for it to find some articles about that topic.

What neither of those articles mentions is the one killer feature that icon fonts have over svg. Actually its two features, but they are a bit related. It is this: hinting and subpixel anti-aliasing.

In english, hinting means that the font rendering will snap straight lines to device pixels, to make sure that fonts always look crisp. And subpixel AA means that the font rendering can boost the horizontal resolution by 3 due to the fact how lcd hardware actually works.

Both of these features are unique to fonts, they do not apply to svg. Hinting can actually distort the proportions somewhat to make sure straight lines snap to pixels, you clearly do not want that for svg. And although subpixel AA may be possible for svg, I have never seen that been done so far.

There is quite some hoops you have to just through to make svg, and especially <canvas> look good and crisp. If you want a line that is 1px wide to look good, you have to place it at a 0.5px coordinate, so when you add the width, it ends up at [0, 1] and therefore looks crisp. You do not want to do that for a 2px line though, because you end up with [-0.5, 1.5] which looks like shit again. It’s hard. Believe me, I’ve been through that already.

The point im trying to make here though is that in order to make svgs look good, you actually have to give up on one key selling point of svgs: scalability! You have to author svgs, specifically for one size to make sure that lines snap to device pixels. Fonts will just do the work for you.


All that I have written about here applies to my personal system, which has a device pixel density of 1. For low dpi screens, hinting matters a lot. The problems I described here are much less of a problem on high resolution screens.

The second thing to note is that content authors do not control font rendering all the way. Sure, there are css properties like font-rendering and friends, but for example the hinting behavior can not be controlled by the author, but is a system wide setting. On my system, I have hinting turned up quite high because I prefer light crisp fonts rather than thick blurry ones. One of the hits you find on google for that topic mentions that icon fonts look blurry compared to svgs. They might, depending on your font rendering settings. On the other hand though, svgs look blurry if lines do not line up with physical pixels, pun intended.

Fact is that font rendering settings also very much depend on your personal taste. Some people for example have font smoothing / anti-aliasing disabled altogether, most likely because they don’t know such settings exist. If I have to use someone elses system, turning on font AA is the first thing I do, because it really hurts my eyes.

I have a also recently seen a developer post a screenshot without font AA that also hurt my eyes really bad. Come on, it’s 2016 for fucks sake! There is absolutely no reason to not activate this single most important feature of a modern desktop!

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.


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.


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"
const ThemeManager = new Styles.ThemeManager()
class App extends React.Component {
getChildContext() {
return {
muiTheme: ThemeManager.getCurrentTheme(),
render() {
return <AppBar
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.


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.


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.