Not Your Father’s JavaScript

Last week I sat down to a meal with some friends and the topic turned to what I do for a living.  And because I love Node.js, Angular.js,, and a whole bunch more, I talked about how JavaScript has really taken center stage in web development.  Yeah, I’m that guy at parties- I talk about code.

One of the friends at the table is a CEO, who is also incredibly technically astute. After rising to EVP at a major tech company, he left and launched several successful start-ups.  He’s also been around the block enough to know where JavaScript came from, so when he commented that, “It’s completely unstructured,” I really got to thinking.  Lack of  structure carries a cost- money, time, frustration, performance.  And his statement is true, but only if you write unstructured JavaScript code.

The sad part is that most JavaScript written in the last 20 years is unstructured, and that is a terrible legacy to inherit.  But it’s not the only legacy.  JavaScript has some really good parts, is capable of wonderful syntax and functionality, and runs on every computer out there.  That is a legacy worth investing in.  And it’s one that a lot of the modern front-end frameworks invest in by providing structure and tools to streamline development.

Modern web apps are shifting the weight of handling user interaction back onto the browser.  User interfaces are more sophisticated, interactions more mature, and user expectations are high.  The code that powers that stuff? JavaScript.  But it’s more than that: powerful business logic is being implemented in the browser too.  The server no longer renders full pages for every user click.  That’s ponderous, slow, and creates that infamous “page flash” that people associate with web pages.  Newer JavaScript single-page apps cut out that overhead by delivering an entire application upfront, and it in turn communicates with the server for just the information it needs for the next step, and nothing else.  It’s lighter, faster, and more user-friendly.

The server-side world is already pretty mature.  The really important problems to solve now are in the front end.  Especially as phones and tablets become the norm for user interfaces.  Especially as HTML5 media support matures.  We’ll have to write code to handle swipes, touches, rotations, etc, over and over again, and the interface will need to respond in intelligent ways.  That’s not a problem for C# or Ruby, it’s a problem for JavaScript.

The moral of the story is this: avoid JavaScript at your own peril.  What the language used to be and what it is now are two different worlds.

Submit a Comment

Your email address will not be published. Required fields are marked *