VentureBeat
Developers: Try not to overdose on new frameworks
By: Zoe Knopf
I first noticed it a couple years ago when a coworker and I were working on a project together with some outside vendors. I try to keep myself informed of what’s going on in the web-tech world, but suddenly there were frameworks and tools in this new project that I was completely unfamiliar with. And not just one, but several. In the same project!
I had heard whispers of new front-end-heavy tech-stacks that used node.js for compiling, but this was the first time I had seen them in the wild. This led to ongoing discussions with my coworker about what was worth learning, how to stay informed and competitive, how much of this type of thing is too much, etc.
After building websites for years, I looked up and realized the pace of new tools and frameworks to learn had accelerated far beyond what I had seen when I started in the industry. I suddenly had a sneaking worry in the back of my mind that I was becoming outdated as a developer, and I was way too young for that.
Today’s front-end development industry has a lot of cool stuff going on: streamlined development workflows where front-end developers are front and center; frameworks that make dynamic sites easier to create than ever before; the ongoing evolution of ECMAScript, bringing new and exciting capabilities to client-side scripting. People are experimenting, making new tools and frameworks every day, trying to improve the world of programming for themselves and their peers. It’s a great time to be a front-end focused developer. There’s a ton of enthusiasm and passion. However, with this flood of new and shiny things, it can be easy to feel overwhelmed or to get swept away in a tidal wave of hype.
Projects today have dependency lists that read like alphabet soup. The sheer number of frameworks and tools packed into a single project can be out of control. This architectural complexity can be a barrier to easy maintenance and intimidating to new project members. The lengthy README file accompanying that first eye-opening project ― just to get the project compiling and running ― had dozens of steps, multiple package managers (npm, jspm, bower, composer) to install and configure, and multiple task runners (gulp, grunt) to set up as well. All this before a single line of code was touched. Even after becoming familiar with the tools themselves, each additional framework adds more learning time, setup time, and troubleshooting time when something goes wrong. There is general consensus that brevity in our code is a good thing, so why don’t we feel the same about brevity in our architecture?
These frameworks and front-end tools are not spun from magic. They were created by other developers, just like you or me, using mostly the same underlying technologies we have probably used in our own projects. These frameworks were born because a developer facing a challenge on a project saw a path to solve that challenge that they then genericized and presented to the world — helping other people solve the same challenges with more speed and ease. Many times, these projects accomplish their goals and go on to help other developers improve their projects or workflows.
There’s a key factor here, though; tools and frameworks are only helpful if they are actually helping you. Spending all your time wrestling an ill-suited framework into submission is a bigger waste of time than writing clean, custom code that accomplishes your goals. If you’re trying to fit a square framework into a round hole, you are only asking for frustration. People are seduced by the alluring dynamism promised by frameworks like Angular, Ember, and their ilk. But it matters what you’re making. Not everything on the web needs to be a single-page-app. Wrapping a static informational site in Angular might get you some street cred, but it could also take you a lot longer than building that site the “old fashioned way” and lead to a bloated code-base. If that static site happens to have a lot of complex animations, Angular might end up leaving you with a monster headache, and you might be better suited dropping Angular and, if you must, using a framework purpose-built for animation, like GreenSock.
The majority of today’s front-end frameworks are built with JavaScript, a language that has been a cornerstone of interactive front-end development for over a decade. In order to get the most out of any JavaScript-based framework, developers must understand JavaScript itself. I would rather hire a developer with in-depth knowledge of JavaScript, than one who is versed in Framework X, Y or Z. Budgets, fads, client needs, and desires can all be fickle. You may evangelize your chosen tech stack, but the truth is, you will probably end up working in many different sets of frameworks and tools over time. If you put in the time to learn how frameworks work under the hood, you will be well-prepared for whatever new thing comes your way.
Possibly the most daunting part of this deluge of front-end frameworks is the difficult prospect of keeping up. How do you know what is worth learning and what will be a flash in the pan? How could I quiet that little voice telling me I was falling behind so I could concentrate on improving as a developer instead of being overwhelmed? First of all, I’m here to assure you that your worth as a developer is not measured in how many bleeding-edge frameworks you’re familiar with. When people are passionate about coding and they find something that works for them, they tend to think everyone should be using it, but your credibility does not automatically go out the window if you haven’t heard of your coworker’s favorite framework. Being a developer means being in a constant state of learning. The ability to admit you don’t know it all and to graciously learn from your peers and others in the community might be the single most important trait of a great developer. These days there is so much out there to choose from.The fact is that programming style and personal opinion play a huge role in what architects and developers decide to include in their projects. In the scramble to be cool, we can lose sight of the actual goals of the things we are creating. Adding in a new framework, no matter how buzzworthy, does not automatically make your project better.
I want to be clear, I’m not telling you to never pick up a new framework or try out new tools. Experimentation, research, curiosity—these are pillars of a good development career and the only way to keep yourself from stagnating. I’m proposing a tempered view where we eschew hype for common sense. No single front-end framework is going to serve you better than knowing the ins and outs of the JavaScript language. And being able to separate hype from substance will only make your projects better in the long run.
So what’s really important? I would argue that the same things are important now, in today’s World Wide Web Wild Wild West, as have been important to good application development all along. Great, thoughtful user experience design; stable, clean, maintainable code; an understanding of how to pick the right technologies for your project and how to harness the particular strengths of those tools; and a well-rounded and in-depth understanding of the underlying technologies of your frameworks.
It’s all about context. If you’re developing your own website in your own free time, try anything and everything that interests you! If you are working in a professional developer capacity with budgets, clients, and users to satisfy, make sure you’re making informed judgements that others on your development team can get behind. Make sure those judgements are rooted in the goals of the site or app that you are producing and not based on what’s cool at the moment.
I personally am re-evaluating where the line is on this topic every day. I think the trick is to ride the edge between a stodgy developer who refuses to learn anything new and a starry-eyed coder who is hungry for anything and everything upcoming and shiny. Keep a curious and critical mind and choose your frameworks with care.
Zoe Knopf is a senior developer at design experience agency, Duffy. She has been using her design background to develop apps for the web and mobile for nearly a decade.
