I spent years as a software consultant and I wrote a lot of web applications during that time.

I remember when I first discovered Active Server Pages  (which we now call "Classic ASP") and I remember how excited I was by this technology. It empowered me to write dynamic applications that the whole world could see.

When Microsoft introduced ASP.NET, I quickly embraced it and when ASP.NET evolved to MVC, I was excited to move to this new paradigm.

I even wrote a bit of JavaScript, enhancing my web applications with client-side validation and interactivity. I wrote even more JavaScript after discovering how jQuery made the DOM manipulation easier to write, debug, and maintain.

But, about 5 years ago, I stopped writing web applications. It wasn't because I disliked anything about them; it was only because my customers were looking for different solutions. So, for a few years, I wrote middleware services and web services and rich client applications and I built databases and I set up continuous integrations systems and I barely looked at web development.

But Web Development technologies did not stand still; if anything, they changed faster than almost any other area of software.

Web Development has moved largely from the server to the client. Interactions that were once handled by a form post and full page refresh are now done using Ajax calls to a web service and client-side DOM manipulation. An asynchronous callback from the server to client triggers a JavaScript function to update elements on the page, eliminating the need for a disruptive repainting of an entire page.

The user experience of a Single Page Application tends to be far superior to the older multi-page applications, so users are demanding more and developers are now writing large, complex applications that run almost entirely inside a browser.

JavaScript wasn't designed with this complexity in mind, so a number of JavaScript frameworks emerged to help developers manage this complexity. These frameworks take care of things like data binding, DOM manipulation, input validation, and separation of concerns, freeing developers to focus their efforts on business logic and other features unique to their own applications.

These frameworks help, but they come at a cost. It takes time to learn a new framework and each framework has its own set of rules and idiosyncrasies.

Even more challenging is the speed at which these frameworks are released. A year after the popularity of ember.js and backbone.js peaked, developers began flocking to Angular.js. Last year, Angular seemed to lose ground to React.js. It's hard to tell what will be the next hot JavaScript framework (Angular 2.0? Aurelia? Something else?), but the rate at which new frameworks appear is accelerating.

Of course, it is not practical to re-write every application every year, simply because you discover a new framework - even one with advantages over your existing framework of choice. And most of us don't have the time to become familiar with a new framework every few months. We have to balance the increased productivity of a new framework against the time spent learning (as opposed to building).

This is the world in which I now find myself as I return to Web Development after a half decade absence. Everything has changed and continues to change at a startling rate.

In many ways this constant innovation is exciting and energizing. But it can also be overwhelming as I try to select the appropriate tools from a plethora of options and as I spend the time and effort learning how to use these tools.

meerkats I feel like I'm in a science fiction movie where the hero departs the Earth at light speed; then returns to discover the planet is ruled by talking meerkats: All the rules have changed while I was gone and I need to adapt. Quickly.

The approach I've taken is to pick a JavaScript framework, learn it, and build an application with it. I chose Angular to start - partly because I had heard good things about it and partly because its popularity ensured I would be able to find samples, tutorials, videos, and other reference materials to assist me. Next, I'll rebuild this functionality in ReactJs, followed by some other framework, until I have a feel for the paradigms involved in JavaScript development and for the relative strengths of each framework.

You can track my progress at https://github.com/DavidGiard/tvdg and on this blog.

So far, I'm enjoying the ride.