Shiny things are fun. But more often than not, that new shiny thing is the result of a single person or group of people that thought an existing product, concept, or pattern could be improved upon. This doesn’t just happen in the software development industry, it happens in every other industry.
Steve jobs looked at tiny mp3 players and thought, this could be better. Eventually leading him to look at the brick cellphones we had at the time and think, this could be better.
The goal of each iteration of an idea is to solve specific problems with the previous version. To create either an easier product to use or a better environment for the person in it to complete tasks faster. When we start to look at the history of programming languages, this same concept starts to shine through.
From the original implementation of Fortran in the mid 1950s, to Lisp and Cobol in the late 1950s. Move on to Basic in 1964, Pascal, Smalltalk, C in the 1970s. Then Objective-C, C++, Erlang, Perl, Bash, and Python in the 1980s. Closer to today we had Haskell, Visual Basic, AppleScript, Lua, Java, LiveScript (which eventually was renamed to JavaScript), PHP, Ruby, OCaml in the 1990s. Finally in the last 20 years C#, VB .net, Scala, Clojure, Swift, Go, CoffeeScript, Rust, Dart, Kotlin, Elixir, Elm, TypeScript, and Reason.
The following list is in no way shape or form exhaustive. There have been hundreds of languages created since the 1950s. If you’re interested in that sort of thing, I’d definitely recommend checking some of the languages out https://en.wikipedia.org/wiki/Timeline_of_programming_languages
About 98% of the languages on that list all have a predecessor it was trying to build on top of. Each new language included abstractions for common patterns. This wasn’t by chance. It was a technical decision by the creator(s) to make programmers lives easier to complete the same tasks. To write less code, or maybe write more imperative or declarative code. Maybe they created it to be compiled faster, sometimes they didn’t even want it to be compiled at all and instead wanted it to be ran just in time when a specific piece of code was needed to executed. Sometimes it’s for performance, other times they know it’ll be slightly slower but the readability and developer experience is 50x better.
Every decision we make in our lives is about dealing in trade-offs. The programming languages we use for a technical problem and the reasons why we’d use a specific language, framework or tool is no different.
From here on out I’ll be making my case using JavaScript and it’s ecosystem due the fact it’s what I use it for 99% of my daily work. I’m sure someone who has 35 years of programming experience could make the same case speaking only about backend languages as well. I’m sorry if this excludes some from the conversation but I feel most if not all should be able to make the connections.
I’ve seen a trend the past 5–6 years as the web development industry has seen a drastic increase in the amount of people wanting to learn to create software. They attend a 3–6 month bootcamp for full-stack development. Basically throw you into the deep end with either Python, Objective-C/Swift, or JavaScript full-stack development. They learn about APIs and how servers work. What and how a deployment pipeline looks like. How to host applications on cloud services like Heroku or Netlify/Vercel etc.
Eventually they find themselves creating tools for either themselves or for the company they’re working for, or maybe they even want to create and maintain an open source library. They start planning out requirements, tinkering with some early proof of concepts, looking at the ways other similar libraries or frameworks are handling things. They’ve got this awesome new shiny thing that is almost done, only to come across the latest tweet “Proud to be launching ‘such and such’ today after 9 months of hard work”. Holy shit, that looks amazing. Click on the link and read through the getting started. Woah I can’t believe how much easier this looks and how much simpler this would make this thing I’m building be. I had no idea you could do it in this way compared to the way I’m doing it now.
rm -rf ./project
Start from scratch with this new found glorious knowledge you’ve obtained. Rinse, repeat.
Let’s go back a few years. Actually 8 years to be precise. I was a full time front-end engineer and always wanted to build native applications for iOS. There was phone gap and a few others at the time, but I wanted write “real” native. So I purchased a few Objective-C books and some redbulls. It went relatively good. Built a few tiny little play applications using the camera and photo storage, messed around with some of the device APIs the iPhone offered. But kind of fizzled out because I was nowhere near where I felt like I needed to be to transition to an iOS developer.
Fast forward 2 years later, Swift was announced and it was the hot new jazz. It got me interested again in native iOS application development again. Maybe it’ll be easier to pick up this time around. Swift was a completely new programming language compared to Objective-C, but it ended up being easier to pick up faster. Because I had already learned a decent amount of Objective-C, I could pick up on the reason I would want to use it over Objective-C. The abstractions, the less verbose syntax etc. It made sense because I had knowledge of what it was building on top of. I eventually fizzled out again because my passion for front-end development was to strong.
Back to today and the JavaScript ecosystem. TypeScript. I know just by typing that there are a few people who just got chills and want to close the window. Who the fuck wants to write strongly typed JavaScript? Vomit. This can easily be the case with newer developers who have limited JavaScript experience or knowledge. There obviously is a reason it’s so widely used now, but you just understand why.
Deno.js was just released recently. Which was created Ryan Dahl, who also happens to be the original creator of Node.js. But why this new shiny thing? Should you use it? Why should you? This brings me back to my original point of learning things sequentially. If you watch his talk on his regrets of Node.js (https://www.youtube.com/watch?v=M3BM9TB-8yA) you’ll start to get an understanding of this new shiny toy.
It’s completely fine to have never written a line of JavaScript and jump straight into TypeScript. Yes I said it. Permissible but not beneficial. Learning programming languages and frameworks sequentially even if there’s a slight overlap helps you understand why something is the way it is. You’ll understand concepts faster and at least for myself I retain the information better because I know what it’s built upon.
jQuery, Backbone, Spine, Ampersand, Angular, React, Vue, Svelte… The list goes on and on with front-end libraries and frameworks. Grunt, Gulp, Browserify, Webpack, Rollup, Snowpack… The list goes on and on with front-end build tools.
I’m not making the case you need to learn everything in it’s entirety. But learning older languages, frameworks and tools even if it’s a broad overview of them will help you understand why things are the way they are. It’ll help you make decisions on why you’d use one thing over another. It’ll help with understanding the trade-offs in the software you develop on a technical level.
It’s perfectly ok if you have to use the most brand new thing at work and you fully don’t understand why you’re even using it. If you’re hungry for more knowledge, spend some time outside of work and go back to the roots of where our technology came from. Build a jQuery plugin. Build a Gulp.js clone. Build a sample VDOM library. You don’t need to publish them. You don’t need github stars. But I’m almost certain it’ll help you down your path of growing as an engineer.
Thanks for reading my random Sunday morning thoughts. I also hope it empowers you in conversations when talking about shiny new things to take a step back and know the reasoning behind deciding on something new.
Top comments (0)