Why I Stopped Using Your Favorite Framework and Started Using My Favorite Framework
First, let me start with an inspirational image that will invoke a spark in people’s minds (and their bandwidth budget).
I had a Large Application that I’ve started writing in Your Favorite Framework back when it was in an early version and back when I had no idea what I was doing, having just decided to try building something for the first time using a framework.
About it being a Large Application, you’ll just have to trust me on that one, given that I’ll never really explain what the application is about (it’s confidential because of policy of a Large Company I work in). Since I’ve built it with my large team for a very ambitious purpose, there’s no other adjective that fits it other than large.
Then I made a very mature decision, even though a lot of developers who are more experienced than I am have suggested otherwise: I decided to rewrite my application from scratch using a different set of tools. And I’m going to tell you about that experience here.
What I did first was do a Google search of “Your Favorite Framework vs My Favorite Framework” and what I have seen is that there is about the same amount of articles favoring each of those. However, it was very obvious that people who preach Your Favorite Framework have no idea what they are talking about — they are those kinds of developers that write articles without doing proper research (which I’m trying to fix here because I’m not of their kind).
Then I assembled my large team and told them about my decision. They were very understanding about it and we all agreed that it was time to move to a better piece of technology. I thought it would be difficult to find the material to learn from at first, but then found an amazing article called “10 FREE Articles About My Favorite Framework You MUST Read” which contained lots of high-quality content. It occurred to me that visiting the official website might be a good idea, but I wanted to learn from people like me, who are actually very experienced.
Everything was clear after just one article: there was a Sparkly Shiny Feature. It was only then I realized exactly how terrible Your Favorite Framework actually is. Compared to Sparkly Shiny Feature, the old-fashioned way of using A Different Approach simply doesn’t make sense in modern web-development. It is my professional opinion that 2018 will be the year of Sparkly Shiny Feature, because that’s when people will realize how good it is. I realized it earlier than the rest of the community, of course, because I read a lot of articles written by the community.
Since reading just that one article was enough to open my mind, I figured there’s no need to read the rest. After all, I’m too busy working on the Large Application. I should not spend time reading and exploring, but instead I should write more code. A piece of advice: writing code is only way you can progress as a developer — spending time to think and learn will only draw you back.
With that in mind, I started doing a full rewrite of my Large Application. I wanted to keep the old code for reference but I had no idea how to remove a file in Git, so I just deleted the .git folder. It solved my problem, so it’s probably a good idea for everyone to know this trick. There will be an upcoming article about this, where you will learn other Git stuff. I’m still debating on the title though: “One Weird Trick to Naturally Grow Your Git Repository by 5 Merges” or “Git Branches in Your Area Want to Meet”.
I spent a lot of time migrating my codebase, but it was worth it. One minor issue that I stumbled upon was the fact that all my tests broke as well, but given that I’m doing a simple migration means that nothing can break anymore. Since the tests have already served its purpose, I decided to delete them. My team members were also very pleased with this because now they do not have to hack around our policy of “every function must be tested”, when a lot of functions just had a “does not throw” test. No hacks = clean code!
It all went very well and now the Large Application is better than ever. What I really love about My Favorite Framework is performance. I’ve checked some benchmark results and it stated that My Favorite Framework is 50ms faster than Your Favorite Framework when dealing with a 10.000-row table. Of course, my application only ever handles arrays of size 20, but it’s still an improvement right? After all, performance matters!
Oh and by the way, the best thing about My Favorite Framework was that I finally found a hack to integrate jQuery back into my application. I now finally have the good old flexibility of pasting Stack Overflow snippets into my code. Good habits should never change.
And that’s it, folks! If you liked this article, please clap to it more than 15 times, subscribe to me, follow me on Twitter, add me as a friend on Facebook, send me a nudge via MSN and don’t forget to rate this video with 5 stars.
