The Personal Blog of Todd Sharp

Which JavaScript Framework Should I Use?

Posted By: Todd Sharp on 9/5/2017 12:05 GMT
Tagged: Misc

I was having a conversation this morning with a coworker this morning about front end frameworks when he asked me the age old "trap" question for developers:  

"Which is your favorite?"  

Oddly enough, I was thinking about this very topic last night so I already knew exactly what I was going to say.  

"Actually, I mostly prefer good old HTML", I replied.  

It was impossible to decipher his reaction:


So I guess I'm the "old guy" now.  The fact is, that shiny framework you're using may be nice and all, but it could be unnecessary.  Before I go on, let me give the same disclaimer I gave him:  I don't have anything against Angular, React, Vue and whatever Fizzbuzz framework comes next when they're used properly.  The problem I have is that many times they're not used properly.  You shouldn't use a machete to trim some herbs from your garden (at the same time you shouldn't use scissors to mow your lawn).  

We're in the midst of an amazing time as web developers.  We have so many choices when it comes to the tools we use thanks to the success of some of the major (and even minor) players in this business.  Twitter, Facebook, Google (and so many others) have open sourced some of their most powerful tools and made them available to everyone (in most cases - licence terms apply, obviously).  The best part of this is that we can take comfort in knowing that these tools work and work well because these companies are using them themselves.  The real challenge to us as developers is knowing when and where to use these frameworks.  My experience is biased (due to projects/clients that I work on/for) but for most CRUD based applications HTML is a perfectly good tool that does the job.  And we know it works in Interfox 23 and pretty much every other browser out there because it's just HTML.  Of course, even the simplest CRUD application could have requirements for things that require "something more" -- maybe a simple email client in the admin, or a project tracker.  And in those cases, I'm glad to reach for something that makes remote data retrieval and data binding easy.  Lately, my choice has been Angular 1.x, but I've looked at Rivets.JS and even Vue.JS and they all seem to fit the bill.   It's just smart business to use the right tool for the job and our trade is no exception.  Use what makes sense, when it makes sense and you'll make your client happy.  Which at the end of the day is really all that matters.

And yes, there is a place for the "kitchen-sink-one-page-app".  I've been working on one of those lately too and it uses Angular 4 which I'm perfectly OK with.  I'm still getting used to it and the big departure from the Angular 1.x way of doing things (advice:  don't even associate the two frameworks in your head - just treat them as totally separate frameworks) but it's growing on me.  As I said earlier I've also looked at a few other frameworks lately to keep up with what is available and the major ones (React, Angular, Vue) all tend to do things fairly similar to each other so I'm not sure which one is my "favorite" but if I had to chose one I'd pick the one that was the most intuitive to me.  My biggest test for a framework is whether I can simply guess how to do something that I'm not sure about and have it be pretty darn close (or exactly) what the actual solution is.  Intuitive frameworks are the easiest to learn.  Unfortunately "intuitive" is a pretty subjective factor.  What's intuitive to me could be completely counter-intuitive to you.  The second most important factor in my opinion is the developer community surrounding a framework.  Are there active forums that I can use to find answers when I get stuck?  Are there dedicated conferences available (or heavy topic coverage at non-dedicated conferences) that I can attend to learn more?  Thirdly, the framework has to be well documented.  If I can't make it through the quick start without Googling something that you didn't explain well enough then I'm not going to be too happy.  Performance is the overarching factor that trumps all - if a framework is slow and presents a poor user experience then it's totally worthless.

Thing is, those are all my criteria for choosing a framework and we all have different criteria so it's impossible for me to tell you what criteria you should use (except performance - never sacrifice performance for any reason).  Talk to more experienced developers around you and ask them what there choice is and why and develop your own list.  Don't simply choose a framework because it's the "next big thing" or you'll end up with dealing with the "fire and motion" problem and that's never a good thing.

Image by jplenio from Pixabay

Related Posts

The Trials And Tribulations of Creating An SDK - Part 1

The Trials And Tribulations of Creating An SDK - Part 1

I’d like to tell you a story. It’s an inspiring tale. One of mistakes and perseverance, but full of learning and growth. It’s the epic about my adventures...

Conference Review - Connect.Tech 2017

Conference Review - Connect.Tech 2017

I recently had the opportunity to attend Connect.Tech 2017 and wanted to write up a quick review of the event.  I'll start off by saying this...

Hello, World

Hello, World

It's been quite a while since I've blogged.  For a while there it seemed like no one really followed blogs anymore, but I decided that it's a good...

Note: Comments are currently closed on this blog. Disqus is simply too bloated to justify its use with the low volume of comments on this blog. Please visit my contact page if you have something to say!