THE ROOT OF THE PROBLEM
JavaScript actually does well what it was originally created to do: very small scripts that enhance the browser’s functionality. However, the appetites have grown tremendously in the past decade or so, and this is what people fail to understand. It is just not good enough for creating complex interfaces that have a high demand on resources and need to tackle very complex business logic.
Many people who know me consider that I hate JavaScript, but I really don’t, and this is certainly not another rant about JavaScript. I don’t hate any technology, I just might like one technology more over the other, but all technologies are interesting in a way. When I get to discuss my dislike of JavaScript people never seem to understand what I am talking about, so I will be selfish a bit and use this post to try to explain my position based on the fact that I am the only one writing here and nobody can interrupt me at least for a while.
The main issue I have with JavaScript is this: it kills the productivity and makes us inefficient, and also makes creating the software much more expensive than it should be. This is really as simple as that. Now I will try to elaborate.
I am talking about enterprise applications. I was in the position for more than 12 years that I had to coordinate the work of 200+ developers in order to release the code and give clients the functionality they paid for. Creating a few JavaScript lines here and there is no big deal but creating the enterprise applications is just a whole another beast. When we are in this domain, then I fully understand that JavaScript is simply bringing us down, because it is like a loose cannon and you never know where it is pointing and when it’s going to go off. Or when it is not going to go off.
I am not going to discuss about the inefficiencies of the language itself, they are very obvious to all knowledgeable software developers and there is no need to talk about the obscure syntax, no types, no block scoping, no classes, inheritance with prototypes, no compiling and many other shortcomings. You can find many articles discussing those, but that’s not even the point since JavaScript was not created for making enterprise application, but for enhancing the browser’s experience, and that is what it does well. The problem here is that I need to deliver a value to the client, and in that context, I have to be professional and use whatever gets me there to create the solution for a specific client’s problem and to deliver it with high quality, under the budget and on schedule.
This is the most important thing: deliver the software that has a value for the client, and that has been delivered with a high quality, under the budget and on schedule. And JavaScript just does not let me to do that.
Now I did not come up with this quality, under the budget and on schedule, it is actually from the IBM, and I really could not agree with it more, but let’s see what the consequences are. The major consequence is that I cannot use tools or technologies that deprive me of doing my work to deliver quality and on time and under the budget. It’s like if you were a construction worker, you would sure use only the tools from your toolset that makes you get the job done. Some would say they like JS because it is fun for them. It would be great if I could do work and enjoy it all the time, but that is just not the case in life. Yes, I love to use technologies that I enjoy, but often we just need to do the dirty work, and there is a lot of it. Somebody must do it. Nobody likes to do it, but hey, that’s why you get paid for doing it, right?
Now this discrepancy further exacerbates with the influx of millennials who, for some reason, believe that they should not learn too much, they should have fun at work all the time, and they should get paid great salaries for doing just that. The whole industry is in a great shape now and we are lacking software developers and many other positions, so they are able to find a job with that attitude, but that still does not mean that this kind of thinking is right. I am certainly not advocating that programming should be all sweat and tears, but a healthy dose of masochism is what I find very often with good developers and expecting that you will have to work hard is a good thing I believe. I don’t know, maybe a generation gap. Anyhow, just because using JavaScript is easy and you can learn it in a few days, does not mean you should abuse it everywhere and not being interested to learn new technologies and ways of doing things. Or vehemently defending JavaScript from any type of criticism. And there are so many new and exciting technologies today, that it is really a great time to be a software developer. But the JavaScript story gets even worse….after doing front end with it, they again don’t want to learn anything new…JavaScript with a bit of HTML and CSS is all they will ever need, and then they use it for the backend as well. I mean, if you have finally made it to the backend and you can do whatever you want to do there, in C# or any other language, why in the world you would confine yourself in Node typing JS again? That just makes no sense.
Back to the context, which is about delivering solutions to clients that help them do their job better. Using JavaScript simply means that there will be too many errors, the language itself is very loose, no types, no compiling, and then we would usually use a lot of testing and different environments trying to test if the solution works properly under various conditions. Then on top of that comes vary uneven support for various standards in the browsers, and as the result even more testing is needed because if it works in FF that does not mean it will work in IE, and then in which versions of those browsers exactly? We are spending so much time and money to get it right, and as the result clients are asking why the hack does it take that long to get it to work? And they are right.
Should we even talk about SPA frameworks, such as Angular, React or Vue, a few of the most popular ones? Just today I have checked the Angular again. Used CLI, ng new and ng serve….what I got was a Hello World application with just a couple of labels, and node_modules of around 225 Mb, with 28.000+ JavaScript files in around 3700 folders! The next thing I am fighting Visual Studio since it got stuck because it cannot show that many files, so go to folder, make it hidden, etc.
And then I know what comes….first thing when something does not work it will throw some 3 kilometers zone error, which does not mean anything and you will have to just think what have you been doing since the last save and grope in the dark trying to make an educated guess on what has gone wrong.
Is this really the right way to create client-side applications running in the browser?
SO IF NOT JAVASCRIPT, THEN WHAT?
Fortunately, there are people understanding this and they have already made some attempts to rectify this situation. There are various approaches, but I think transpilers and using WASM are two of the most successful ones so far.
Transpilers Microsoft created TypeScript which you can use to create classes and to use strong types, and then it just transpiles it to JavaScript. So basically, you do not need to type the JS yourself, which is a great help. There are other tools that do the same, for instance CoffeeScript and other ones.
WebAssembly (WASM)
The other approach is rather new and is based on the WebAssembly, which is a binary format that can run in the browser’s virtual machine. WebAssembly, or WASM in short, is not created so that you can code in it directly, but rather it was created to be a target for compilation from different languages. For instance, you can use Emscripten to compile C or C++ files to WASM module, and then it takes some JS glue to actually run the code and manipulate the DOM. This approach is such a huge step toward having a better and much faster execution in the browser, since more and more languages are going to add support to it. Microsoft has already started doing that with Blazor, and they have made a huge progress already.
The additional advantage of this approach is that we do not have to parse huge JS files and process them, but using the binary format we are already 25 times faster, or even more.
The support for WASM exists for all major browsers, for version from the beginning of 2017 until now, and will sure continue in the future.
You may ask: “Why would anybody ever want to write a client-side web application in C or C++ or C#, when you can just use JavaScript?”. Well I have explained about the inefficiency, testing issues, the language itself being sub-par, and ultimately very high costs of writing such applications in JavaScript, but there is much more. We forgot about many other types of applications that will use browsers as the target, that simply has to be written in other languages that are much more efficient as programming languages as well as at the execution time. Such applications running in the browsers are: 3D games, Virtual Reality, Augmented Reality, computer vision, image processing, and many others. You cannot make that in JS.
This, in my opinion, is great and will ultimately change the way we code client-side applications in the browser, but it is only half way there. It still uses some JavaScript glue to make it run in the browser. We can be pretty sure that the importance of browsers will not fade away, since I do not remember when was the last time I saw the classical windows application, or WPF one, except for the legacy ones that need to be supported. The browsers are there and will remain the main vehicles for running the applications, and those applications will be even more complex and demanding when it comes to coding as well as the execution performance. In my opinion, in the future we will have to converge on creating a whole new virtual machine running in the browser. Right now, different browsers use different virtual machines to run JS code. For instance, Chrome uses V8 engine to compile JS code. It was written in C++, and compiles JS to a machine code, not as other virtual machines that are just using the interpreter, which makes it somewhat more efficient. Other browsers have similar approaches. Mozilla, for instance, started with SpiderMonkey engine back in 1995 that had interpreter, JIT compiler and garbage collector, but they also produced Rhino which is again JavaScript engine that converts JavaScipt scripts into Java classes, and can work in both compiled and interpreter mode. Gecko is the layout engine, produced by Mozilla again. IE and Edge uses Chakra, Safari uses WebKit, and so on. JavaScript engine and browser virtual machine are terms most of the time used interchangeably.
In any case, I can bet that the future brings us pure excitement, and sooner or later it will end up with us writing the code in any language we are comfortable working with, and then compiling to WASM (or some other binary format of the future), and without and dependency on JavaScript it would just be compiled and ready to manipulate the DOM directly. Then, and only then, will we be achieving a maximum efficiency when writing client-side applications on the enterprise scale.
CONCLUSION
I tried to communicate the challenges that I have observed with JavaScript for many years when creating enterprise level applications. My intention is not to cause any heated debates about this topic, but to simply try to convey some of the real-life challenges I have experienced in my career and why, as a consequence, I believe we need to strive for creating much more efficient tools for creating the client-side browser applications.
