Web Developers Are Schizophrenic

Everything in web land is moving very quickly. What’s best practice one day can be totally frowned upon the next day. This change isn’t necessarily a bad thing, we’re continuously rethinking and reevaluating our decisions on technology and process. In other words, the web dev community isn’t afraid of new ways of doing business.

But it wasn’t always like this. In the early days, creating a website only involved static HTML files and publishing them through a web server. But no long after that someone realized we could serve dynamically generated HTML files for more interactive sites. Ok, that’s cool we all thought, all you needed was a server-side language to generate these HTML files.

Man at desk multi-tasking

Some time after that came JavaScript like a refreshing whirlwind allowing even more interactivity and low-latency actions to be carried out without any server round-trips. So, the requirements are now HTML, a backend language and JavaScript. This is probably somewhere in the late 90’s and it’s also here things start to derail.

Not soon thereafter came CSS’s breakthrough, a language to simplify design and styling of web pages. CSS did simplify this but it also added another layer of complexity to web design. On top of those previous three languages you had to master, yet another was added.

The Current Toolbox

So where are we at? You need HTML, CSS, JavaScript and a server-side language. Four basic pieces making up any web developer’s toolbox even today. Undoubtedly this is just the bare bones needed for today’s development. To become productive you most likely need a server-side and JavaScript framework. Two quite heavy tools that both require some investment in terms of learning and becoming proficient with.

But if we should be realistic, a toolbox that small won’t get you very far in modern web development. I’d say building a modern website today requires a toolbox looking something more like this:

That makes quite an impressive list just for creating web sites nowadays and it makes me a bit nauseous. The context switching required here between client-side to server-side coding and to storing your data has grown over the last years. All this in the name of delivering kick-ass websites. And hey, that’s great! That always should be the focus and we can all be proud of how fast the community and the tools are evolving. Things get better everyday. People just have become too comfortable with the current situation of multiple runtimes, frameworks and languages that they don’t think about it.

When did we look at this from a broader perspective? Sure, really smart client and server side frameworks pop up every now and then but they usually solve “narrow” problems such as easy DOM selection or database object mapping. Think Rails or jQuery, both game-changing frameworks on how people approach web development.

But just as user experience isn’t about the tools neither is the developer experience. The latter is something we as developers rarely think about and that’s a shame. Keeping this experience in mind helps you get a perspective of how you do your work. How much context switching do you REALLY do without thinking about it? More than you’d like think I guess since it becomes almost second nature to most web devs.

What can we do about it? Many of the tools I described probably cannot be removed without sacrificing functionality. However you can ease the pain by choosing more ubiquitous languages and frameworks and through this help mitigate the context-switching problems.

Think Rails and Ruby. With Rails you can use Ruby as your template language and also help you with basic AJAX stuff (at least in the past <2.x versions). The build tool Rake which is written Ruby could double as your build tool and deployment tool. Also, Redcar is an interesting text editor that’s actually written in Ruby. Making it really easy for developers to extend their editor.

People aren’t dumb of course and they try minimize this breadth of their toolboxes, Rails and Ruby are just one example.

We can do better The least common denominator in this is JavaScript. The ubiquitousness of this language due to it being in every web browser has made it very popular. Used for mobile app development to database querying interfaces, it quickly has become a language almost every developer gotten in contact with.

While the language run by every browser can’t be changed, our server-side language can. And with the advent of node.js, this approach really has been taking off. It still is young but all the innovation going on there shows lots of promise. I’d say node.js is really the freshest breath to the web dev community in a long time. Despite its shortcomings being purely event/callback based.

Still remains to be seen what can be done, but sharing the same runtime between the client and server can really reduce the schizophrenia caused by all context switching seen in the past.

IDEs like Cloud9, purely written in JavaScript and run in the browser, will also help narrowing the gap of JavaScript truly becoming the ubiquitous language of web development.