Open-source champion, Eric Raymond, famously described his preferred method of software development as a bazaar, a marketplace of ideas where every person was free to contribute and improve on a software project. The idea that many developers working on a problem, each with their own agenda and motivations, could produce a better product than a top-down approach to software development was only starting to see adoption at the peak of the first internet boom. But the strength of the idea outlasted the projects and companies that were the early adopters of it. For those of us who work as web developers, it would be hard to imagine not utilizing tools in our daily work that aren’t hosted on Github. The transparent nature of HTML and Javascript make it easy to see the weaknesses and inefficiencies in our code, and we frequently have them pointed out to us. The bazaar is so prolific that the concept no longer needs to describe the democratization of development practices that the internet faced two decades ago. It’s shifted to a new paradigm.
With the accumulation of wealth in a developing nation, the healthy open-air bazaars become supermarkets and malls. Web developers are blessed with a wealth of tools and frameworks born out of a vacuum of need to improve our lifestyle. Just as enough of us realize that there must be a better way to structure our code or reach our users, you’ll find that there are competing brands and brand champions for the best way to solve this problem that you’d only just discovered exists. Having too many options of brand of laundry detergent is truly a first world problem, but it underlies a stressful point in our jobs. Our clients trust us to make the best decisions for them, yet most web developers don’t feel like experts of their domain. For those of us who have been doing this since more-or-less the beginning, keeping up is like daily boot camp and many only get through with the support of their peers at work or development community. For novices and those who work in isolation, it’s like looking up at Mount Everest. In that situation, the only thing to do is to take the first step, as I recently did.
I was a front-end developer on a Perl-based website for three years. Creating an eCommerce website from the ground up without any modern frameworks is a lot of re-inventing the wheel, but doesn’t mean you get something that was worth the effort. Comparatively, I prefer to work with Drupal. I built this blog on it as a way to get to play with the tools I’ve wanted to use but didn’t have at work. Being a Drupal developer is the opposite of going it alone, because Drupal is the largest open-source project in the world with ten times as many contributors as the Linux core. Because of this, Drupal is empowering, letting a single developer on a project use the combined resources of the entire community’s contributed modules and themes. In comparing popular content management systems, Drupal is always seen as the most complex, the most difficult to learn, but also the most powerful and configurable to suit any need. In the three years since I’ve worked with Drupal professionally, I’ve found that there’s a lot that’s new to learn, but there’s also a welcoming and diverse community that’s grown out of the need to address that learning curve.
But while Drupal addresses a lot of my problems with development, it certainly doesn’t solve everyone’s needs. Capable engineers can certainly be more comfortable with Ruby or Django for building the backend of a leaner, meaner web app. But for front end developers, there’s nothing that looks more appealing than Node.js right now. Giving developers who are proficient in Javascript, but who may have never touched a controller the ability to work on both the front-end and back-end of their project reduces your resource requirements and gives front-end developers a better understanding of what they’re writing the the feeling of being empowered to tackle it. Angular.js works well as the glue between the pure front-end layer and the data on the backend, and Jade strives to do for HTML templating what CSS frameworks have done for CSS.
Oh, speaking of CSS frameworks, there’s quite a few to choose from these days. Something as simple as CSS can still benefit greatly from some modernization, but picking the best approach is a difficult and contentious decision, and the right answer seems to change almost from week to week. Less and Sass both got the same idea of making CSS fun to write and easy to read, and while they’re more alike than different, picking one or the other is something you want to get right the first time. I’ve gone with Sass for a myriad of reasons that can be better explained elsewhere, except to say that there’s more community support behind Sass from where I’m standing - both with Drupal and with the resources that make Sass work, like Compass. Sass is more of the Drupal way of development, open and adaptable. However, as soon as I made the decision to start using Sass in my projects, someone else told me that I should be learning Stylus, another almost-but-not-quite-the-same CSS pre-processor that strives to get further away from CSS. I can’t weigh in yet on what will ultimately be the best tool, because it’s another area where the landscape is changing so swiftly that anything could happen, and developers have to stay agile and adaptable to change.
The upside, though, is that like with programming, it only takes changing your thought process once to be capable of assimilating any changes that come down the pipe later. It can seem like a lot of work to change your thought process when you’re entrenched in ideas that don’t conform to the new marketplace of open source development. There’s a fear that constant adaptation leads to a cycle of destruction and creation that users won’t ultimately notice. But the more we use better tools, the better we get with them, and a hammer can only take you so far. Every developer should know that the better their tools are, the happier of a craftsman they’ll be.
Photo by Pedro Szekely