Paralyzed by Choice in Front-end Development


By Brian Rinaldi

I’m starting to wonder if the front-end development community has begun to turn a corner. Lately, I’ve seen what could be described as a backlash against the ever lengthening list of tools, frameworks and libraries. There seems to be a growing consensus around the idea that something needs to change, though, admittedly, without a clear picture of how to change it.

Trying to change it, though, smells a bit like stifling innovation – which we certainly don’t want to do. I always tell my kids that you can’t control what other people do, you can only control how you react to it. So, along those lines, perhaps the answer isn’t so much changing the behavior of the community but rather how we respond to those behaviors. In this article, I want to discuss some ideas for overcoming the “paradox of choice” in front-end development.

Something Changed

This is a topic I’ve hit on myself for a while. When I first refocused on front-end web development using HTML, CSS and JavaScript close to 3 years ago after spending a few years in the world of Flash and Flex, I was initially overwhelmed at the number of framework options. Looking back, that list was laughably small compared to what it is today. I even touched on this last year in a session for Ignite at the O’Reilly Fluent conference and then again last September for an article on this site. The message seemed to resonate but I also didn’t get the sense that people thought it was as deep an issue as I did.

Things seem to have changed. For example, you have leaders within the community such as Rey Bango speaking about The Learning Conundrum and the costs both personally and professionally of trying to stay on the “hamster wheel” of new tools. Louis Lazaris, who, perhaps not coincidentally, runs Web Tools Weekly, said that we are “drowning in tools in the web development industry.” Jeffrey Way wondered “why do we continue learning new techniques, if those same techniques will invariably become out-dated within a couple years or so?” Addy Osmani wrote about “front end choice paralysis.” As a commenter on Facebook asked when I recently posted about a new tool, “isn’t it too much?”

Sometimes this feedback comes in response to some new library being released. For instance, there was a lot of negative blowback over some of the recent build tools for JavaScript. While this reaction is understandable, it also could have the side effect of stifling legitimate and worthwhile innovation. What if the tool we’ve all been waiting for simply doesn’t get made or never gets publicly released because it’s author fears getting flamed over creating yet another framework.

Filter Out the Noise

One of the biggest difficulties front-end developers face can be deciding what is worth paying attention to and what isn’t. If you follow social media, Hacker News, EchoJS or even a handful of blogs, it can be hard to decipher the tools or frameworks that are deserving of investigation versus those that maybe just aren’t there yet. Fortunately, there are a lot of people out there in the community that are doing the work of helping you filter this down.

There are no shortage of roundups and newsletters that you can rely upon to at least get the list to something manageable. Many of these also have a specific focus so that you can even choose only the ones most relevant to you. Some even focus on a particular framework or tool, which can further filter your reading list. Here is a by-no-means-complete list of the ones I am aware of grouped, as best I can, by their primary focus:

Web Design Focused

Collective by CoDrops
CSS Weekly
Web Design Weekly
Responsive Design Weekly
The Sass Way
Sass News

Web Development Focused

Web Standards Library Update by Flippin’ Awesome
Best of JavaScript, HTML & CSS by Flippin’ Awesome
HTML5 Weekly
JavaScript Weekly
Node Weekly
Web Tools Weekly
ng-newsletter (AngularJS)
Ember Weekly
Today’s Readings by Aaron T. Grogg

My suggestion, only subscribe to the ones that will be particularly relevant to you. You don’t want to replace one batch of noise for another. Also, learn to skim them and pick out the things that stick out as either potentially important to your work or something you find personally interesting. That is an important distinction to make, which leads me to my next suggestion.

Distinguish Between Useful for Work vs. Fun for Experimentation

If you do a good job of distinguishing those projects that are actually worth investigating for your job versus those that just seem potentially cool and fun to play with, you can whittle down the list of what you need to focus on.

Of course, what is suitable for your job is dependent on the type of job you have. For example, a consultant may have a longer list of tools or frameworks to learn while an enterprise developer may only be allowed to use projects that have been formally approved. There’s obviously a wide spectrum in between.

The point here is that even though something looks new and interesting doesn’t mean it is worth investigating deeply for work purposes. I’d suggest sticking only to those tools and projects that have an established community, proven track record and, potentially, some availability of support when choosing something to use for work. Right there, that eliminates an enormous amount of noise.

But that what about all the cool tools, libraries and frameworks? When do you get to have some fun?

Remember What You Love About Programming – Experiment

Being a developer is a job of choice. I don’t think I have ever met anyone who became a developer out of a lack of other options – they did it because they love to design or code. Nonetheless, I often hear things along the lines of “work doesn’t give me time to experiment and learn.” The question I have is, since when does work dictate what you can do outside the office?

We all lead busy lives. However, I bet you became a developer because you enjoyed it. But somewhere along the line everything related to development got lumped into the “work” bucket. This meant that if it didn’t happen at the office, it won’t happen. Coding for fun became a thing of the past.

Even if work doesn’t give you experimentation time, it is important that you find the time to experiment. It may benefit your career and will definitely will help you remember what was fun about being a developer.

Setting Goals for Experimentation

Even once you’re determined to find time for experimentation whether it is at work or outside work, one of the toughest things to do is to come up with an end goal for your experiment. Personally, I find that setting large goals like building a complete web application or mobile app can make the whole process seem daunting. I always find that setting a smaller but achievable goal works better.

I generally start by adding a tool or library I find potentially interesting to look at for fun to a bookmarks folder (I call mine, “potential topics”). Once you’ve identified what you want to try, the next step is to set a goal and a deadline. Here are some things you can do:

  • Speak:
    • Agree to present the tool to a user group;
    • Set a “brown bag” presentation to share with your colleagues;
    • Submit a topic about the tool to a relevant conference.
  • Write:
    • Write a tutorial on your own blog;
    • Contribute an article to a site (like this one!);
    • Contribute to the tool or framework’s documentation.

Any one of these things will not only give you the opportunity to experiment with a goal and deadline, but will be the kind of thing that can help build your reputation in the community and improve your resume.

Avoid Being Overwhelmed

I think if we can filter out the noise, determine what’s worth investigating for work versus experimentation and, finally, find time and set goals for experimentation, it can be much easier to avoid feeling overwhelmed by the flow of new tools, libraries and frameworks. We can change a reaction of anger and frustration into a positive and fun opportunity to find things worth learning and having fun doing so – all while boosting our resume.

I’d love to hear people’s thoughts or other strategies. Feel free to share in the comments.

35 thoughts on “Paralyzed by Choice in Front-end Development”

  1. One thing I think that you have overlooked is this: hipsters. It’s no secret that hipsters have gotten very involved with web development over the last few years. This is especially the case in Silicon Valley. And if there’s one thing that hipsters hate more than anything else, it’s liking something that somebody else likes. So in their never-ending quest to find and promote stuff that is obscure yet “trendy”, they started creating their own JavaScript frameworks and CSS/HTML5 bootstrap packages.

    They don’t care that the quality of these tools is very low. They don’t care if it causes their creations to be harder to maintain. They don’t care if it becomes difficult to learn all of these different frameworks. All of that is irrelevant to them. They care only about trendiness and obscurity.

    • I didn’t get into the motivations of why people create new tools and frameworks. Rather I focused on how I can deal with the influx because I can’t change what other people do.

      • Brian,

        Totally agree! I read the same thing somewhere else and the author suggested people should work to improve what is out there instead of trying to “solve” some problem. I have seen so many projects that could be integrated and really create some awesome stuff.

    • Exactly. The recent influx of frameworks seems to reek of “solutions looking for a problem”, some of which are seemingly created for selfish “look what I can do” reasons. Although great for the framework creators’ careers, this is unsettling for the industry as a whole, because: When hiring managers with little technical expertise hear of these frameworks, said manager will insist all of them are necessary skills for a candidate. This leads to the “hamster wheel syndrome”, where developers have to learn various obscure frameworks just to stay relevant in the market (and therefore employed).

    • Haha 🙂 So your saying that people that dress in a certain way, perhaps brew beer or whatever hipsters do, have a different gene pool or something? Obviously they are driven by the same kind of motivation like everybody else.

      You can’t expect every new idea/library to reach a mature state. If its good enough it will reach attention and hopefully be properly maintained and further developed. If not, the author probably learned tons of stuff when trying to create his own library, something he will take on board when creating code in the future.

      To argue for a pause in innovation at the stage where web development is at the moment is just silly. Sure there are some decent libraries out there, but to say that “Hey, look at Angular! This is what the world of developers came up with 2012, web development can’t get any better!” is obviously laughable.

      I say, just keep the new libraries coming and let the best ones flourish and the bad ones be quietly forgotten.

  2. Avoid also to be impressed. A lot of the css “frameworks” are just attempts. They are leaky abstractions, that bring nothing. Better no abstraction than a leaky one. So:
    – Try to work with em and rem, instead of using px2em().
    – Try using mixins and semantical css, instead of a “grid framework” that is going to uglify your markup and introduce a hard dependency.
    No need to be cool, we know that since the “rounded corner era” : all of those script, (ALL) were wrong, and would just produce damage in some way.
    Use carefully your free time, to learn stuff that will be useful in 3, 5 years. That eliminates a lot of possible choices.
    – Prefer experience against stuff claimed in blogs and twitter. Most of the opinions expressed on framework x,y are just uninformed, or not informed beyond the beginner’s tutorial.

    Those are some of my guidelines

  3. It’s a double-edged sword. Yes, I agree that the overwhelming choices does cause “paralysis” like staring at a buffet table. But it does allow someone to look at the source code and learn a new technique. I don’t think it really matters to a good programmers how many tools are available as long as you understand what each of the tool is meant to be used for.

    Also, we are now at a stage where notoriety is becoming important. I can’t blame anyone for creating something to show off their l33t skillz. 😉

  4. “Being a developer is a job of choice. I don’t think I have ever met anyone who became a developer out of a lack of other options – they did it because they love to design or code.”

    Yes and no. Programming has changed drastically over the past 10, 20, 30 years. Someone who got into programming for what it was in 1990 may not like what it has become today.

    As much as we like to say it’s easy to change jobs at any point in one’s life, it’s not always as easy as we’d like. Momentum is a powerful force. It’s a tough decision to give up a developer’s salary (and maybe all salary, for a while, while you go back to school) to enter another field where you think you might be happier. I know lots of developers who *used* to love programming.

    “Even if work doesn’t give you experimentation time, it is important that you find the time to experiment. It may benefit your career and will definitely will help you remember what was fun about being a developer.”

    For someone who isn’t already having fun at work, then doing fun things outside of work will just serve to reinforce that divide. If you’re making money working on a bad Java project, and you use your spare time to learn Lisp, that will be fun, but it will also teach you a bunch of programming techniques that you simply can’t use in Java, and your coworkers will hate you if you try. It’s not going to make work fun. It’s going to remind you that the fun part of being a developer is the part you can’t get paid for.

    It’s like someone who works as a mechanic because they like cars, but is disillusioned because all they do now is oil changes on minivans. You can tell them to go do a track day to rekindle their love for cars, but (unless they’re the top 1% of 1% of 1% of racing drivers in the world) they’re never going to make a penny doing that, and it’s not going to make them excited to go into the shop early Monday morning to jack up yet another beige Toyota Sienna.

    • I think the first half of your comment only proves my point. At some point they liked it, even if they don’t think they like it anymore. The specifics of an individual job may have changes but whatever it was they liked about programming probably hasn’t (even if the languages have).

      The second half of your of your comment seems to imagine a world where the only opportunity is the current job you are in but not enjoying. Working on that side project to learn may open up other opportunities – perhaps elsewhere or perhaps even in your existing company. And I really don’t see what your coworkers feelings about the code you write outside of work hours has anything to do with it.

      A bad job can make you feel trapped and can even kill your self esteem. Just accepting your status quo certainly isn’t going to make it better.

    • “If you’re making money working on a bad Java project, and you use your spare time to learn Lisp, that will be fun, but it will also teach you a bunch of programming techniques that you simply can’t use in Java”

      Learning other languages makes you a better programmer in all of them. Learning Java made me a better C++ developer, learning Ruby made me a better Java developer.

      They are just tools. Learning different techniques and syntax gives you a bigger tool box. No, you can’t use them all in all languages but being a good programmer means knowing when to use the right tool for the job.

  5. Have you seen any articles that help you decide which framework works best for which project? They each have their strengths right? Should I use Meteor.js or Node or Angular or Backbone or Rails….the list goes on. Thanks!

  6. Pick the right tools for the job.

    I’ll use grunt and automation as an example. I’ve seen a number of developers questioning why on earth they should bother with installing grunt, creating config files, running command line compile tools and automating processes, when the ‘old’ method seems so much quicker.

    It usually transpires that these developers are working on very simple websites – news/blog/about – and unless they are producing a great deal of these websites, using a framework, clearly grunt isn’t for them.

    Where grunt shines, is for complex web projects being delivered by a large team – web applications for example.
    It can also shine to bootstrap and maintain projects which share a common codebase or framework.

    It’s a clear case of picking the right tool/s for the job, the problem is, finding out which tools *are* the right ones!

    Another very important, but often overlooked aspect of web development – *learn the basics first!*
    If you can code lean & efficient HTML, CSS & JS it really doesn’t matter *what* tools or libraries you use.
    You can grab the most basic of text editors and start creating. The tools and libraries are a bonus.

    If you can’t code the basics, no amount of tools and libraries are going to help you. I’m seeing this time & time again, where new developers are leaning on, for instance, Sass & Compass, without having a clue how to write effective CSS.

  7. Also, when selecting frameworks you want to try out, it’s a good idea to check out the authors (their experience and stuff) to see if they know what they’re doing 😀

  8. I agree with most of your points but I think there may be something more at play: Contributing to open source projects has become a form of work experience that some firms value and encourage more than others – particularly for recent graduates and others lacking actual paid experience. It’s not to hard imagine a pecking order (or rank striving, really) among those who want to elevate their marketability by pointing to some tool they’ve ‘authored’ and can show that others are actually using.

    There’s nothing inherently wrong with such endeavors but, like many things in life, software is not immune to the ‘90% rule’.

    I’ve been at this game since the 80’s and language wars, dueling platforms, and transient technologies are nothing new to me. This ‘community’ you speak of was once defined mostly by the ‘Dr. Dobb’s’ and ‘C User Group’ subscriber lists. What’s different for sure is the accelleration and amplification of information we’re expected to absorb.

  9. I think a lot of these frameworks are the result of people just wanting to “make it”, or be a “Known Guy/Gal”, or The DHH Effect. DHH made a framework, marketed the hell out of it (yes), co-founded a company and is now a rich/famous coding rock star.

    Every self help book anywhere says, “Study the role-model you want to be, and do what they do”., and with that you have everyone & their brother writing some sort of framework, and let’s admit it, coding allows for this field of endeavor to be virtually unlimited.

    I think this effect paired with the “Whatever you can do, I can do better” mentality has also fostered out-of-control framework proliferation. Who hasn’t gotten in a conversation, and tried to endlessly one-up the other guy/gal with (certainly barely peripheral) knowledge of some new gadget/widget/framework/language/editor/NoSQLDB/PostgresPlugin/JSONViewer/RubyGem… well, you get it.

    The question is What Happens Next? Industries go through this sort of Innovation Tsunami at the beginning of their lives like clockwork. A list of defunct auto companies is hundreds long:

    Remember the Ajax? Yes, before it did background HTTP requests, it made cars, somehow.

    TV makers? Yes, now there are only a few, but there used to be hundreds:

    Today, we have medical specialists, because there is simply no way one person could treat even a small subset of the disease spectrum, it’s just too overwhelming. And so it will go with programming, we will all be specialists. My only advice is Do Not Generalize. Besides being impossible, you will become a jack of All Trades and A Master of None and then irrelevant. Would you ever go to a General Practitioner when a Specialist is available? Even at a higher price, the answer is usually No.

    At some point, as always, many of these frameworks will be abandoned, because their costs do not justify their benefits, just like anything. At some point, as there always is, there will be a consolidation of all these coding fiefdoms. There will always be the churn of innovation (Facebook runs over MySpace…), but the current blizzard of frameworks falling on us from all corners seems like it has to end… almost certainly it’s slowing will coincide with a Bubble bursting.

  10. And I came here from the “This Week In HTML5” newsletter, and one of the other articles is:

    22 HTML5 Game Engines: Find Which is Right For You

    Seriously? 22?
    And you can repeat this same state of affairs for virtually every other micro-coding niche… there are hundreds! Paralyzed by choice, indeed. I could listen to the elevator pitch for a framework a minute, and I don’t think I could listen to all of them at the current rate of production.

    If you don’t specialize, you will drown in this. Stop trying to One-Up your buddies, and do more with less. You can’t overpower a tsunami. Don’t be a Generalist. Specialize or Die.

  11. Great article. Although I understand there’s no simple answer to the question, it would be helpful to have some guidance on where to start. I’ve been around quite a while (late 70’s). Approaching the web framework and development fire hose, let along drinking from it, has become nearly impossible. Balancing long work hours and family make experimentation time a precious resource. Even trying to narrow the search doesn’t help much. I’ve tried looking into mobile HTML5 frameworks that provide local storage and came up with so many of them I can’t figure out how to narrow it down.

  12. Recently saw a nice simple tool sharing a single CSS file; It required bower and a whole chain of tools and had me scratching my head, when did this become normal.

    I feel – like few maybe, burt out enough at work, never mind getting home to find the cutting edge of the industry is even more out of sigh in a sea of new tool. Occasionally I try and start a new project at home and end up spending most of the time setting up and familiarising a new set of tools which toped this months “22 dev tool I can believe your not using right now”, and the goal gets lost.

    Ultimately you point of it being us that has to change our reaction I think sums it up for me.

  13. Front end development tools or frameworks pop up every now and then. I have subscribed just to a small fraction of your e-newsletter list and yet I find myself already overwhelmed by the sheer amount of new tools introduced by them. It seems that if I were offline for a week, I would have lost my orientation in the sea of development tools. It is possible that more time is spent on learning new tools than creating great things.

  14. I agree with what your getting at “avoid being overwhelmed” its key to find your focus and stop trying to read everything and learn everything. Know your strengths and become the best that you can be in your focused fields.

  15. Hi,

    I help run a weekly newsletter that curates articles, videos, tutorials etc for frontend developers facing exactly what you’re talking about. Would love for you to check us out and to be included in your list of resources if you like what you see. We created Fresh Brewed Frontend precisely because it was getting overwhelming just to keep up with the reading.


Comments are closed.