As many readers of this blog know, I have been quite actively involved in Aurelia for over two and a half years now, it’s actually almost three years. You could be forgiven for thinking that Aurelia is all I work with and while I do work with it a lot, I am not close minded.
Before I worked with Aurelia, I was heavily into React. I will always have a soft spot for React, but its lack of opinion when it comes to things like routing and state management means you have to glue things together from numerous third parties until you have something that resembles a framework.
Unless you’re solving the kind of problems Facebook are solving, chances are your use-case dictates the need for something more than just a view library like React touts itself as.
Now onto Vue…
I actually built a working application using Vue just to see what the hype was all about called TidyFork. I used the Vue CLI, Webpack and also used the state management library that the Vue team ships called VueX (which is awesome and we’ll talk about shortly).
It actually took me very little time to get something working in Vue. The learning curve for the basics is quite low and the official documentation is great.
The only thing that has put me off Vue is the Angular 1.x syntax using double curly braces. This isn’t even an issue, it’s just the emotional baggage I carry from all those years ago trying to get Angular (pre one time bindings) to work performantly and not hit walls with the digest cycle and dirty checking.
There is so much to love about Vue, I can definitely see what the hype is about.
One Man Syndrome
Funnily enough, as someone who has been in the Aurelia community since the beginning we’ve had our fair share of concerns from people asking about big company backing of Aurelia. It turns out developers have the same concerns with VueJS.
Let’s get this straight: it does not matter if Vue has big company backing or not. Evan You is a talented guy who has achieved so much, and there are numerous contributors to the project if you look at Github. It’s not Evan committing everything, it’s a community led effort.
Single File Components
Vue’s single file components are awesome, there is nothing like them in any other framework or library. Essentially you have your template blocks for HTML, script blocks for Javascript (or equivalent flavour) and (if needed) style blocks for your styles.
I wish React and other frameworks/libraries would copy this feature, because you can see everything upfront you can easily reference computed values and attributes without needing to switch between files. Being able to see your entire component also makes you conscious of how big it is.
More Than A View Library
One thing that Evan did is realised that people rarely need just a view library, most people building web applications need a router, validation, a means of performing network requests and some form of state management. Instead of taking the React route, Evan created a few optional libraries.
The official routing library is great. Instead of having to glue together a heap of third-party dependencies like you do in React, you get official libraries from the Vue team themselves.
It’s Fast
I am not sure how it stacks up against React 16 Fiber, but VueJS is blazingly fast. Thanks to its virtual DOM diffing implementation, you’re able to work with large DOM’s and not run into issues caused by changing things in large web applications. Because components are converted into Javascript (templates and all) the end result is perfectly optimised Javascript.
VueX
This is the big mistake that the React team made with Facebook, not releasing an official state management library to accompany React. Although, React did champion the Flux Architecture methodology of which many state management libraries are based on.
Evan You and the team realised this and created their own official state management library in the form of VueX. Just like they did with their own router and other libraries.
Not only can VueX do everything other popular state management libraries can do, it’s dirt simple to use. If you’ve ever worked with Redux before, then you would know that it isn’t exactly beginner friendly or simple.
Conclusion
Whilst I wouldn’t completely abandon using Aurelia in favour of Vue, it definitely is in my developer toolbox. In-fact, Vue works well being used alongside Aurelia because it’s a component based library, you can embed it into an Aurelia view and pass data into it.
> In-fact, Vue works well being used alongside Aurelia because it’s a component based library, you can embed it into an Aurelia view and pass data into it.
I’ve been thinking about doing this actually. Recently used Vue for a PWA project and love making components with it. Any recommendation for using Vue w/ Aurelia? Considering Aurelia’s customizability, would it be possible to create some sort of glue to allow the seamless use of Vue with Aurelia?
Another small framework that I’ve been hapilly using for some time now is Riot.js. Riot also encapsulates markup, styles and Javascript into single .tag files which get translated into single js files. Well worth a look.
the single file components was suggested long time ago to aurelia, https://github.com/aurelia/framework/issues/342 but was prematurely closed.
About the time size and company backing, the really bad part is the time to fix bug, give answer and provide new features that a modern framework should maybe provide. I still use aurelia, sometimes it seems like the team take ages to move forward, like HMR was late, SSR is still missing and single file components maybe in 2018, with this speed in 2019. Microsoft should invest in this project to give the worthy boost.
What about Vue.js 2 and ES6 : What are your thoughts about building a scale application with Vue.js whilst using the latest ECMAScript?