I have been using jQuery for quite a long time. Then Vanilla JS, as is so elegantly called the natively-implemented JavaScript. I have always kept an eye on Knockout and stuff, but without ever really investing in it. That was also the case with AngularJS, which was supposedly a game-changer, since it was on everyone’s lips! “An MVVM tool”, one would say. A whole new outlandish language to master, when I was just coming to an in-depth understanding of an MVC(2) architecture. No thanks!

I need to tell you something: for my part I have always sworn by the separation of roles. I would not go back to HTML mixing structure and behavior, with invalid W3C attributes and poor source code. It kept me thinking that jQuery and Vanilla JS were safe bets.

But still. I ended up investigating AngularJS, after seeing it featured in another articles in my news feed. It turned out that the main drawbacks I reproached it could actually be solved with a little rigor. But why put so much effort into using the latest trendy tool, when jQuery had always done the job perfectly?

I partially understood the interest in using MVVM thanks to my personal investigations on Aurelia, React, and then Angular. But it seemed that I had just found the ultimate reason to drop jQuery thanks to the study of… Vue.js. I got the whole point of using it in a single afternoon of reading. And I can tell you that I only swear by this library now!

In short: jQuery is DOM-driven while Vue is data-driven. And that is the big difference!

IT ALL STARTED WITH JQUERY.

I can tell you that I was a big fan of jQuery. Its JavaScript library has helped me become what I am today: a passionate JavaScript full-stack developer. Back to the time when I was developing some websites just for fun and without any professional status, I only swore by jQueryamong my PHP files and my $.ajax calls. However, I abandoned PHP — which was beginning to be adored with a concrete object syntax — in favor of a more front-end specialization. I was fascinated by the flexibility of jQuery.

I wondered how it was possible for jQuery to be developed with… JavaScript?! My only experience with JavaScript at the time was some “picked” scripts on the JavaScript Editor website. Those were edited through hours of “hacking” to avoid various errors between browsers. Exhausting. To me, JavaScript was an awful language and I hated it. But this jQuery was simple, elegant, quick to proceed, simple, distinct from HTML, with thousand of plugins, etc. And again, it was so simple.

With HTML for design, CSS for layout and jQuery for actions, I found there a tremendous way to develop by separating the different roles without ever mixing, so that with one single HTML I could come up with different interfaces (CSS/JavaScript).

In order to keep up with the back-end, I obviously studied programming (actually Object-Oriented Programming) with Java at school and C# in my different jobs. These are languages that I respected for the rigor, the complexity and their philosophy of implementation. But jQuery was too versatile, elegant and simple not to stay my favorite. If I had to do something solid, it enabled me to do it. And unlike other back-end languages, jQuery was a perfect answer for more simple projects too.

jQuery had become so comfortable that it was hard for me to get away from it, and even imagine that other libraries could possibly do better.

It had permanently diverted me from PHP, then C # and Java. I kept wondering how such a great library could have been developed in JavaScript, the only language that I could not stand!

THEN I DISCOVERED AGAIN JAVASCRIPT

I had to roll up my sleeves to acquire a deep knowledge of the foundation of JavaScript. The key to comprehension was to understand all the potential of its asynchronous language, along with its ability to pass a function as parameter. Whatever I intend to do, I can enter the function which will directly operate this task, no matter what time it may take. This feature is purely amazing, but not actually “created” by jQuery. Indeed, this behavior was enabled by closures and the fact that higher order functions were… objects itself?! And this poor language with no capability of casting had, in fact, a weak typing system and used coercition to automatically modify type on the fly.

JavaScript was so much more interesting than I initially thought. It combined a considerable amount of concepts from several previous languages I had studied. By studying the native DOM API which is implemented in all of the latest browsers, I ended up realizing time had come to say goodbye to jQuery. In the end, this marvelous toolkit was a launch pad to understand the JavaScript through the right spectrum (and with more ease). After all, it was just a matter of courage.

So I opened my door to Vanilla JS, and I convinced myself that Native JavaScript, with its little libraries and polyfills used just when needed, was the key to my redemption.

With this fascinating revelation, I couldn’t have started a more complicated relationship with AngularJS!

ANGULARJS, NODE.JS, REACT, ANGULAR: ALL EGGS IN THE SAME BASKET?


I missed back end development. I was then dependant of my C# expert colleagues to finish a complete website. My short excursions with CodeIgniter or Laravel — while re-practicing some PHP — really made me realize how much JavaScript « magic » lacked in other languages. Nonetheless, it seemed we could do some JavaScript… from the server’s side! It was more than enough to make me switch to Node.js, when it was still at the very 0.1x.x version. I was forced to swim amongst the various resources attributed to the early versions I had found. It turned out to be a real challenge at first to distinguish what truly belonged to the core of Node.js, from what belonged to these npm packages such as Express or even middlewares from the incore of Express.

The learning curve — even if not so complicated with my JavaScript background — made me realize that Node.js needed a little boost to allow the front-end developers, « stuck » with jQuery or PHP and wary of JavaScript, to get started. That is the reason why I developed the NodeAtlas framework which, unlike its competitors, was meant to be evolutionary in its handling by progressive iteration, and quite close to a PHP architecture in its approach. Of course, by digging the framework as and when required, it is possible to fully embrace Node.js and its modules. Indeed, it was possible to get a powerful multilingual website for production in a jiffy, without all the harsh words found in the ecosystem of Node.js, Angular or React, such as gulp, grunt, Browserify, webpack, Babel, Bower, etc.

ENTER REACT


Along with AngularJS (which was about to become Angular quickly) came React. React enabled developers to generate server content using, I quote, « its virtual DOM ». Wait, what? Was React actually a competitor of NodeAtlas, conceived to operate server-side JavaScript? Or perhaps an alternative to Node.js? And so Facebook was developed with that? Wasn’t that supposed to be an alternative to Angular? Why is there only JavaScript and no HTML in the examples? And what is JSX anyway? The more I dug the JavaScript ecosystem, the less it seemed that I knew about it. I wondered if with all this new JavaScript complexity on client-side, server-side, “mobile-side”, “what-you-can-imagine-side”, … I would pull through in the end. The good ol’ times spent with my jCertainties were a long way off, and that really scared me.

The JavaScript ecosystem exploded at the same time as my understanding of its complexities. Today, no one hires any JavaScript expert anymore. The offers simply announce that “we need a JavaScript developer working on this, or that framework”. Based on the realities of NodeJS, ReactJS, NodeJS, AngularJS or VueJS, do people really know what they are talking about? How could non-experts do it if even JavaScript developers were lost?

THANKS VUE.JS FOR EXISTING!


Alongside AngularJS, there was also the discreet Vue.js. Unpretentious, yet fully able to compete with it. Simplicity, elegance; it stood out with a strong desire to be used in evolutionary and versatile ways. Its API was especially well defined: changing its internal mechanics in depth did not affect its external use during its transition from Vue 1.0 to Vue 2.0, giving it, among other things, a virtual DOM. AngularJS lost everyone, and forced most developers to TypeScript (not mandatory, but good luck without it!).

When React arrived with its server-side rendering via its virtual DOM and the use of JSX, Vue was still there, and could also do it server-side. In fact, Vue had been there from the early beginning, and was so well conceived out that it had hardly changed from the outside. Yet, in terms of performance, importance and learning curve, it now surpasses Angular and React! While heavyweights such as Google and Facebook are waging war, Vue.js suddenly sneaks. Plus, it is led by an independent JavaScript community. Vue is so scalable and simple that you can use it as easily as you would use jQuery. And it’s not even a trick. Vue was designed to be used sparingly on a DOM client, some interfaces and forms as well as to manage a complete client and server-side DOM and complete navigation!

TL;DR


Vue.js is to Angular and React what jQuery is to Vanilla JS! So, if you’re still standing in your comfort zone with jQuery, defending your own position, convincing yourself that Angular and React have nothing to teach you, please give a chance to Vue. js. It will not take you more than half a day to appreciate its full potential.

    Share: