Sometimes, Javascript is not the Right Answer

Let’s talk about some use cases where you’re better of not using JSPhoto by Priscilla Du Preez on UnsplashJavaScript can do anything, at least that is what we like to think. However, while it sounds cool and it can potentially be true, there are a few …


This content originally appeared on Bits and Pieces - Medium and was authored by Fernando Doglio

Let’s talk about some use cases where you’re better of not using JS

Photo by Priscilla Du Preez on Unsplash

JavaScript can do anything, at least that is what we like to think. However, while it sounds cool and it can potentially be true, there are a few things we should not be doing with JavaScript, even if we can find a workaround for its intrinsic limitations.

The phrase “your scientists were so preoccupied with whether they could, they didn’t stop to think if they should” comes to mind in this situation (geek points if you know where that is from without having to google it). I know, it sounds terrible and clearly we’re not dealing with an end-of-the-world situation, but the same reasoning applies: just because you can do it, doesn’t mean you should.

This is why, even though I’m risking receiving some very interesting comments afterward, let’s take a look at 4 use cases where you’re most likely better of using something other than JavaScript.

Data science

Look, I get it, Tensorflow, Synaptic and other libraries got you believing you can actually do ML with JavaScript. However, that is not exactly the case.

There is a good reason why professional Data Scientists are using R or Python for their work: the ecosystem is far more mature than in JS.

The other big issue with ML is that it requires a lot of computational power to train those models. The training phase is probably one of the most taxing ones resource-wise and JS was not built for that.

In fact, most of these libraries are meant to give you the ability to perform ML from the browser itself, which in theory, sounds great. However, the little benefit that Node.js has implemented around worker threads is not available on browsers, so that’s not really an option. Instead through these libraries you only interact with pre-trained models. And don’t get me wrong, you’ll get the job done, but that’s not really machine learning, that’s just the equivalent of using an external API that does the heavy lifting for you.

And that is perfectly fine, mind you, let me say it again: you’re getting the job done after all. But there is a difference between claiming to be doing Data Science/ML, and actually doing it. And in this case, you’re just part of group #1.

Robotics

This is another one of those scenarios where you think you’re able to do it with JavaScript because lots of libraries give you some interaction with hardware. Like Johnny Five, for instance which allows you to run JavaScript on the Arduino platform.Which if you think about it, gives you access to the plethora of applications you can build through Arduino.

So as an entry platform for robotics? Yes, definitely!

Will it get you a job with Boston Dynamics? Hardly.

Robotics through JS is a great gateway drug, let’s call it that. But if you want “the hard stuff”, you’ll have to go lower-level, get something that is considerably faster to run which normally tends to be C or C++. That’s where the real money is at.

JavaScript is a fantastic hobby-oriented way of making robots and electronics in general. Accessible, yes, but that’s about it.

Game Development

I tried game development in JavaScript myself, I tested some of the libraries, they’re fun to toy around with and, yes, you’ve probably guessed it by now: they’re a fantastic and easy way to get into game development if you’ve never coded in a lower-level language.

But the truth of the matter is: there are no AAA games built with JavaScript. And if there are any which I’m not aware of, they’re the exception, not the norm. Why? Because people don’t want to play their favorite games on the browser.

Well, that and the whole performance and hardware access part, just like with robotics. And mind you, browsers have come a long way from their original purpose. They’re like the mobile phones of software. Originally you could just use them to browse Internet, and that was it. Now they have access to the GPU? I mean, damn!

If I’m not mistaken Unity, which has helped release some AAA games by now, does allow you to use some form of flavor of JS for their code (at least it did a few years ago), but it was a bastardized and outdated version of the language, so I wouldn’t really call it JS.

If you want to get into Game Development and you only know JS, that’s OK, you can pick up one of the libraries, learn the concepts involved in the process of making a game through that. But once you’re done, jump into the real stuff or you’ll be stuck.

Desktop applications

And we finally land on the biggest wrong use case for JavaScript, IMHO: Desktop applications.

Let’s put it this way: if you have to build a desktop app that is simple and you need to do it fast, then it’s fair game. Do you want to go with Electron and JS? Fine, by all means, knock yourself out.

But if you’re looking to build a complex, rich and new experience for your desktop users, I would not go with a solution that just opens up a headless browser window for you to write HTML, CSS and JS on as if it was something else.

I understand the temptation of being able to reach a new platform without having to learn a new language. And in some particular use cases that might actually be possible. Heck, with Electron they built Slack! Of course, you can open Slack, hit Ctrl+R and see how the whole UI refreshes. Feature?

Jokes aside, the simple truth is you’ll provide a sub-par experience to your users and potentially bad performance. Or you’ll have to work extra-hard to achieve the level of maturity a native application would have out of the box. Either way, it’s not ideal.

Yes, with Electron and other solutions, you can build a single application and distribute it across multiple platforms. That’s a very valid use case and I’m not denying it. I’m just making a point that none of those users in all those platforms will enjoy the best possible version of your application, instead they’ll have a carbon copy of your idea turned into an application.

Alright, if you got all the way here, I’d like to reiterate something I’ve been saying across the article: I love JS and I understand why you (or anyone you know) would want to use it for everything. The language itself, the syntax is very versatile and it allows for great development performance if you know how to use it.

But most of the use cases shown here have not been widely adopted in their respective markets. Either because they’re too new or just not able to beat their competition on production-grade solutions. So consider the fact that if you’d like to “make it” inside one of these industries JavaScript might not be the best investment skills-wise for you.

Finally, I’m not asking you to stop innovating. If you have an idea of making JS available for smart cars or smart appliances, for instance. Go for it! Innovation is key to growth. But if instead you’re looking for a way to skip learning a new paradigm or a new language and still be able to work on a non-web-related market. Think again, spend the time learning the new skill, your bank account will appreciate it.

Anyway, that’s my opinion. Disagree? Please let’s take it to the comments section, just try to be civil! ;)

Build with independent components, for speed and scale

Instead of building monolithic apps, build independent components first and compose them into features and applications. It makes development faster and helps teams build more consistent and scalable applications.

Bit offers a great developer experience for building independent components and composing applications. Many teams start by building their Design Systems or Micro Frontends, through independent components.
Give it a try →

An independently source-controlled and shared “card” component. On the right => its dependency graph, auto-generated by Bit.

Learn More


Sometimes, Javascript is not the Right Answer was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.


This content originally appeared on Bits and Pieces - Medium and was authored by Fernando Doglio


Print Share Comment Cite Upload Translate Updates
APA

Fernando Doglio | Sciencx (2021-11-23T22:34:21+00:00) Sometimes, Javascript is not the Right Answer. Retrieved from https://www.scien.cx/2021/11/23/sometimes-javascript-is-not-the-right-answer/

MLA
" » Sometimes, Javascript is not the Right Answer." Fernando Doglio | Sciencx - Tuesday November 23, 2021, https://www.scien.cx/2021/11/23/sometimes-javascript-is-not-the-right-answer/
HARVARD
Fernando Doglio | Sciencx Tuesday November 23, 2021 » Sometimes, Javascript is not the Right Answer., viewed ,<https://www.scien.cx/2021/11/23/sometimes-javascript-is-not-the-right-answer/>
VANCOUVER
Fernando Doglio | Sciencx - » Sometimes, Javascript is not the Right Answer. [Internet]. [Accessed ]. Available from: https://www.scien.cx/2021/11/23/sometimes-javascript-is-not-the-right-answer/
CHICAGO
" » Sometimes, Javascript is not the Right Answer." Fernando Doglio | Sciencx - Accessed . https://www.scien.cx/2021/11/23/sometimes-javascript-is-not-the-right-answer/
IEEE
" » Sometimes, Javascript is not the Right Answer." Fernando Doglio | Sciencx [Online]. Available: https://www.scien.cx/2021/11/23/sometimes-javascript-is-not-the-right-answer/. [Accessed: ]
rf:citation
» Sometimes, Javascript is not the Right Answer | Fernando Doglio | Sciencx | https://www.scien.cx/2021/11/23/sometimes-javascript-is-not-the-right-answer/ |

Please log in to upload a file.




There are no updates yet.
Click the Upload button above to add an update.

You must be logged in to translate posts. Please log in or register.