My first job out of college was working on OfficeMax.com (for OfficeMax) in 1999, where I primarily wrote a combination of client-side code and server-side javascript, run on Netscape Enterprise Server. For several years thereafter, I attempted to run far away from this ‘javascript’ world, as javascript at the time seemed to be a mess to deal with (this is well pre-JQuery, let alone all the other javascript libraries/frameworks of today), and languages such as Java were where it was happening. I can remember going to Java One for a few years in the early 2000’s and the buzz there was very WWDC-like. It seems hard to believe in this day and age I’m sure. But it’s indicative of the tech industry being both cyclical and the fact that today’s hot technologies are tomorrow’s not quite so cool (but still widely used) technologies.

In the past few years I’ve strived to leverage the Java and object-oriented knowledge I gained from several years prior with other dynamic JVM languages and frameworks, as well as pried my way onto native and mobile web initiatives/projects. Aside from native mobile application work, I’ve found that working with javascript has been best at providing me with an ever-increasing amount of development enjoyment. The innovation in the space is often mind-boggling, and many of the solutions I run across are amongst some of the most elegant libraries and frameworks around today.

That being said, integrating client-side javascript libraries and frameworks with non-javascript-friendly (more on that in a moment) back-ends produces a set of challenges. There’s state synchronization, rather manual synchronizing of changes, wiring together script packages/packaging, CSS compilers, code minifiers, client-side MV+ frameworks, templating engines, client-side history, ORM, database, etc. And that’s just for starters. While this certainly can be managed by seasoned developers, after doing the work of adding all these pieces, wiring them together, testing them and maintaining them, one at some point has to ask themselves: “is this the best way to be doing this?”

I’ve long since asked the questioned and told myself “no” many times. That being said, few web projects are greenfield and rarely - or basically never - are decisions that drive technologies used at companies politics-free. Certainly though I’ve reached a level of exasperation with it. Frameworks such as Derby, Socketstream and Meteor are either built upon or provide out-of-the-box (or optional yet rather easy) integration with popular libraries such as Node.js, Express, Socket.IO, Browserify and MongoDB. And many more. One of the challenges I see in the midwest as a developer is that there has been so much investment made my organizations and developers in the Java stack, and to a lesser extent Rails, that moving to these other stacks is an enormous challenge. There’s misperceptions out there I’m sure that provide excuses for resistance: performance issues, documentation issues, SEO issues, maturity, etc. As I similarly alluded to earlier, these are the same stories that get thrown out in the early part of any adoption cycle for impending technology trends. Some of them have validity to a degree, but they are widely overblown. From my vantage point, being that I’m a strong believer in the “realtime” web replacing the “dynamic” web we see today, platforms such as Node.js - or Vert.x - are our web application platforms of - at the very least - the not too distant future. And what language works on all these platforms, and all of the frameworks I mentioned above? Javascript. That’s why I say embrace it. That’s why I pushed in some talks I gave last year to “learn it” - to understand it - and most importantly, to know how to use it properly.

I’m hopeful in 2013 that I can - at the very least - help push the conversation at local companies and with local developers in my area forward on the types of technology stacks I’ve mentioned above. I have ideas for talks, blog posts and demo apps (not chat apps…) ready to be explored, to excite others, to help show the possibilities and dispel the myths. In short, I’m looking forward to helping others embrace our javascript overlords. If the interest and ideas are out there, I would certainly be very interested in joining forces with other local developers in this fight as well. We can either whine about the state of affairs at clients and companies (a trap I personally at times fall into), or we can actively work to show why there is a better way.