The Next Great Hobbyist Revolution
No ads, no tracking, and no data collection. Enjoy this article? Buy us a ☕.
I want to take a trip down memory lane to a white-paper I wrote over a decade ago. It was originally titled Ruby on Rails: Death to All Hobbyists. I wrote it near the peak of Ruby on Rails popularity, and it was an analysis of hobbyist languages and hype versus proven scalability and development processes. I left most of the white-paper alone, but adjusted the language to be past tense instead of present tense. What's worth noting is that you could swap out Ruby on Rails for Elixir, Angular, React, or just about any hyped language or platform over the course of the last ten years as frameworks and buzzwords hit various peaks and valleys. I think that history pretty much proves my overall point.
Ruby on Rails was the most hyped about technology in modern programming since the days when XML started passing the lips of CEO's who just "had" to join in on the latest round of buzzword bingo.
I didn't believe the hype initially. By the time Ruby on Rails started to gain traction, I was hip deep in Mono development (the open source version of .NET that could run on Mac OS X and Linux), and really had no desire to pick up "yet another" framework to master. I was familiar with the Ruby programming language, having programmed with it on several occasions, but for pure web development, I still stuck with Perl (yes, I'm that old) or .NET. It wasn't until I first viewed David Heinemeier Hansson's now infamous screen-cast of programming a weblog in Rails that I decided that this framework needed some attention.
Ruby on Rails was one of the fastest and most efficient programming languages (in terms of the development cycle) at that time. This doesn't mean it was the fastest running language—nor does it mean it was the most efficient language to use—but it does mean that when it came to the life cycle of application development, Ruby on Rails could get you to the endgame faster than most.
Rails was also a very human intuitive programming language. This meant that while planning out your functionality or reviewing code, the code read like the English language in most cases. Oftentimes you could "guess" at how something would work and you'd be right. Other times you could easily track down issues in your code—or just functionality that you were looking for—by reading through it with ease.
The speed of development and intuitive nature of the framework were two of the largest reasons that Ruby on Rails was such an attractive language for programmers to develop in and for businesses to request as the backbone of their own development. Rails' fast development life cycle meant less expense on programming and faster ROI. Or did it?
When the worlds of web development and programming converged to produce dynamic web applications that intermingled front-end design code (HTML) with server side technologies (Java, Perl) there were four main competitors for the title: Sun's Java ServerPages, Microsoft's Active ServerPages, ColdFusion and PHP. Out of these four most popular dynamic languages, PHP stood as a web developer's dream. With no compiling required, no real tag syntax and a lower barrier of entry than most others, PHP became the de facto dynamic language on the Internet. This doesn't mean that everyone was using it. To the contrary, at the time, most big businesses were heavily invested in Java Servlet and JSP technology. But many small and medium sized businesses couldn't cope with the cost of expensive Sun Microsystems or IBM tools. Instead, they started looking for a more cost effective alternative that would "just plain work." PHP filled the void not only for small and medium sized businesses, but also for young hobbyist developers looking to program their own web applications for personal or community use.
The problem with PHP began to arise when it became obvious that too many hobbyist developers were passing themselves off as experts. PHP was an easy language to learn, but learning a language and mastering it are two different things. The Internet was now filled with applications, scripts and even quite a few development houses that were created by what some in the technology industry refer to as "script kiddies." Script kiddies were hobbyists that learned the basics of the language necessary just to get their project complete. That didn't mean that it was efficient. That didn't mean that it was secure. It just meant that it was done. These same script kiddies could often be seen trying to sell their services for development projects.
All of this had ultimately given PHP a bad name in some circles. PHP didn't have a clear separation of front-end (view) design and back-end (controller, model) programming. It also wasn't as secure as many other languages—originally more focused for quick integrated development rather than fully fledged web applications; and although PHP had grown and evolved into a more robust and secure language compared to its earlier versions, the script kiddies didn't evolved with it. The result was bad, uninformed programming, and poor code that could ultimately cost an individual or business in the long run.
The day eventually came where Ruby on Rails had taken the place of PHP as the script kiddies' dream tool. Consultants and code houses wowed prospective clients with the speed of development factor, while secretly tapping their heels in the air at the ease that Rails brought to them during programming. But just as PHP had spawned a cadre of hobbyist programmers that lacked a clear understanding of software architecture, Ruby on Rails had spawned hobbyist programmers reliant on the framework to do the work for them. Sure they could build generic applications fast and with a smile—and even with client approval on the glimmering surface of the finished product—but this didn't mean the application was secure, optimized, or ready to bring value.
I never ran into many Ruby programmers. I ran into a lot of Rails programmers. Despite Ruby on Rails being written in Ruby, a Ruby on Rails project consisted of a tight wrapping of the application within the framework. A Rails application would be programmed with mostly Rails framework-created methods and methodology. You had to "learn" the framework to be an effective Rails programmer, which is true with any framework. Ruby on Rails was so easy to work with, however, that it was even easier to jump on board and start creating applications without ever being familiar with the Ruby language itself. This is where the problems started to occur.
It's one thing to know how to program. It's another thing to know how to program effectively and solve real world problems. Ruby on Rails did a great job of giving programmers the tools to start an application, but only real problem solving skills will help them finish that application, and finish it to the clients' satisfaction. Truly innovative tasks are not accomplished "out-of-the-box." Ruby on Rails could probably take you 80-85% of the way there, but unless a programmer actually knows the underlying technology (Ruby in this case) they'd be ill-equipped to solve the problems that occur when functionality requests from the client lie outside of the realm of "out-of-the-box" Rails functionality. It is the solution to those problems that separates an average application from one that makes a client successful. This is why fundamental understanding of software architecture is such an important thing.
A low barrier to entry for a framework is not always good for businesses seeking technology solutions. It can sometimes actually hurt them when they're seeking to solve their technology needs. There are too many script kiddies rampant on the Internet professing expertise in languages like Ruby on Rails, but without any solid understanding of the actual underlying language and the methodologies of successful software architecture. Businesses have very little wiggle room for error when investing in technology. A business must be able to rely on sound technology that knows how to solve problems, not just pieced together parts inside of a framework.
The above was written around 2009-2010. It wasn't at the height of Ruby on Rails' popularity, but was certainly still near the peak. Rails eventually came under fire for being slow (a fault of the Ruby language at the time) and being bloated. But you could swap Ruby on Rails out for Elixir 5 years ago and you can swap it out for React-ish frameworks today. Most languages and frameworks run through the hype cycle before settling down, but if the person using the language or framework is proficient at "programming" and "problem-solving" then the framework shouldn't matter.