Javascript is much more like a board game than you might think. Let me tell you a story to explain what I mean.

I used to be convinced I just didn’t like board games. I’d played the usual Snakes and Ladders, Sorry, Risk and Monopoly as a kid, and I could happily go without playing any of them ever again. Especially Monopoly. At least the other ones had an end in sight, even in Risk there was the hope of a quick and merciful rout, but Monopoly always seemed to end with people forfeiting just to get the game over with.

Then friends of mine started introducing me to board games that didn’t suck. Games like Clue and Red November and Space Alert and Ticket to Ride. It turns out I like board games after all, I just don’t like shitty board games.

Javascript, as it turns out, is remarkably similar. I used to think javascript just sucked, then I started working with ember. It turns out I don’t hate javascript after all, I just hate shitty javascript. All of the javascript I’d worked with pre-ember was a totally structureless mess – which I freely admit was partially my own fault. The vast majority of my programming experience is in java using frameworks like struts and spring which enforce a lot of structure. Server devs, myself included, don’t always know what to do without a framework enforcing some structure on our code.

Ember is an extremely opinionated framework, which as a veteran of rigid java frameworks I find comforting and familiar :) It also takes quite a few architecture decisions out of the developer’s hands, which is tremendously helpful if you’re a server dev with no interest in reinventing the wheel. Ember certainly isn’t the right choice for every single project, but it works very well in the context I’ve used it in and lets me get my front end tasks done quickly so I can go back to the server side development I prefer.

The moral of the story, in case you haven’t been paying attention, is that before you decide something sucks make sure you’re not just using it wrong.