I’ve always had this joke with my friends (only the geek ones, of course :) in which I would say that frontend developers are in fact “framework developers”, because, when faced with the challenge of building a new system, their way of developing software is sticking together several frameworks in an application pastiche and keep on adding new frameworks for every piece of functionality that they need.
Now let me say that I’m a big fan of code reuse and reusability principles. I have a github repository where I share lots of open source libraries, controls and frameworks. And I’m a consumer myself of open source software, libraries, pods and frameworks, but only when they are truly needed. I think that, when done right, reusability helps the whole developer community.
But sometimes the large availability of frameworks and libraries mean that many lazy developers would not care about evaluating whether all these pieces of software are appropriate for the systems they want to build, they will just get them and use them. Do you need some dynamic frontend interface? Just plug Angular. Do you need a backend? no problem, Parse is there (well, Parse is actually closing down, but there are alternatives). Do you want to deploy a mobile App? Use PhoneGap, Titanium or Cordova. After all, they are there, they are easy to setup, un-opinionated, scalable, won’t affect the rest of your system, and will always be maintained and up-to-date, right? Let’s not reinvent the wheel, they say time after time…
Well, let me tell you, that’s not the case. Indeed, half of the job offers I get are from a startup or company that started developing their product in one / several of that frameworks and now are facing some serious scalability problems, so they need to rewrite all of their code from scratch if they want to survive. That’s harsh, and it’s happening to companies and startups all around the world, day after day:
- easy of use: while it’s true that many frameworks out there will allow you to start building something fast, most of them are really good for simple tasks or simple projects, but limit your capacity of performing complex tasks or doing things outside the “typical use case scenarios”. This means a lot of time spent later in trying to adapt that “easy to use” framework to your needs.
- un-opinionated: there’s no such thing as an “un-opinionated” framework. Most (and I mean the vast majority) of frontend framework out there are opinionated in one way of another. They all will (to a greater or lesser extent) alter the way you structure your projects, write code or relate parts of the project together.
- scalable: this is the main problem with all those frameworks. The frontend-backend frameworks (like Cordova, PhoneGap or Titanium) are web-based (“multi-platform!!!”, they affirm triumphantly), and so you will find multiple issues like performance, operations that need to access the hardware of the device, advanced functionality… most of my work in re-building native apps for companies comes from this point alone.
- dependency: when you are using a framework for a long-time project, you are tied to that framework. If the framework changes significantly, modifies its interface (so it’s no longer backward compatible), or is discontinued, this means refactoring your code, choosing another framework that can substitute the old one, or patching that now obsolete, legacy piece of software for as long as your project last. Multiply this possibility by the number of frameworks you are using, and you may have a problem at hand. Take Angular as an example. One of the most used frontend/backend framework solutions out there, that recently outraged its whole community while completely changing its API and interface. I know some projects where the developers have been left with a difficult decision on whether to continue using Angular 1 or do a tedious update to Angular 2 nobody wanted to get involved in.
As a member of Google Campus Madrid, the Tetuan Valley accelerator, and the TechHub community, I’m surrounded by some of the most innovative and awe-inspiring startups in the ecosystem, and yet I’m seeing the same mistakes again and again. A tech startup is supposed to be scalable, but the reality is that most of these startups are relying on these frameworks that immerse them into a heavy technical debt scenario, that either means investing a lot of time and effort in the future to be able to adapt to a ever growing number of users, or (in the worst cases) supposes an obstacle they cannot surpass. You’d get surprised to know how little startups have a native iOS App, for example.
I understand that it’s hard to build a startup (I know because I have done it myself), and that sometimes you don’t have native app developers in your team, or backend experts, and the CTO probably is not even a developer, and I know it’s easy to reuse code, and hard to code your own, so the use of frameworks and fast solutions appears as a fast and appropriate solution.
But I know for sure that, in the long run, you will need to do things right. Your startup won’t be scalable and won’t ultimately succeed if you don’t build a good backend, invest time, effort and money in building quality, native apps and get developers that know what they are doing to build a good, optimized and customized frontend adapted to your users needs.
This is not limited to frontend/backend ready solutions like Cordova or PhoneGap. Earlier this year, I was asked to collaborate in a startup that needed it’s iOS App to be rebuilt (probably from scratch). While having a look at the code, I realized that it had 26 Cocoa pods included in the system. As an example, for doing a simple set of GET/POST requests to a backend API, the developer had included Alamofire when all he needed was probably a method with some NSURLSession magic… Now don’t get me wrong. I think Alamofire is an awesome library, and I have used it sometimes, but this is an example of a lazy developer that, when confronted with a need or problem in the project, would just look on Google for a cocoapod to solve it, instead of stopping for a minute to think: “how can I solve this”.
And we are not only developers, we are software engineers. Our job is to solve problems, and find new ways of doing things, innovative, better, more optimized ways of solving these problems. I think we are loosing some of this capacity. I love to share code, and I love to reuse quality code, but I also love to solve problems, and I love doing it in a scalable, optimized, and (why not) personal way.
… So yeah, reinvent the wheel.