Once upon a time, way back in the 1970s, there was this little operating system that came out of Bell Labs called UNIX. While most of the industrial effort in operating system development was focused on the commercial arena, UNIX was about something different. It was about giving the people who had to work with an operating system every day the freedom to get their work done quickly without a lot of pain. To this end, the work done by the creators of Unix was brilliant.
In The UNIX Philosophy by Mike Gancarz, he points out that two of UNIX’s strongest precepts were that small is beautiful and that a program should do one thing, and do it well. Small programs are easier to understand, maintain and enhance. Programs that do one thing well are typically less complex and more flexible than their counterparts. Used in tandem, these two tenets bring forth an almost zen-like simplicity to both programming and system development.
The programming world has come a long way since UNIX appeared, but these ideas still ring true. The systems that today’s programmers develop routinely are arguably more complex than any that have come before. But invariably, these complex systems are built out of small simple pieces that each do one thing well. I believe that most of us programmers today build systems and software in line with the UNIX Philosophy.
Robert Martin’s Clean Code promotes understandable code by following certain guidelines when writing software. Design Patterns by the Gang of Four (Gamma, Helm, Johnson and Vlissides) identifies recurring patterns found in programs and describes how they may be used in the development of new code. Programming methodologies such as agile, test driven development, and lean software development also try to make building complex systems less difficult. All of these work and help, but I believe that in the end, puting together small simple pieces that do one thing well is the best way to create good software.
The Rise of Web Development
In the late 1990s, the Internet began to commercialize. As businesses went online, web development became hot. Web developers were the cool nerds. My own path took me through Perl CGI to JavaBeans to Ruby on Rails. All along the way there was the foundation of HTML, JavaScript and CSS, changing but everpresent. On those rocks we built our castles.
Perl CGI was hard, due in no small part to the fact that Perl was hard. Perl was not known as a read-only language for nothing. Perl could do so much, but often it was beyond the understanding of mere mortals. Even seasoned Perl professionals could have a difficult time reading each others’ code. It seemed that doing more interesting things made the code even more difficult to understand, and more complex.
Java was originally developed as an alternative to C++, which was a no-fly zone for many programmers just because Microsoft had wrapped so much gunk around it. JavaBeans was created as a standard to encapsulate objects in Java, which became a conveyor between a Java Web server and a client. In particular, Enterprise JavaBeans and web beans were used to get objects out to the web. At the time this all made Java pretty cool because you could do web development using it, but Java was verbose. Making JavaBeans fit with the web model was even more verbose and thus prone to pain. Over time the Java web stack became deep, and more complex.
Contemporary with the creation of Java, the Ruby programming language was created in Japan. Compared to pretty much everything else, Ruby is elegant. It looks simple and it feels simple because you don’t have to write the things you don’t need to get work done. There’s very little pain in Ruby code. The Rails framework was the first general purpose web framework written in Ruby, evolving from a real web project, and though opinionated, turned out to be remarkably versatile. But over time it got bigger, slower, and more complex.
The Rise of Meteor
It seems that each promising framework became more complex to use.
In 2011, some folks got together to decide what to do about this ever-growing complexity in web development. What they wanted was something different. They wanted web development to be easy. Their response was Meteor.
Whether they knew it or not, they were turning back the clock to the UNIX days. They wanted web development to be like software development in the old days, when tooling was simple, languages were fewer, and with a little experience a programmer could quickly create systems built from simple small pieces that did one thing well.
In Meteor the tooling is simple. You create projects, you iteratively develop them, and you deploy them. Sure, there are lots of other tools in Meteor that do other things, but they’re all under the meteor umbrella, simple and understandable.
In Meteor the languages are fewer. Besides the ubiquitous HTML, CSS and JavaScript, you need… nothing. Meteor is JavaScript on the client and JavaScript on the server. Mongo is used to store documents in Meteor, but that’s straightforward, well-interfaced with JavaScript, and is available on the client and server as well. And you also need to know about the DOM, but in web development, that goes with the territory.
Gaining experience in Meteor comes quickly. It can only take hours to become effective. True, learning to do the hard stuff can take more time, but that’s less about complexity and more about taming the complexities of external packages.
The Meteor folks figured out the right way to divide and conquer complex web development and turn it into writing small, simple pieces that do one thing well. When you read code written under Meteor, it’s clean and easy to follow. You wonder why everyone’s not doing it this way.
Meteor, Beware the Dragons
There’s a lot of pressure on Meteor these days. A lot of programmers are coming to it for the first time. These programmers have held off until now because they’ve been investing their time in learning the systems that are the cool, shiny technologies that big players in the industry have created. The companies they work for have adopted these technologies, and the programmers who work for them have invested the time required to learn them. Naturally, they don’t want to see this effort go to waste.
These newcomers are putting that pressure on Meteor. “Change and we’ll use you,” they say. “Otherwise we won’t and you’ll fade into obscurity.”
Meteor has reached this pressure point that all worthwhile systems eventually do. Like the web development systems that came before it, Meteor is now at a fork in the road and must use a path. It can choose the left path, and try to tightly integrate the new cool systems, and try to bring today’s shiny technology into the fold at the cost of a little complexity. Or it can choose the right path, and keep things small and simple for those who have adopted it.
I believe Meteor should remember its roots, and understand what made it so special when it was created. It definitely wasn’t about bringing together shiny technology. It was about giving the people who had to do web development every day the freedom to get their work done quickly without a lot of pain. It was about allowing users to build systems by adding simple functionality incrementally rather than through tight integration of other systems into itself. And it should be remembered that there will always be some other cool, shiny technology coming next year, and the year after that, and so on. Meteor should choose the right path, and keep things simple.
The pressure to change will always be present. Meteor should change. But it should change in a way that is true to its principles. Meteor began as something different, a way to make web development simple and easy. It should adopt these new ways only if they do not push it towards increasing complexity and pain for its users. Otherwise, it will become the system being replaced.
Please keep it simple, Meteor.
