I recently decided to rewrite an Ember.js project I have worked on for several years in Vue. It was quite a big decision so I’ve decided to write about why I chose that option here — hope it is useful to someone out there.
This is the project I am now implementing in Vue:
It is an admin panel to manage various settings of my open source website builder for the real estate sector. Quite a simple project to start with but it slowly got more complex than I had anticipated. In particular I struggled while using ember to find a good way to allow rolling back unsaved changes.
The first thing to say is that I by no means think Ember is a bad framework. It is great in many ways and the community around it is particularly outstanding. The guys developing it are pretty smart and they are probably right about a lot of the conventions that they push. Truth is though that I found it very frustrating each time I had to change the way I wanted to do something because of an Ember convention.
In spite of my many years of frustration with Ember, I was quite reluctant to change to another framework. JS frameworks are so fickle that I knew I could spend a year with some other framework and then find there was another one that turned out to be even “better”. Because I was working on an open source project, an important thing to me was that a framework had a good community around it. I want as many people as possible to use and contribute to my project.
For a few years it looked like Ember was the framework of choice for great open source projects. One of the main reasons I chose to use it was because it was being used by the discourse project. In the last couple of years though I have noticed fewer open source projects using Ember.js. This is one of those observations that result in very strong pushback when used as an argument for picking one framework over another. For one thing it is not easy to accurately determine which framework is the most popular. Plus popularity does not equate quality.
I have already made the case that for PropertyWebBuilder it was important to use a framework that was popular enough to attract collaborators. As to figuring out how popular Ember is relative to Vue I’m happy to rely on my instincts. Just in the course of talking to people and browsing various websites I have come across enough activity around Vue to feel pretty confident that if it has not already attracted more developers, it will soon. Over the 12 plus months that PropertyWebBuilder has been open source I have only had a couple of people interested in helping out with the Ember side of things. I have already had 3 people show interest in the 2 months since I started using Vue.
As I started experimenting with Vue, I noticed that quite a few UI libraries were being built on top of Vue. This really added to my interest in it! Much as I like Ember and its community, there just aren’t that many UI libraries being built on it. The best one I found was Ember Paper but it was nowhere near as impressive as any of the top 5 Vue UI libraries. I spent a few hours trying out Vuetify and was smitten. In no time at all I was able to create a great looking demo that would have taken me 3 or 4 times the effort to create with Ember.
Thus far it may sound like I get swept away by whatever the new cool kid on the block turns out to be. There may be some element of that but I have resisted shiny new frameworks before. Both Angular and React got a lot of hype at some point but I never found enough compelling advantages to either of them to justify switching. Sure they both seem to have overtaken Ember too in the popularity stakes but they were constantly changing and I struggled to pick one over the other. Neither was particularly easy to pick up and I felt that if I implemented something using either I may well find I had to reimplement a good chunk of it within a year or two.
Somehow Vue seems to achieved something no other framework before it could manage. It is super powerful but fairly easy to learn. It is quite new but feels more stable than other frameworks that have been about for years. It does not force you down any conventions but it has a great ecosystem of accepted libraries for the main things you might need — routing, animation, state management, data-retrieval etc. Quite incredible considering it was created by one guy with no large company behind it.
There is one other reason I ended up migrating from Ember to Vue. It hurts me to admit this but my Ember code was terrible. Really, really ugly. Of course I can’t blame the framework entirely for that but when I look back I find it ironic that I ended up writing such unconventional code when one of the big value propositions of Ember was that it pushed you to follow good conventions.
Here is my explanation of why my Ember code ended up so ugly — sorry if it sounds like a poor excuse, perhaps it is... Over the time that I’ve been working on PropertyWebBuilder, Ember has changed enough that I got confused about how best to do things. As an example, when I started writing the admin panel for PropertyWebBuilder, using components to encapsulate functionality was not yet the preferred way to organise things. It has since become the preferred way to break up units of functionality. With the introduction of routable components there have been even more significant changes to the recommended way Ember projects should be organised.
It is quite likely that if I was smart enough and had paid attention to all the announcements about each change in Ember I could have kept my project up to date and decent. The reality of being a developer is that you have limited time and I got super frustrated trying to keep up. Because I accepted that the guys behind Ember are way smarter than me, each time I struggled I put it down to my own incompetence. I dreaded each version release so the project is now several versions behind the current Ember release.
I want to make sure that I don’t repeat the mistakes I made with the Ember version of my project. I want to make sure I follow best practices from the start and get some community involvement early one. In the ideal case I would like it to be a reference implementation that others can learn from. It will be difficult but I’m enjoying Vue a lot right now and I’m ready to put in the effort to do a better job this time round.
I will write more blog posts about the implementation details I decide to go with. Any feedback and help with improving it will be very much appreciated.
Create your free account to unlock your custom reading experience.