The programming world has always had its share of opinions. Our community loves debating everything from tabs vs. spaces to Vim vs. non-Vim to which frontend framework you should use. For me, the answer almost always comes down to: “Whichever, so long as it’s consistent across your project.” End of article. Thanks for reading!
Wait, why are you still here?
Shouldn’t you trust the advice of a random programmer, writing an article on a company blog? If not, I guess I’ll have to explain myself. Here goes…
As I said, the answer to most programming debates comes down to context and the team doing the work. At MichiganLabs, we’re often asked to recommend a front-end framework to program in. Until recently, React and Angular have been our go-to solutions. But over the past few years, Vue.js has had a surge in popularity, and so we gave it a shot (this blog
post documents an interesting attempt at estimating how fast Vue has been growing!).
Since taking the plunge, it’s become one of our most-recommended frameworks. Here are a few reasons we like it along with a few caveats (because nothing’s ever a perfect fit).
While React and Angular come as full frameworks right from the get-go, Vue’s relatively lightweight library can be slotted into an existing site. Each has its advantages, but we’ve found that Vue is easier to pick up. So, even though we almost always use Vue as a full framework, onboarding new team members who haven’t used it before is straightforward and quick.
Officially Supported Libraries
Concepts like state management, routing, and observables are becoming widely adopted in web frameworks. However, React and Angular have decided to leave many of the implementations of these patterns to their communities, opting to focus solely on core libraries. Vue, on the other hand, has chosen to make official implementations—contained within different libraries—allowing you to pull them in as you see fit. While the React and Angular communities do a great job of maintaining these important libraries, it’s nice having so many key components designed and maintained by the same organization.
If you’re not up to speed on computed properties, they are functions that return a value that you compute based on other properties, which you then can call as properties instead of functions. For instance, you could have properties A and B, and a computed property C that returns A+B. Instead of calling C(), you simply use C as if it was a variable, knowing it will always return the correct value of A+B. The primary benefit of this is that computed properties’ values are cached based on what properties they depend upon. If you call a computed property five times but the values it is computed from never change, it will only be computed once, as opposed to using a regular function that runs every time it’s called. This specific optimization is missing from Angular and React (not to say that Angular and React are slow). If you use computed properties heavily with inline HTML logic, there’s also the side benefit of making it far more readable.
Fits Our Preferences
Up until now, I’ve laid out some basic reasons our teams prefer Vue over other frameworks, but as a tech lead, I also have my own personal opinions.
The first that comes to mind is Vuex. Out of all the state management patterns I have used, Vuex is my favorite. It does what it needs to without being cumbersome like other state management libraries such as Redux. Granted, it could be that I was using Redux when I shouldn’t have. However, things like Vuex’s less verbose boilerplate code feels better to me. If you’ve ever bounced off Redux, give Vuex a try.
Vue’s design is another benefit. The first big web framework I worked with as a web developer was AngularJS. It was incredibly confusing and obtuse. I hated it. The fact that I was still learning web development likely added to the confusion. But after working on countless websites and frameworks, my opinion stands.
Now for the Cons:
Vue doesn’t enjoy the same large communities as React or Angular. If you run into issues or have questions, you won’t have as many Stackoverflow threads to frantically scroll through. Add to that not having as many community-made components and libraries to pull from. That’s not to say they’re non-existent; there’s certainly a good amount of community support out there still. Fortunately, I haven’t run into any egregious problems in my time on Vue. It’s just something to keep in mind.
Another thing to consider is that Vue’s class-based components are not the default, and are
slightly less efficient than the default method of creating components using objects. With object-based components being the default, a majority of the code examples in Vue’s documentation are written using them…which also means you can no longer copy/paste example code into a class-based project while learning.
In the end, I find these trade-offs worth it. Writing Vue with class-based components feels so much better than the default object-based method. Plus, I’ve never had trouble figuring out how to convert code examples. However, if you prefer the object-based components, that’s great! Your favorite method is also the more efficient one. But if you share my preference for writing classes, just know that it is slightly more inefficient - keep that in mind when you decide which component style to start a project with.
To be clear, I believe Vue.js, Angular, and React are all solid frameworks. You really can’t go wrong choosing any of them so long as you have a solid grasp of web development concepts. For those reading this post who have never tried Vue, if there’s something I mentioned that resonates with you, I say give it a shot! I wasn’t expecting to like Vue as much as I did. Maybe you’ll come away feeling the same way.
If anyone out there wants to share their own experiences on Vue, please feel free to chime in. Good or bad, I’d love to hear your thoughts!