Is there anyway to use Vuejs components inside Ember, or Ember components inside a vue app? or better yet anything that will make migrating a large Ember project to vuejs less painful?
The thing about any kind of interoperability is that it’s never impossible, but it can be complex and expensive and it only works as well as the amount of effort an ecosystem is pouring into maintaining it. Trying to go-it-alone is painful.
So if your underlying goal is to get a big, old app onto something with an improved development experience, you should be looking at the most well-trodden interoperability paths that lead away from where you are.
For a big old Ember app, the overwhelmingly easiest interoperability is from old Ember to newer Ember. You can upgrade from LTS release to LTS release, with a lot of preexisting materials to explain and help automate the changes. This can take you all the way up to Octane, which has a radically improved development experience compared with old Ember.
Even if you already have a team who knows Vue better than Ember, doing the rewrite off Ember still requires them to become skilled in Ember, in order to understand what they’re trying to port. Once you own a big
$FRAMEWORK app, you fundamentally need to become an expert in
$FRAMEWORK, even if your long-term goal is to not need it anymore. There’s no shortcut.
Thank you for taking the time to help appreciate it,
I’m already using latest version of ember, and the app was built last year and ember was always kept up to date. Upgrading to octane not sure if it’s a wise decision at the moment since octane lacks sufficient documentation and wouldn’t risk taking a production app into it. Ember itself with all the years behind it lacks that not to mention an edition that’s set to be released “maybe”.
I know sadly, I was hoping there would be some easier way of porting components one one or another… Ember is just to restricted and all the edge cases we deal with on a daily basis make it not worth it… At first it was fun to build things with ember but as the app grows our productivity dropped massively and we are now fixing bugs here and there in packages that are badly maintained or are trying to hack around the JSONAPI Adapters…Etc
Whether or not you switch frameworks, if you don’t get to the bottom of this the problem is going to follow you. Especially if you’re facing this problem with an app that’s only a year old. That’s a big red flag that has nothing to do with language or framework.
I have the same complaints with Ember but I tend to agree with @ef4. I am not confident that trading frameworks will make our code better / easier / less susceptible to frustration. And so I stick with the devil I know, rather than the devil I don’t
That said, if I were to pursue such a migration I think I’d start by converting my ember components to web components, then moving long love state from services to redux or something. Not sure about ED though.
Yep, true. The problem is that the app itself was a rewrite of a PHP original one… I won’t deny that getting started with Ember was the easiest and smoothest among all major frameworks out there (React, Vue and Angular)… especially when it comes to handling the data and the store setup (which I initially found hard to grasp on other frameworks)… But the bigger the app becomes the harder it is to maintain, and had to re-invent the wheel for almost everything… Especially the adapters, serialisers are badly done and worsely documented… Most of the time you find a solution out there (after digging a lot into google) and then after wasting hours into trying to implement the supposedely solution to a problem you faced you suddenly find out that the proposed solution is “outdated” or has been revoked.
Generally, the major problem I guess we had was in decision making and ignoring all the “reviews” on the internet before picking a framework… since it was first time working with Ember, React and Vue… I ignored all the reviews and red flags put out there by others… and just stuck with Ember… and by the time we started facing problems it was already to late to do anything about it.
Well, we already stopped building any new projects or demos on Ember, and started doing so on React, Vue and Angular that way we discover new potential challenges and see which one is best fit to replace Ember… So far Vue been the best to work with. But still we find it little hard to invest all the hours into rewriting the whole thing again instead of focusing on releasing new features.
If you have a more elaborate action-plan for the would love to know more, especially on migrating from Emberjs to Vuejs? how would you go about doing it?
I don’t have an elaborate plan, but it depends on so many things specific to your application. You could do page-by-page, you could start redirecting clean parts to a new app, you could migrate parts of the app to render an iframe with the Vue app in it.
I think this would be a super fun project to work on technically, and I think it’s totally doable, tbh! I started breaking down the work in this post as I would do it, but it’s not based on anything so I’ll refrain
Sorry to hear that it sounds like struggles with EmberData are a big motivation towards wanting to abandon ship. EmberData is not a requirement for Ember apps and many apps choose to use raw fetch, apollo, orbit, redux, or many other data solutions instead.
That said, with EmberData I feel we’ve done a poor job historically helping folks fall into patterns of success when an API doesn’t fit the adapters or serializers you get in the box, and that is something we’ve been working quickly to address.
We introduced new serializer API docs recently:
New adapter API docs are in-flight:
We’ve made it possible to use EmberData without using either of these packages (documentation on that will be provided soon as well):
If you’re interested to know more about the overall architectural evolution and where we are headed with EmberData, you might be interested in the talk I gave recently at EmberFest on it: https://www.youtube.com/watch?v=zbqbsOyLM30
I’d also be interested to know which packages you’ve found poorly maintained.
Feel free to reach out via twitter DM, gmail or on discord (runspired on all platforms) if you’d like to discuss this more privately.
Thank you for your input @runspired, but that’s probably the point with ember seems like a lot is “usually” going on but nothing in reality happens… which probably means it lacks good management… efforts to build or improve stuff are not concentrated enough which makes them meaningless and wasteful.
One more thing I hate about ember is having to debug errors like this:
Now I have to guess where that error happened (i encounter that quite a lot and it takes days sometimes especially as the project grows), I never encountered similar thing with Vue, React or even Angular!!! you always told what file/component/route the error took place in in your project… while in ember you get this:
Now for god sake what’s the point from logging out all those files it’s pointless (maybe would help If I’m maintaining ember itself but not a concern to me) and it points you no where at all.
That’s just one of the daily struggles with using ember.
as for this:
Well, as far as I found it’s hard to find the other way around any package that is highly maintained! Ember itself seems to struggle to keep things on track with the releases… not to mention packages… if you find any packages for what you need in the first place…
try https://github.com/lifeart/ember-vue-components to create vue-like components in ember. after rewriting, you will be able to reuse components in vue with minor template changes.
Thanks @lifeart, I stumbled upon that a while back interesting if it was the other way around finding a way to embed Ember Components into a Vue project… that would help migrating… that one will probably be more beneficial when migrating from Vue towards Ember, But no one in their right mind would do that I suppose.
Hi @Yassine, we are thinking of migrating bits and pieces as well. I don’t think it’ll be too hard using vue in ember, but it’ll be very hard using ember in vue because it follows inversion of control. The strategy we are going to adopt (not yet tested, but going to soon enough) is to migrate small components to vue, and use them in wrapper ember components which mount the vue component once mounted itself. I have no idea if this will work the way I think it will, but I will try and post a proof of concept if it works
@iamareebjamal The same strategy should work the other way around. Glimmer components should be renderable in Vue with glimmerx-lite-donut or if bundled as a web component. It gets complex if it comes to shared state (services), router and such advanced features that are not only about invoking a component.
Almost all ember apps currently are non glimmer and using routing, ember data and so on, so that won’t work out.