The Most Secure Cross Browser Testing Platform since 2012


Should We Use JavaScript for Everything Now?

BLOG / Web Development

Should We Use JavaScript for Everything Now?

JavaScript is one of the world’s most popular programming languages and also one of the most controversial. While the script language is incorporated into every web browser (and quickly marching into other areas) by many, it is also despised, passionately. Lately, JavaScript has been moving into areas like back end and servers, and it begs the question: should we use Java for everything now? We are going to talk about a few points to support why we think it should not.

JavaScript Has Positive Attributes

There’s plenty to like about JavaScript. Being a standard recommendation as a subset of EcmaScript, it isn’t hard to see why it’s so heavily used in browsers. I dare you to not find a library for anything. jQuery has enough info to build a mobile site in 24 hours.

Ajax is heavily used among developers and with web-enabled devices literally, everywhere, JavaScript is not going anywhere soon.

The JavaScript Haters

While we admit, JavaScript has its good side, if you ask around, you will find the opinion that JavaScript is a horrible language. Ouch. Legend says JavaScript was designed in only 10 days, and for many developers, this seems obvious. Especially considering its vast amount of quirks that create serious headaches.

JavaScript is Everywhere

We continue to use JavaScript on the web, mostly for lack of a better option. Sure, some claim that NodeJS is the only real developer language, but the next guy will claim we are getting close to completely overthrowing JavaScript altogether and getting ready to start from scratch.

JavaScript frameworks are not easy to master and they can only be built upon so much before you have to wonder: is it an if, or a when, the slate will need to be wiped clean and the frustrated developer forced to start all over again? Not a completely unreasonable fear.

JavaScript And The Desktop App

Remember when we discussed JavaScript being everywhere? Here’s an example: Spotify. The wildly popular music streaming site uses JavaScript as a desktop client. Maybe one of the most complex uses of JavaScript we’ve ever heard?

Here is the setup: a C++ core, with the JavaScript UI built on top. C++ takes care of the music playback, user edits and the local files, but JavaScript deals with all the interacting and rendering with the UI. They communicate with each other via a message interface, and all JavaScript/HTML/CSS assets get bundled into the app itself and are then run locally. That’s pretty creative, but not hard to see where things might go wrong.

NodeJS Creeping In

You might have noticed lately, more and more developers are using NodeJS on the server side and the back end.

Lauded as the “silver bullet” developers have been waiting for, to hear NodeJS’s fans, you would think it was slated to take over the development world. Yes, it does well in real-time apps because it doesn’t use web sockets and instead employs push technology.

Which is awesome, because 2-way communication in real time between web apps where clients and servers can freely exchange data is a welcomed change from the typical response paradigm. But, the last thing you want to do is use it for CPU-intensive operations. By doing so, you will void any advantage you had choosing NodeJS at all.

NodeJS can build scalable network apps, fast ones by operating on single-threads using non-blocking I/O calls, and can support concurrent connections by the 10 thousands.

That’s all great, but here is the truth: NodeJS was never intended to solve the problem of computational scaling. However, it was intended to solve I/O scaling and that it does.

NodeJS is not a good idea to use for server side apps if you are using them with a relational database. The database tools it currently offers are not easy to work with and are still in the early stages.

Another place where it’s not the best choice: heavy server-side processing or heavy computation. Incoming requests are going to get blocked, and heavy background processes will need to communicate via a message queue server.

Too Risky To Be A Good Idea

At the end of the day, JavaScript has too many drawbacks to be used everywhere. If you’re building something that relies on efficiency, speed or performance, it’s not the best. You are going to have callback issues. There is a complete lack of proper block scoping support. Miscellaneous behavior annoyances and expected quirks are guaranteed to come up, frequently. Not to mention the aggressive type coercion and heavy reliance on global variables.

JavaScript might be sticking around a while longer, but that doesn’t mean we need to use it in areas it was never intended. There are plenty of reasons to like its better attributes, and NodeJS has potential, but server-side isn’t one of them. At least, not yet.