What I eventually realized is that these frameworks felt wrong because they don’t use the right abstraction. Modeling web apps as MVC, MVVM, MVP, MVT, MVASDFASDHSFGSDFGHQRTQRTAFGLKJNNGJSKL, these are all the wrong abstractions.
The Infinite Monkey Theorem states that given infinite monkeys banging the keys on infinite typewriters for an infinite length of time, the probablity that Hamlet will appear somewhere on one of the monkey’s typewriters is equal to 1, i.e. one of the monkeys almost surely produces Hamlet. MonkeyType.js takes this theorem to heart and uses it to create an abstraction for UI programming that’s so wrong, it couldn’t be more right. The best part about a client-side framework based on the Infinite Monkey Theorem is that the Infinite Monkey Theorem is MATH!, and uses terms like almost surely in confusing ways that only make sense if you know MATH!, and are otherwise just confusing and misleading! You have to be really smart to know MATH!, so you also have to be really smart to understand MonkeyType.js. No dummies who only know how to make solid, functional user interfaces that are intuitive and aesthetically pleasing; only the best front-end engineers need apply to use MonkeyType.js, because with MonkeyType.js, you have to be able to do all of those things, and also know MATH!, and not dumb kiddy stuff like fractions, but REALLY HARD MATH! that famous French guys invented. Everyone knows French stuff is really cool and hard to understand; the other night I watched Amelie, and I had no idea what was going on, but it was French, so I can just go up to people and say “Hey, have you seen Amelie? It’s French” and they know how smart and cool I am to be able to understand French stuff. And then they’re even more impressed when they find out I’m the inventor of MonkeyType.js and I understand MATH!
A typical MonkeyType.js program has two parts: the monkeys, and the typewriters. The monkeys represent the data. They’re sort of like the model in other frameworks, except with more MATH!, and more French. The reason monkeys are a better abstraction for data than a model is that models are stupid and for babies. When I was a stupid baby I got this model of an airplane for my birthday. It was wood. I kept trying to build it and getting splinters in my fingers that really freaking hurt. Finally I got a splinter under my fingernail, and it hurt so bad that I got mad and threw that dumb airplane model across the room and it broke, and my mom had to come in and hug me. I wouldn’t stop crying, so finally my mom had to take me to the zoo to make me quiet down. I didn’t stop crying until I saw the monkeys. I was only fifteen years old, but I kept that love of monkeys my whole life, and I never cried again, until I got home and stepped on a broken piece of the airplane model and got a splinter in my foot.
The typewriters represent the appearance, sort of like the view in other frameworks, except with more MATH! Typewriters are way better than views. I hope I don’t have to explain this one; views remind me too much of 1985’s A View to a Kill, and then I spend all day mumbling “Dance into the fire” under my breath and my smarmy co-workers who pretend to be my friends but secretly laugh at me because they all hacked into the Pentagon’s computers when they were ten years old and I didn’t learn to program until I was forty-seven start talking behind my back.
The monkeys pound on the typewriters to create the website. Unlike other dumb frameworks that have something like a controller standing between the model and view, MonkeyType.js lets the monkeys pound directly on the typewriters. Here’s where the really cool part comes in. Obviously we can’t have infinite monkeys and infinite typewriters on a modern computer with finite memory, so MonkeyType.js uses a clever optimization called a monkey barrel. Instead of infinite monkeys, the monkey barrel contains about twelve or thirteen monkeys that it keeps recycling. Every time you ask for a monkey, the monkey barrel gives you a monkey. It might be the same monkey you got last time. It might be a different one. Since one monkey’s as good as another monkey, with this approach, you effectively have infinite monkeys. The typewriters are stored internally in a circular buffer, which gives the impression that there are infinite typewriters, but it’s actually just, like, twelve or thirteen typewriters on a loop. And to create the impression of infinite time, MonkeyType.js is coded in an excruciatingly dumb way so that all the pages hang for at least a minute before doing anything, and when they do do something, they just load a spinner that swirls for another minute or two before the actual page you were looking at finally loads. This impression of infinite time is increased even further in production enviroments, where hundreds of trackers and advertising services also get to load before your content. This makes MonkeyType.js the perfect framework for rich media sites like Buzzfeed, Huffpost, and ZergNet, where every page is so obviously loading five hundred ads before it even thinks about delivering the content you asked for, because the advertising is actually the content and the content was actually just a bait-and-switch to get you to look at ads. But who cares, because we deliver ads with a firm basis in MATH!
In conclusion, where other JS frameworks give you broken abstractions based around dumb ideas like being easy to learn, easy to write, or easy to use to create great UIs, MonkeyType.js gives you abstractions based on MATH! and awesome stuff like monkeys and typewriters. Who cares if it causes memory leaks in your browser? It’s MATH! I hope you’ll consider MonkeyType.js for your next project, and finally learn what a real abstraction looks like.