In my article, I explained what a web developer could do.
Richard Kenneth Eng

“ The message I’m trying to hammer home again and again is that JavaScript is a dangerous language to use. If you have the choice (and you do), you can use safer languages. Why wouldn’t you?”

I understand that JS is a flawed language. I didn’t actually use JS before until it matured enough (or actually, the elegance and the ability of the browsers have matured) to the point that I can manipulate the DOM easier than just using document.querySelector(‘#this-element’).innerHTML = “new content”.

I agree there are safer languages, and I could have chosen one. The question of why wouldn’t I choose one is at least simple for me: it adds another task to my build and another complexity to my team.

I made a mistake before of switching one front-end framework to another just because the other framework is better in terms of code elegance, better code management, etc… in the middle of trying to ship the MVP. If the team is fast in getting “how things clicked” on the new framework, then it wouldn’t be a problem. But they are not and I have to use up a lot of time re-training them just to use the new framework.

And now we are thinking of a change of language and not framework here just because Javascript is flawed and some other language is better. People would have to take time to learn a new language (even if they have encountered it before). And even then, by the time a lot more people invest on that new language, we don’t know if that language will be there in 3–5 years. Just look at Actionscript for Flash, could have been nice…

And here comes this additional task. We already have tasks for trying to squeeze in every bit of performance from it. From concatenating, to minifying, to optimizing, to code-splitting, to lazy-loading, and making these code available offline. Where do people now plan to put the transpiling? How do we make sure that the transpiled-code is minified or optimized or even split in the right sections or lazy-loaded? Isn’t that just putting more burden on the team to decide which part to put using the safer language, and which to put on Javascript? (I know I may be naive on these, I only know that adding coffeescript as part of webpack would be enough, but I don’t know about others, so please forgive me).

The thing is, even if some language is better (much like Java was better than C++/C back then when I was still in college), these additional tasks of transpiling code to Javascript has taken its toll (see Javascript Fatigue), and browsers will still show errors in Javascript, which needs you to add specific tools for the safer language, so that you can debug them without the additional cognitive load of mapping the error to your language.

The real problem here is that Javascript, with all its flaws, must adhere to the main rule of being a web standard — that it should be backwards compatible. That means a Javascript code that works pretty much in the late 90s should still work now. That also means that even if that code wasn’t that elegant before or flawed or “inferior” to other languages, it should still work when run by modern browsers. Yes, there are deprecated functions but it still stands: it should be backwards compatible. That’s not the case with all the safer languages that cropped up because of the “inferiority” of Javascript. If we want Javascript to be safer, we would have to break this tenet, and have all browser vendors agree and create a better version of JS, each agreeing that this is the way to implement and run JS code in their own browsers. It is like saying that Windows, Linux, and Mac should agree how ASM should run in their hardware.

For me, safer languages that are just an alternative to JS on the front-end doesn’t do much. They are just “special kind of linters”. It just scopes up the good parts of JS so that developers will not use the bad parts of JS. I agree on the additional cognitive load that will be added to people trying to learn the good parts instead of just using safer languages. But we are just shifting that focus from learning the good points to something else, and it doesn’t change the fact that these will just be tools for developers who want to implement code that is manageable for them.

To answer your question though: I guess for me is that Javascript has matured enough to manipulate DOM in an easier way, either via Virtual DOM, which Angular and React follows, or using Shadow DOM, which Polymer and Custom Elements follows. The web has evolved so much that it now allows not only the use of the main thread to run javascript, but also web-workers and service workers.

For me, Javascript is the de-facto tool to create and manage re-usable components for easier manageability, and as a means to democratize the creation of useful components for others to use without the use of additional tools. Just think, now we can define tags like <app-router> or <image-carousel> and scope the javascript control on the tag without messing other parts, and then share it to others who might find it useful. I think that’s the reason a lot of people went back to Javascript (after the success of Angular 1) — that there’s an easier way to create a front-end app-like behavior and make reusable components without direct DOM manipulation that is unpredictable and “un-testable”. Also think, javascript is single-threaded but now we can delegate it to web-workers. Javascript can also act as middle-men servers for offline purposes via service-workers. Right now, Javascript already has those functionalities set.

Which puts me into this other point: any additional functionalities added in the Web through Javascript would have an effect to JS-alternative languages. That is because people will need to update the transpilers to accommodate these additions. We are just shifting the burden of making sure the transpilers, again, scope up the good things on the new JS and filter the bad to them. And either we wait for some good documentation to be spun up by others on how to do them in our own JS-alternative language (and auto-compile them if it should run in a service-worker or web-worker), or we do it on our own… to think that it is already existing in Javascript. And if we really want it badly, then we just go back to Javascript to use it, which breaks the point of using safer JS-alternative languages as our de-facto language of choice.

Don’t stop though (and I know you won’t stop telling how bad JS is). JS is bad, but it will stay, at least for most of the foreseeable future, as a W3C standard. And people will still try to make it better. And people will still make more features for it (see VR). If you want anyone to stop using JS though, you can try and submit to W3C to add an additional language for anyone to use. Much like an RFC for WebAssembly or for adding routing and data-loading just by the use of HTML. This way, the discussion evolves from just pointing out bad things in a standard language to opening up another way to implement code using an elegant language.

Going back though, regardless if our front-end code was coded in a safer JS-alternative language or hardcore JS itself, it’s all about how we improve the user experience.

Show your support

Clapping shows how much you appreciated Toni-Jan Keith Monserrat’s story.