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.
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
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:
- Server-side language
- Server-side framework
- Template language
- Browser debugging tools
- Text editor/IDE
- Cache servers
- Job schedulers
- Build tools
- Deployment tools
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.
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.