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.
1. When do you introduce a framework?
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.
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.
2. 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.
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.
3. Framework =/= Language
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.
4. Problem-Solving or…not?
“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.” - Alicia Sedlock
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.”
5. 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.