Use what works, play with the new
April 8th, 2016
It’s easy to get caught up in the newest trend, and there are lots of great technologies being developed, but at the end of the day, just because something’s new and shiny doesn’t mean it will move the needle for your business.
Bingo. By the time I finish editing this post seventeen more frameworks, libraries, or pseudo-languages will have been released. And honestly, that is fantastic. Because out of those a few will take off, be well supported, and become great utilities for future projects to benefit from.
However, this doesn’t mean we need to use them in live projects immediately. Or, that we should jump from one framework to the next because you like the way the method names use camelCase.
Kyle goes on:
When it comes down to it, I’m most productive when I’m writing Rails code. Sure, I could build out my next project in Node.js, or Go, or whatever else is out there, but I’m going to be able to crank out the best, most productive code in Rails. I know it best. I’ve been working with it for almost as long as it’s been out, so I know all of its ins and outs.
This piece, as he explains, is a big reason to decide to use one language or framework over another. Not just your own productivity, as he states, but also for those that may touch the code in the future. If the framework is widely known, actively maintained, and many people use it in live projects, chances are you can add more people to the project and not have to teach them much about your project. They can likely dive right in and be productive very early on.
Lastly, this bit:
A mature framework, while it may not be as exciting, has had thousands (maybe tens of thousands) of hours of developer time spent getting it to where it is, which generally results in a more stable and secure platform.
If the project your working on ever hits any type of scale, you will want to know that hundreds if not thousands of other projects that run on the same technology has done so too. Early on, many people pointed to Twitter as a project that helped Ruby on Rails mature. And also to Facebook as one that helped PHP get a lot faster. Do a bit of digging when selecting what to use in your project, if a “big boy” is using and supporting it then you will likely get more sleep.
The very same reasons Kyle uses Ruby on Rails is why I use PHP. I do like the way Ruby looks far better than PHP. (Insert GIF of DHH saying Ruby is gorgeous here) I also think that the Rails framework is well structured for web applications. I do think Go looks succinct and interesting. And Node is likely better for some of the things I’m trying to accomplish. However, I’m faster with PHP, a lot of people know it, it is very fast and stable, and has been used in large-scale projects. So I’m perfectly happy using PHP.
I try my very best to stay completely agnostic when it comes to choices like these. (Kyle and I still get along great even though he’s a Ruby fascist.) In fact, longtime readers of my little blog here have likely seen my opinion of Microsoft technologies change dramatically since 2012 or so. Recently I saw someone’s C# and was all o_0! It looked very, very nice.
I love playing around with new things in order to see what else is out there. I can’t tell you how many times I’ve built a new Ruby on Rails application or built something with React or this or that. You’ve gotta keep the juices flowing and one way is to push your abilities into new territory. I liken it to a guitar player that mainly plays rock music riffing with a classical pianist. Expand your horizons from time-to-time and it will only make you a better guitar player.
None of this is to say that you shouldn’t switch to something new when the time is right. In fact, one very good reason to play with new languages and frameworks from time-to-time is that when something you’re using needs to get the axe you’re likely better prepared than if you had your head in the sand. There may be a time to switch from PHP to something else and when that happens I hope I have an open mind and make a good decision. I’ll likely refer back to Kyle’s post to help me make that decision too.