On Frameworks

This blog post was written in May 2016. It is included here partially for posterity and partially because it was somewhat responsible for getting me a job. The folks at Traackr were looking to upgrade to a Framework-based approached and liked that I wasn't a zealot about them and thought in a critical way about their use.

A little over a month ago, a coworker linked an article by Sean Fioritto about how daunting it can be to work in Javascript. There are numerous options for package management, testing, and frameworks which can make it feel extremely complicated. As Sean pointed out, if you’re starting to build your application with a framework such as React or Angular, you are over-engineering from the beginning.

I have mixed feelings on this.

On the one hand, he’s not wrong. Introducing a massive framework without knowing the direction of your app or without starting to build anything can mean over-engineering. He suggests first defining the level of complexity that you think you’re application will reach, and using that as a starting point.

In my experience, that’s incredibly difficult to do. The tech world changes rapidly, and from what I have seen, working primarily in education focused on subjects such as foreign languages and finances - People come up with complicated ideas. Whether or not those ideas are made is a whole other story. Aside from scope creep being a possibility, part of web development is never being done developing, and sometimes having to pivot.

Here are some issues to consider when working with a framework.

When do you introduce a framework?

At Vista Higher Learning , we took the “Don’t introduce it until you need it” approach. We had built out the entire application in Javascript / jQuery with a Ruby on Rails backend. It wasn’t doing anything fancy with two-way binding. There were some async ajax calls where things would update real time, but otherwise it was fairly straightforward.

What we were building was a web application primarily for foreign language education in schools. Teachers could assign homework, manage tests, and grade students. Students could do their work, read excerpts from our course books, take tests, among other things.

We were constantly striving for innovation when it came to the various activities. Partly because “just read the book” doesn’t work for foreign languages, but also because... Why stop there when there’s so much you can do? Some of what we had was relatively simple (such as multiple choice, fill in the blank), But other activities required complex implementation. Activities such as listening to recordings and choosing an answer, and students recording themselves and the teacher reviewing it are a couple examples.

At one point we decided to try out using Angular with an overhaul. The activities code was in many ways brittle and we wanted to try some new things from a design perspective, such as giving immediate feedback and transitioning between videos and activities in a seamless one-on-one presentation.

Bringing in Angular for something that we had already spent close to two years writing - even something contained - proved difficult at best. We now had some of the site written in Angular, and some was written in plain Javascript. Aside from those two not playing very nicely together (both the state of Angular at the time as well as our implementation), there was also the problem of “okay, now only the people who know Angular can work on this feature.”

That was a few years ago, and now the idea of bringing in Angular or Ember to a site that has already been established makes my brain sad. Because of the different conventions, you wind up in a situation where perfectly good code has to be rewritten to conform to your Framework’s opinion on how code should be written.

I mentioned that it blocked out some developers from being able to work on Angular, but that went both ways. There were also developers who were unintentionally put into the situation of “okay, you’re the Angular guy now”. They should have been learning javascript when they were only learning Angular and that is I think one of the biggest problems with Frameworks. Even for an experienced developer, what a framework does (because of the inherent complexity) can be perceived as magic if you don’t have the time to learn what it’s doing, how it’s doing it, or why it’s doing it this particular way.

The issue of commitment

These days, Ember and Angular are meant to be complete solutions. If you’re using one, you’re probably using it throughout your entire application.

There’s a staunch belief that it’s better to rely on one Framework rather than manage a several small libraries. At the time of this article, the web application for the Society of Grownups website has 40 Ember plugins installed through NPM, and another 6 through Bower. That’s an absurd number of plugins to be reliant on.

When I left Vista Higher Learning , we hadn’t committed to using Angular throughout the website, because it poised the question: “Do we really want to rewrite all of our javascript to Angular’s conventions?” The code did not necessarily need a refactor. It would be essentially change for change’s sake, which is hard for a business to justify.

I worry about the idea of committing thoroughly because it’s putting enormous faith in one thing. I know that when Angular 2.0 was announced, it was said that they would not provide any information on an upgrade path. Speaking of my own experiences with upgrading from Ember 1.5 to 2.4 over the past six months, I can tell you that it was surprisingly difficult. In either case, unsurprisingly, the more you commit to it, the more you are reliant on it.

That could work if your project has an expected lifetime, but if you’re planning out the next x years, then I think you need to consider the change more than just “Yeah, we use this Framework.” You need to be aware as a team of how the Framework will continue to evolve, what you want to accomplish and how this framework will help you get to that point. In short, if you’re going to commit, you need to commit. Ideally, I’d say you should have a senior-level developer with aspirations of becoming a Principal Developer who will strive to be a core member of the framework’s team. At the very least it should be someone who can peruse the issues, pull requests, and source code for it.

Framework =/= Language

If you are committing half-heartedly to a Framework, you now have devs who don’t know how or why things work. Again, to cite Vista Higher Learning , when we brought in Angular we had split the team into “Devs who know Angular” and “Devs who know Javascript”.

In theory, this works. You have someone who knows the framework and they simultaneously get into the specifics of it while also bringing more people up to speed. What I’ve noticed is that the people who don’t know the framework think that it is magic, and the person who knows the framework is the only person who can work on specific tasks. That person never gets the time/bandwidth to learn more about why it works, or train anyone else for that matter.

You now have a developer who is getting better at a framework rather than a language, while other developers are not improving at all. You can see this in hiring trends, too. People don’t care if you know Javascript as long as you know the particular Framework that they use and the problem is further perpetuated. I could not tell you how many Mid and Senior-level developers I have interviewed in the past two years who could not write standard object constructors and prototypes in Javascript.

Problem-Solving or...not?

The main question, which Sean touched on (and I don’t think enough people ask) is “Do you even need a framework?” What I’d say is that all of them - React, Ember, Angular, Backbone - are all written in Javascript. You can accomplish the same results without them, thereby gaining a more thorough understanding, which makes you a better developer.

Earlier today I was in a meeting discussing some projects coming up in the next few months, where an Ember developer asked, “should we be using Ember for new features?” After finishing a large rewrite and relaunch of the website, the last month was spent dealing with bugs, many of which had been caused by our use of Ember. It’s not to say that Ember itself is buggy or that we’re writing bad code. But it does introduce a lot of complexity, and it is incredibly rare for us to be doing something that couldn’t be done with the simplicity of the server serving HTML and the page having minimal javascript.

There is a widespread belief that the single-page application approach provided by Angular or Ember offers a better user experience, but that is not necessarily true. Whether you’re using a framework or not, the experience of your users will only be as good as what your interactive designer created.

For some of us, frameworks are a “given” - and I disagree with that approach, having made those mistakes in the past. When I started work on the application for Watch the Skies, I remember having a conversation with the other developer (as there were only two of us at the time) about which framework we’d use. I ended up feeling disappointed that we went with Angular (I was hoping it would be a good excuse to play around with React), when in reality, it wasn’t something we even needed.

I was talking about this with the incredibly talented Alicia Sedlock , and she said to me: “When I ask people why they like React, they list features of React. And I follow with ‘So what problem do you have that React fixes?’ And to this day I haven’t gotten a straight answer.”

Problem Creation

So, we’ve talked about how there can be inconsistencies in your code base, which isn’t a thing that I like. We’ve talked about dividing your team by language, which isn’t a thing that you should like. Another issue to consider when building any kind of website / web application is what you’ll have for mobile support.

Most of these frameworks are big. It’s understandable, in a way. Regardless of how much you use them for, they have multiple complicated features and therefore contain a lot of code. But how much of it is code you don’t actually need? 30%? 70%? How much value is enough to justify having it?

I don’t want to simply repeat someone else, so go read Henrik Joreteg’s article about this. It’s enlightening. Something he said that really sticks out to me: “Tools are merely a means to an end.”

These frameworks are seen as one size fits all solutions but they aren’t. There is a lack of proper planning and architecture that goes in hand with slapping something together with an off-the-shelf framework. I feel similarly about the Twitter library “Bootstrap”. It’s absolutely great for Prototyping, but it has absolutely no place on a production website (You don’t have to check: Yes, the Society of Grownups site uses Bootstrap).

But honestly, that’s my point. It’s a tool that was introduced at some point that we are now reliant on more than we ought to be. Tools like this are meant to make our jobs easier, not more difficult. Sometimes they introduce bigger problems and sometimes we don’t know that will happen. But we learn from that, and we do what we can to make it work in the meantime, while also trying to improve for the next time.

Is Ember a bad framework? I don’t think so. Would I use it again? Maybe. I like writing it, I like some of what it does. But my decision would depend entirely on the product. Ember has a lot of great uses, as does Angular, as does React. But their use case is not, and should not be, “I am making a website.”

My portfolio website is (currently) built with Angular and PHP (in a project that I called Phangular, or just Phang). It was a neat little side project at one time, and now I just think, “Wow, this is absurdly complicated for what I actually need.”

It’s a simple truth that most websites have not been around long enough to justify the amount of technical debt they have. I just spent several months on a rewrite for work to help minimise ours and we still have a long way to go. There are tools that we have to reevaluate in order to see if they’re the right ones for us. It’s not just about building the right things - it’s about building them right .