You cannot use JavaScript for everything!

Questo articolo è stato scritto oltre 1 years, il contenuto potrebbe essere datato.

Someone should say this again and again: You cannot use JavaScript for everything!

I am a developer that started to develop in JavaScript in 2006/07, when there was Internet Explorer 6 and there wasn’t any transpiler.

This was the book I read in that period from my local public library. (Photo of 2013)

During the years I worked enough with Javascript, on doing apps and libraries for Firefox OS (I also localized and extended a book), writing a lot of browser extensions, forked a module for NodeJS to add new stuff, created and maintained for years a yeoman generator published on NPM.

I used a lot also on work from jQuery (and vanilla), CoffeeScript (that I still like a lot) and recently a bit of Vue (in the past I worked also with Dart).

So I am not the most addicted JS developer on earth (luckily) but I am also not the last developer that is starting to use JS.

In the last years there was a huge grow up of people that write JS and use it everywhere also when is not needed at all.

I remember once a startup website, that was broken because I was using Adblock that was blocking Google Analytics with a crash of the page.

A bug break everything

JavaScript is an interpreted language like PHP or Python, the problem is that everything happens on the browser and is easy to break.

Languages server side can handle better errors and in case can do redirects to a 404 page, in JavaScript you can get a blank page without any hints of what is happening.

Maybe a connectivity issue, a browser extension (that now are very commons), something didn’t test because of the strange combo can break the user to use your page.

As the Murphy’s Law (that every developer knows) say: “things will go wrong in any given situation, if you give them a chance.

With using JS for everything on your website, you are giving an opportunity very big to any situation.

I remember when I forgot a password but because the web page was in Angular I could retrieve that because was in the page memory, without the need of change it.

https://twitter.com/glueckpress/status/1116814841266802689?s=19

Easy to alter

JavaScript is clear in the page and is easy to inspect and alter everything, from online games (if they don’t have a lot of controls) to other kind of applications.

This is very helpful when you are doing browser extension, but there are cases that expose information, like find the right question in a test because this data is a HTML attribute (in this case I am talking of Teachable, but I don’t know if in the meantime they fixed).

This means that you have to implement twice check in frontend and backend because the first rule is: “don’t thrust your users“.

I remember a self-xss in WordPress dashboard (with no interests in fixing) because require a sanitization.

Sanitize HTML in JS is not easy

Probably you don’t know but the Mozilla Addons store is stricter compared to Google. The second one is like an open door, the first check also what are you doing with your code about data, sanitization and privacy.

One of my browser extension to get approved on Mozilla marketplace required to clean up inputs from the user with dompurify, and you probably never know of that library.

Mozilla keeps a repository to track hashes of JS libraries, because a file name is not enough to thrust the developers. There is a hash check of javascript library so the marketplace can validate every extension uploaded.

Think about all the web apps in JS and if they are validating the input serverside or on frontend. A browser extension doesn’t have the first option but in a web app this can be heavy for resources.

Do you know that Slack used React in development version (I don’t know right now if they are still doing that) that is more heavy?

JavaScript is expensive for your device

From a sysadmin side this is better because we have our lovely server with less stuff to do but sometimes it is better that something is made by the server. Serverless has no meaning, after all your data lives somewhere and you need to access them.

Slack is the best example because is heavily used, made in JavaScript and you are often using the client with many workspaces. At the time I had like more than 10, this means that the client was taking more of 120mb for any of them.

For that reason I switched to Rambox that is less heavy and removed a lot of workspaces useless. At the time of IRC but also of Telegram with native client this problem doesn’t happen.

Promote your webapp or software like multiplatform because now with Electron you can do everything you want is like a hoax.

Also, we have to think that on mobile when the browser is in background is still working, so if you are doing ping/heartbeat or a lot of servers request is still doing them. With a lot of battery consumption as example, also when you are not using the browser.

I remember when there were static generators…

Write in markdown and generate a HTML page

Years ago there was a lot of hype around Jekyll, with people abandoning WordPress and moving to markdown on git and generate static pages of their website.

Because they wasn’t need a webserver with a database, maybe also for safety. At the end it is used for blogging and gh-pages.
Maybe because they don’t have money to buy a hosting but a cool domain with a TLD that costs 3x a basic plan, no problem.

This is sarcastic and maybe doesn’t fit with JS but I have another news for you.

There are new technologies that require a server, with a JS library to rendering the data from Rest as example and lately generate a static page.

There are technologies where you can put, JS code on HTML that is available from the HTML source but on runtime disappear and parsed.

I remember when there were the fights against spaghetti code and new patterns like MVC were the real trend, and they were right, better dividi et impera to organize code easily also for newcomers.

Seems like reinventing the wheel because now seems very cool but with forgetting what happening in the past.

 

Electron is not a workaround for multiplatform

As Linux user I see that promoting an app as multiplatform but instead is a webapp built web technologies as hoax.

OSX and Windows are everywhere, and they were the primary release platform. When a company/project was doing a real native software for Linux was a victory for a lot of reasons.

With Electron, we saw that for a simple app like a music player we have now like 500mb of NodeJS modules. Multiply for every electron app you are using and you will have a pc full of crap and also vulnerable.

And remember that browsers are expensive for ram usage, so have many of them is not the best option, also for your battery.

There is a reason if in Google they started to work on Carlo (that despite to the Italian name) seems to be a solution to create fewer problems.

Also, we have to consider the issue of a silo of the same engine for the web with a high fragmentation, basically not healthy for internet.

I remember a time of multiple pages easily to open in more tabs but often in JavaScript this doesn’t happen.

I love tabs and the middle click of the mouse

With JS History api is possible to create fake URLs that not exist on the server but are built in the page by JS itself. Often when you bookmark them sometimes doesn’t work because the page itself doesn’t exist at that moment and need to be generated on the fly after a process.

At the same time when you see a link (you know that with a hover the browser shows to you the URL where is pointing), you can open as new tab but instead there is a JS event that block you to do that. So you need to open two pages in two different tabs and do a similar flow to get the pages you want to have together.

This creates problems on caching stuff as example, because means that everything need to be evaluated on the fly. Sometimes seems that I am only one that cares about caching.

I remember a time when with static pages was possible to scraping but now you need a browser.

Everything is static, at least at first glance

Search engine like static stuff because is easier to analyze and help their users to find what they are looking for.

Now we need to write webpages in JavaScript, create a server that execute all the JavaScript and generated a new page that is static just for them. And often this server is a browser headless.

Create a website that need to be public without static stuff can be an autogoal.

Automatize stuff is for a niche audience (like me) but with static pages is easier and fast for resources instead use every time a browser. You have no idea of how much sleep you need to use because a server sometimes is slow to respond quickly when you do a lot of requests and JS to elaborate them.

I remember a time when I saw one of the most horrible things a dev can see, an anchor with inside a button.

JavaScript can be used for horrible things

When I was developing my browser extension for Facebook (available only on Firefox because on Google is under DMCA), that remove outbound links I did this discovery.

They write anchor tags for buttons but inside they put buttons with listeners for events. Something that every HTML validator can never image.

Yes, HTML validators exists and is better to avoid errors for issues with CSS and strange browser configurations. Also, to not fell yourself so dirty when you go back at home.

You have no idea how many hours I spent on debugging stuff because the HTML wasn’t standard, like your_value[0][number] and your_value[0]number.

Guess what of them is valid for JS as selector (in my case was for the name attribute) but not for HTML forms, when you are doing a patch to another library and discover this.

I remember the time when nodejs packages had malware or abandoned by their maintainer.

NPM and Node_modules (DLL) Hell

During the time of Visual Basic 6 (yes existed, it is not a nightmare fictional story), there was the DLL Hell.

In other words every tool was using the same library but duplicated so a lot of files that maybe creates issues or in case was missing there was a crash.

This is one of the reason why I hate NodeJS cli tool because they are not compact and have a lot of dependencies.

Now to download a simple cli tool is required to have a lot of space and wait to download everything. Compared to Python or PHP this is a big problem.

There is also the issue of Dependency confusion that is a new kind of attack to inject malicious code by public package.json files that include private packages.

The problem of this are developers that choose to use this technology that as we said is heavy as performance (after all require a browser engine) compared to other solution.

https://www.reddit.com/r/commandline/comments/bevgaf/forever_a_simple_cli_tool_for_ensuring_that_a/el8vyma/

I remember when there was a conclusion in this kind of ranting articles.

This is a rant for good

You can think, after all you are saying that JS is horrible but there are also other languages that are not so good and you can do horrible things with them.

Yes of course, the point is how much is spread this “do horrible things” with other languages?

Right now this happens only with JS (with PHP luckily this is happening only on legacy stuff) and the reason is that people don’t see the big picture.

The big picture is see the web page as it is, not as something that you are writing from scratch without consider how a web page works.

There is a reason why exists these books, because JS is a language that evolved but wasn’t planned from the tech side (Brendan Eich tried to implement Lisp instead of Java).

As every technology that exists, it is how we are using that demonstrate if we are doing in the right way from the code to UX also in stuff that often are not considered UX (like URL usage).

I am not the best JS developers, but I am not the only one that rant about it, and I am not saying that you should stop developing with that.

I am saying, check what you are doing because you can do it better from a lot of sides.

Yes, maybe I am too old school (also if right now I am 28 years old) and I have nostalgia of the past. This doesn’t mean that the today cannot be new and different, just remember the whole picture not only your page but your users.

Yes, a lot of things written in this article can be true for other languages, in JS this happens more often and clearly in your browser.

I am one of the people that when see a CLI tool written in JS with NodeJS, close the tab and look for something else (for the various reasons already explained).

Write this article required more than a month of ideas because include only the stuff that I can remember without looking on the internet, because probably I can find more stuff that promote my thesis.

Sincerely a developer (that still writes in JS) and love the web maybe more than a lot of people.

Liked it? Take a second to support Mte90 on Patreon!
Become a patron at Patreon!

2 thoughts on “You cannot use JavaScript for everything!

    1. Depends on the context of course but use it as de facto solution for everything as explained in the article it’s not the case.

Leave a Reply

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