I went to Wordcamp Lancaster this year. It was a great time. I gave a talk on Javascript and after the conference, I was perseverating about one of my favorite things: what the f%c Javascript framework should I use. Rami Abraham (who organized the crap of out of WC Lancaster by the way) was quick to point out that we had probably drunkenly discussed this very same topic on no less then seven different occasions. Like usual, Rami was right. Sometimes we do it on Twitter.
I think about this crap a lot and I’ve never really figured it out.
Stop me if you’ve heard this one. I’ve been working on this new project, trying to pull JavaScript and the WordPress API to pull together some pretty cool tools for writers and developers.
Awesome. Crack my knuckles and get started. I know things are going to be heavy on the client-side, but this is a learning opportunity and I want to dive into a solid framework to get me started.
Cool. Angular or Backbone or React or Ember or Vue or Mithril?
Ugh. Okay, forget it. Build process. That’s simple, right? Let’s see… Gulp or Grunt or Brunch or Webpack or Browserify?
Wait, module bundling? Should I use ES6 Modules? Or CommonJS? Or AMD?
Well if I’m using ES6, I’ll need to transpile for sure. Traceur or Babel?
Cool, I’ll just need a client-side router, and an http request library, and a solid data store, and I’m just going to stop because this is ridiculous.
I didn’t know where to start. So I did the dumbest thing I could possibly think of. I rewrote the same thing five times with different approaches and frameworks. I doubt very much that I’m the first person to do this. But I’m almost (almost) glad I did this, because I learned two pretty important things.
- Most frameworks do a pretty good job when you’re doing something simple
- And …
Trying to Pick? Choose Your Metric
How do you figure out what that metric is? For me it’s simple. I let the project point me in the right direction.
I’m working with WordPress, which means I won’t be rendering any JavaScript on the server. And these large file size libraries still put me off a bit. So I made my metric pretty simple. File size. So for me, some good options are things like Backbone, or Vue. Both keep things really lightweight purely in terms of initial download size.
Maybe you’re working on a team, so having strong conventions and solid documentation is important. That way any team member can just dive in. Ember’s probably a good choice here. Angular’s not far behind there.
Maybe you have a team that’s transitioning to the client side from a very functional approach to programming. That’s like, exactly what React is built for. It’s what Automattic did to help their PHP developers transition.
There are a ton of comparison posts out there, but at the end of the day all you’re going to do is agonize over the decision. For me the answer was to find that one principle and let it guide all the decisions that you make. This has the added benefit of connecting up the various bits and pieces of your project very nicely, and will inform decisions you make as you’re building the project.
For me the realization was that you can’t be wrong. You can waste a ton of time. So find your metric. And stick to it.
