Boink: My Attempt to Beautify My Web App Code

My web apps tend to be a mess.

Over the past few years, I've written a number of "single-page apps"., Tunr, Roomie, etc. As I never bothered to learn any of the hip new client-side SPA frameworks (Angular, Ember, etc), my first step was always to come up with a good way to manage the UI. In my haste to build an awesome app, I never put too much thought into crafting a nice way to manage how I was displaying information, or even architecting the app in the first place.

The result was nightmarish spaghetti code. Extremely short-sighted hunks of code to apply this animation here, update this element here, insert these elements there, etc. Despite this, however, I'd receive praise for how beautiful and smooth the UI was. The code, despite being poorly conceived from a perspective of re-use and modularity, was very efficient at what it did: move elements of the DOM around to display what it needed to the user.

Once others started diving into my code, though, this became a problem. It hit me harder when I dove back into old code of mine and couldn't easily come to understand where I'd need to make changes to add new features. I was lost in my own labyrinth of terrible UI code.

Tunr promotion video, showcasing some of the cool UI

You should use a framework, you idiot.

So how do I solve this problem? Use a framework, of course! I immediately dove into Google's Polymer project, which seeks to provide a framework that includes support for web components, data binding, common controls that implement "material design," and all sorts of other stuff.

It was a nightmare - nothing was easy. Tons of components and conventions that weren't very well documented. There was no support for TypeScript. Helpers were provided in places I didn't feel I needed help (a huge amount of "let me get that for you" CSS styles). In addition, a lot of it only worked well with Chrome. Worst of all, whenever something went horribly wrong, I didn't understand how the framework worked behind the scenes, so I had nowhere to go. It drove me crazy. Worth noting is that this was over a year ago, things may be much better now.

After wrestling with Polymer for days, I went back to spaghetti-UI, and productivity shot through the roof. I could bang out simple apps in no-time (the front-end was the result of one or two night's work), even if the code behind them was hideous.

Do it yourself.

I started thinking... what exactly do I need to do to beautify my apps? A way to declaratively write UI. A library that will interpret declared UI, and manage keeping it in sync with data, animating it, etc. I would write my own UI framework, and I'd call it Boink.

Instead of being a giant mess of spaghetti code, what if my app could look like something like this?

<template id="todo-list">

<template id="todo-item">
    {{itemDate}}: {{itemName}}

<todo-list data-context="{{todoItems}}"></todo-list>

Pretty straightforward. Define some templates, define where the data belongs, and Boink does the rest.

So far Boink already supports templating and data binding, and comes with some common components like Repeater. As I continue to write more apps with Boink, the framework will expand to support everything I need to do. Navigation model and animations are up next. Maybe when I get to a point where I'm confident Boink is fairly feature complete, I can go back and re-write some of my old projects to utilize it.

Tunr Artist Images

I've just added artist images to Tunr! Looking pretty smooth.

Soon there will be more, along with panning, and perhaps some nice coloration effects. More functional feature additions to come!


When I was a Junior or Senior in High School, I started this little project called RhythmCloud. This was around 2009. The idea behind RhythmCloud was that you could listen to your music anywhere, from any browser or mobile device, without ever having to sync anything. You'd simply run the RhythmCloud server on your home computer and it would stream your entire music library to any web browser.

So I started writing it. GStreamer for track conversation, ID3 tag libraries and SQLite for library database... PHP and HTML/CSS/JS for actually serving up the streams and library, and some weird Flash OGG player written in Haxe that I'd dug up on the web... I wanted to avoid any licensing things with MP3... and OGG actually tended to sound better at lower bitrates.

So I built it. And it worked

RhythmCloud Player

It was ugly, but it was working. It could stream your whole library with zero-effort from anywhere. All I needed to do was polish it up... maybe re-write it a few more times... but as with any side project, it got lost in the business of life.

Then Google Music came out. And Apple announced a cloud solution for iTunes. And Amazon Cloud player appeared. RhythmCloud didn't seem as novel as before. So I stopped working on it for awhile.

But since then, playing my music has never felt right. I started trying these new cloud services... and no matter what I tried, I never felt the experience was perfect. I was used to having my own library, and using desktop music applications like Amarok (or Clementine) and the powerful control they gave you over my music and playlists. I didn't want to sort through a gigantic list of artists and songs to build a new playlist each time I wanted to listen to music. And I also didn't want some random algorithm picking the mood of my music.

I wanted some real tools to bring the music I wanted to the surface of my own library. And I wanted it to be beautiful. Like Zune beautiful (pictured), with the functionality of ye olde music library managers.

Zune beautiful

This experience doesn't seem to be out there. So I'm going to build it. My latest side-project is Tunr.

Tunr's landing page

I dabbled here and there with re-starting RhythmCloud. But after winning an award at MHacks 2014 with a cobbled together draft of what my cloud player might be like, I decided to start fresh.

Tunr at MHacks 2014

Tunr will feature your library. Copies of tracks that you posess, in the cloud. Tunr will keep your library in its original form, but store it online and give you access to it from anywhere. You'll even be able to sync your library to any device in the format you originally uploaded it in. New tracks that are added will be stored and synced as well. Your library is everywhere at once, and always up to date.

This persistance of your library has a huge number of benefits outside of just data security as well.

  • Playlists and preferences stored in one central location, accessible anywhere
  • Adding music on your phone or computer and having it available instantly on other devices
  • Long term analysis on music discovery and listening patterns

This last point is huge. Data is powerful, and if you use one platform to manage and consume your music across all of your devices, you're unleashing a treasure trove of data that can be used to further your listening experience. At a surface level, this could reveal things like what sort of music you tend to listen to during the winter, or if your mood tends to shift toward a different genre during weekend nights. The possibilities are endless! Imagine mood-driven music experiences, where the system is already informed about what sort of moods you tend toward given the current context.

I'm super excited about this project, and have been for a long time. Hopefully I can manage to at least get a working prototype to production quality this time!