Do you remember the time when we all wrote our Front-End apps, oh I actually mean Front-End for our apps, like this…
If you don’t feel at least a bit of nostalgia when you look at code from above, then lucky you!
For us old noobs, that was the way to go.
For crying out loud, all available tutorials were implemented in such way. There was no Udemy, nor people like Kyle or Eric Elliott and Mattias Petter Johansson to show you the light. Even I wasn’t me, instead I was some tall high school guy who dreamed to play in NBA.
Trivia: That abomination called W3Schools had “document.write” in their examples until recently…
As a result of all that, HTML / CSS / JS were tightly coupled in 1 HTML file. It stayed like that until each one of us didn’t experienced revelation called external stylesheets.
I clearly remembered how I was proud of myself when I learned about DRY principle, and how I thought that placing styles and javascript code in external files is how you follow it.
Time is ticking away… Years started to pass
IE6 died, I was happy.
OOCSS came, I was happy.
OOCSS died, I was happy.
MVC came to JavaScript, I was happy.
MVC was kicked out of JavaScript, I was happy.
jQuery is still around and that is just fine.
Then things changed, this.time for the better.
Somebody at Facebook realized that they hit the wall in major optimization of traditional back-end. Which forced them to rethink alternatives (Leaving things as they were was not a choice. It was risky and expensive, if nothing else).
Eventually, as result of that effort React was born.
But before that happen, Component Based Development on Front-End came to somebodies mind as an brilliant idea!
Ok, React is obviously great, additionally platform that surrounds it is awesome. Still no matter how funny and true; this xkcd comic may be I am Very happy that Evan You decided to introduce new framework that solves problems which were already (almost) solved…
Now lets recall how we began this article. Remember that ridiculous 1 HTML file with HTML / CSS / JS in it?
Oh yeah, that code is how we do it today :), weirdly enough it’s also how we did it back in the day… Still not the same, oh how much it’s not the same.
There is a reason why MVC died on Front-End. It just was not able to support Component Based Development as it should be supported.
Scalability is the tough word, and it’s almost always part of sentences that end up with “?”.
Except when we talk about Components, more precisely VueJS components.
No matter how much we oppose it, everything is coupled. It may be tightly or loosely, that’s up to you. But still, if we talk about the WEB, then there is no technology that can work alone.
Creators of VueJS obviously got tired of calling it HTML / CSS / JS and renamed it to Component.
Vox populi
As you can see, if nothing else people are asking the Google what is this VueJs all about.
Additionally github repo of Vue is 3rd most popular JavaScript repo when we compare them by number of stars…
Tired of guessing what the hack is this?
You know that framework is thinking about you when it automatically handles binding of this (if you still have trouble with this in JS checkout: What is ‘this’ in Javascript? Explained to the 5 year old, literally).
VueJS proxies this throughout its methods.
That means that we are able to access all of our data properties from anywhere in the Vue instance (with exception to vue-resources AJAX helper and similar things)…
So if you are tired of binding this, or even worst, assigning it to some variable, then welcome to Vue!
Watch-out, because properties are not dead
Framework is as good as much it solves common general problems, that would otherwise have implementation on level of each app.
With that being said, we can find VueJS watchers extremely useful.
If you need to execute some code logic, when ever some of your data properties change, watchers are the way to go.
Watchers cut the codebase size quite a bit.
Best part is that if they aren’t needed you just don’t use them.
Trivia: I am sure that React people will say, Yeah but watchers come with price which is payed with performance.
Good framework is a gentleman, who helps you to modify events
VueJS implements few very useful event modifiers.
.stop call event.stopPropagation()
.prevent call event.preventDefault()
.capture add event listener in capture mode
.self trigger handler if event was dispatched from this element
.{keyCode | keyAlias} trigger handler on certain keys
.native listen for a native event on the root element of component
.once trigger handler at most once
Two-way is sometimes the way to go
The main idea behind Vue (if you ask me) is to provide support for lots of features and let you choose what you actually need.
v-model directive makes two-way binding between form input and app state simple and quick to implement…
Check it out in action: At VueJS official documentation (which is awesome btw.)
Every serious Tool needs to have it’s Chrome dev tool
For those of you who already worked in React, it’s obvious how handy React dev tools can be.
Vue will not disappoint you, since it has Chrome Devtool. extension for debugging.
Check it out at github repo.
Buzz words
I hope that I managed to sell you the idea of Vue and that you are at least interested enough in it to check it out, play around with it and fall in love.
At the end I would just like to add that VueJS implements Virtual DOM.
It can easily be configured to use LESS or SASS.
If you prefer JADE more than regular HTML, that will work almost out of the box…
Need styles encapsulation, it’s just a matter of placing one flag!
VueJS is all about freedom of choice, that is why I love it and why you should try it too.
If you are reading this it means that you are curious and passionated about JavaScript and Front-End in general. That makes two of us!
Consider joining me on this adventure of discover by following me here, maybe clicking that heart or checkout my twitter account https://twitter.com/develoger
Once I hit 1000 followers on the blog I will share the prizes (public draw) -- 2 yearly subscriptions to https://egghead.io
