The Persecution of JavaScript

JavaScript’s history is a colored one of misuse and misunderstanding. It has evolved into a platform that, as of today, is arguably the most approachable, portable, and versatile programming language available. A former colleague of mine recently showed me an article claiming 10 reasons why you should not use JavaScript. JavaScript, like every language, has its strengths and weaknesses, but what is interesting about the article shared with me is the naivety behind it. Comparing JavaScript to languages like Ruby, Go, and Java is like comparing a hammer to a power drill. Each tool is very useful but each is better suited to solve certain types of problems. Developers have learned from their own experiences how to approach certain problems with their language of choice. What we forget sometimes is that we must not assume another language approaches this same problem with the same tools, patterns, or paradigms. That said, let’s look at some claims from the article in question.

The Assumptions

JavaScript hurts your mobile visitors

I am assuming this refers to performance and usability based on a comparison of HTML5 web applications to native applications. When running web applications on mobile devices they are restricted by a few factors.The rendering pipeline limitations of the device, the speed of DOM interactions and degree of GPU acceleration all contribute to performance. JavaScript, like many languages, can always be optimized for mobile performance but is by no means even close to being a major performance problem. I can agree that less lines of code per request helps to “lighten the load” but to say the Phone Gap article bashing JQuery Mobile is referring to all JavaScript is just not true. In fact, as the article title suggests, the post specifically refers to JQuery Mobile.

Many projects optimize web applications for progressive enhancement. One example is SouthStreet By Filament Group. They have taken several problems they see in modern web applications, especially in mobile, and have proposed solutions to these. As an example of one SouthStreet component is PictureFill . At a very high level it enables you to download smaller assets for less capable devices instead of the desktop high resolution versions through markup and JavaScript. This is a way JavaScript actually helps with progressive enhancement. Also, I recommend taking a look at Jake Archibald’s article on Progressive Enhancement. Jake explains “Progressive enhancement has never been about users who’ve turned JavaScript off, or least it wasn’t for me.”. He further details approaches to what he feels true progressive enhancement should be.

JavaScript hurts your robustness

The post talks about “a single bug in your JavaScript can break the functionality” . This is why we, as developers, use linters and testing. If you are pushing code that you haven’t tested in your application’s supported browsers then that is not the fault of JavaScript. Additionally the post argues that using JavaScript MVC frameworks couples your application and prevents testing future browser implementations of JavaScript. Projects like Chrome Canary and Firefox Aurora are extremely helpful if you want to test your code now in future implementations of the browser. This is also great because if you find a bug and submit it it will most likely be fixed by the time your users see it.  One problem I do see with developers often is that they don’t test in their application’s least powerful target browser throughout the development time. That means bugs are not found early enough in the process.  Testing early and often in at least the worst browser on the list will save so much pain in the long run. This is not a JavaScript issue.

JavaScript hurts your security (and your privacy)

We have all heard the horror stories of the evil hacker sitting in an abandoned shack somewhere in Portland hacking into our servers and sucking out our souls from across the the nine hells of the internet. Although JavaScript can be minified and obfuscated, a clever hacker will get your code if it’s there in the browser. While I agree that client side JavaScript has vulnerabilities in this area I do not agree that this should be the responsibility of the JavaScript language. Each browser allows JavaScript to access quite a bit of features. Without that authorization, many features of our applications we run in the browser would not be possible.

The fallacy in cyber security is that we are not protected because of JavaScript. It is true that a simple Google search will yield results that detail standard attack vectors using XSS and XSRF. Anyone can find step-by-step instructions and training videos on YouTube these days. Fear not, XSS and XSRF ARE preventable attacks. You can put countermeasures into your application on the backend to prevent this from hurting your users. As a general rule of thumb, don’t expose sensitive data in the browser where JavaScript has access. Server Side JavaScript has many more security options so storing sensitive data there is not an issue. Your backend, which might be JavaScript should always assume the browser can’t be trusted in these cases. On a related note – the real cyber threat is not JavaScript, SQL Injection Attacks, or even code hacks in general; It’s Human Hacking and the art of Social Engineering.

JavaScript hurts your SEO

Front End Developers seem to have a love for clean markup (I know I do). If you code your HTML semantically, separate your concerns, and use accessibility standards you can progressively enhance your page for robust functionality while maintaining SEO. Section 508 has been due for an overhaul but still yields some great practices that can optimize SEO. WAI-Aria attributes and patterns can progressively enhance your page for robust functionality while maintaining SEO standards.The big concern sited in the post was AJAX. Making your site functional without AJAX is sometimes an option but not always. This is not a JavaScript problem either as the language was not designed for SEO purposes nor claims to assist or hinder it.

JavaScript hurts your development time

Browser tools for Internet Explorer have come a long way. has a lot of testing tools for Internet Explorer. The new F12 tools are no Firebug or webkit debugger but they are getting there. Browser tools and even server side tools for Node.js like DTrace and TraceGl are extremely helpful. Using a linter and checking target browsers in the Continuous Integration and in development is extremely important. Unit testing and End To End testing for JavaScript is a necessity when building massive applications. Would you leave out testing in the backend of the application? Development time optimization comes with experience no matter what platform you are on.

JavaScript hurts your testing costs

If I understood this section correctly, “maintenance costs of testing” and relying on HTML implementations of browsers are the issues causing this ‘pain’. Testing is an quality investment, whether it is on the data layer, back end, or the front end. If you are testing the right functionality in your code and you are communicating what is being tested then testing is maintainable. This is a difficult and subjective way of thinking, especially in large teams where everyone has a different style if testing and coding. That said, testing code is a discipline and an irreplaceable tool to ensure better quality software. This is true not just for JavaScript but for all programming languages. As for setup of these frameworks you most likely need a browser matrix that you are targeting for your code so I get it that there is that dependency. Given that you are creating tools and applications with JavaScript that will run on those targets then it is no different than server side testing requiring environment and system dependencies. End-To-End testing is similar to integration testing on the server side. Whether you are writing unit tests or integration tests,  we have bad tests and good ones. JavaScript is not an exception in this case but not at the fault either.

JavaScript hurts your website performance

Nothing hurts more than watching a client scream at an application you built that loads in 6 or more seconds. Premature JavaScript performance modifications are not necessary. If you are wealthy enough ( or have a client that is) to use a tool like New Relic, you may find that the page is waiting on the server from some crazy SQL call or a service end point that’s slow. Just because the browser takes longer to load a page doesn’t mean it’s the JavaScript that is at fault. When it determined a performance issue is on the client side, it’s usually bad coding practices. Restricting the amount of DOM elements, using spriting techniques, concatenating static assets to avoid vast amounts of server call are a few major contributors to better performance on the front end. Tools like JQuery optimize this and abstract out browser specific implementations but overuse of the DOM is not recommended. This is a failing in how the DOM is implemented across browsers, not in JavaScript.

JavaScript hurts your software investment

JavaScript is almost 20 years old now. It is now a proven platform for major application across the world. Applets and Flash require a plugin and are not the same as JavaScript. JavaScript is native to the browser.You cannot compare Applets to JavaScript. “Client-side technology is doomed to fail” is very presumptuous. I am not sure why you would assume JavaScript is doomed to fail since it has been widely adopted by large companies likes Google, Microsoft, Facebook, etc. I can’t even think of a company that has not desired to build a web application without any use of JavaScript.

JavaScript hurts your software architecture

First off I love MooTools but it is a abstraction of JavaScript. Underneath MooTools is plain old vanilla JavaScript. It is a bad idea to assume that backend developers understand how JavaScript works. Respectively, it is bad to assume JavaScript programmers understand how the server-side backend works and its complexities. JavaScript is flexible enough that it can emulate many styles of development. There is not a right or wrong way to code in JavaScript, only style and tradeoffs. If you don’t understand its paradigms and approaches to coding you should research and learn it.

JavaScript is not needed

This one I actually agree with this to a degree in some cases. For accessibility and Mobile First approaches we have a choice to to approach the application MVP with a semantic HTML version that has a minimal script tag to detect capabilities and provide richer experience in richer device targets. The rich functionality we see in applications is from JavaScript (and CSS) these days. Creating GMail without JavaScript is probably a bad idea. There are still things that can only be done on the client side. JavaScript is just another tool in the toolbox and should be used to create great software.

JavaScript is not perfect and it is definitely not the end of the road for application development. It is a flexible tool akin to a swiss army knife. It is powerful, portable, and versatile. and it has many problems it can solve and many ways to do them.