4 ms·

Every time I see a framework like this I ask myself: if I outgrew this, how difficult would it be to migrate away from it? I'd love to hear if anyone has used

Every time I see a framework like this I ask myself: if I outgrew this, how difficult would it be to migrate away from it? I'd love to hear if anyone has used meteor for something read and if they've had to deal with migrating to something else: how they've done it, and what issues they encountered. For example, I love angular, but migrating away from angular after using it for one year would doubtless be a very painful process.

vqc 12y ago
What would be the opposite of angular, i.e. easy to migrate away from? Backbone? (Because it is less opinionated than Angular?)
joshkpeterson 12y ago
This seems like a low priority consideration. Personally I would try to choose a framework that will last you longer than a year!
swartkrans 12y ago
Meteor is a totally different way to write web applications. Between the merging of the concept of front-end and back, the distributed data protocol it uses, the live templates, there's nothing really else out there like it and no, migrating away from it will not be easy, but if you're a transient nomad with frameworks I'm not sure you should really use any framework.
KaoruAoiShiho 12y ago
I moved from meteor to an angular+pusher solution. I rewrote the entire thing in about 3 weeks. Almost nothing was reusable. The app is http://anonquest.com/ http://anonquest.com/ It's a realtime story writing community. Be happy to answer questions.
- general_failure 12y ago
  Angular 2 changes everything
kyllo 12y ago
That's because it's a higher-level abstraction than other web frameworks. Ripping out a layer and dropping down to a lower level of abstraction is always going to be a lot of work.
goblin89 12y ago
> For example, I love angular, but migrating away from angular after using it for one year would doubtless be a very painful process. I wish AngularJS’s dependency injection/forced modularity and HTML augmentation/templating were somehow independent and not requiring each other. > if I outgrew this, how difficult would it be to migrate away from it? I'm becoming successful at fighting my urge to migrate my projects away from things I outgrow. I reason that changed preferences alone should not constitute a reason to rewrite an existing and working solution. And in case costs of adapting existing solution are higher than costs of rewriting it from scratch, then this is probably due to some unfortunate design decisions or obscure libraries/frameworks used, so these are the things to avoid.
- pluma 12y ago
  > I wish AngularJS’s dependency injection/forced modularity and HTML augmentation/templating were somehow independent and not requiring each other. That was why I eventually switched to React after trying to find ways to have Angular-like components/bindings without the DI/IoC parts of Angular (even going as far as reimplementing parts of Angular). If you only want the bindings, maybe rivets or knockout is an alternative?
lopatin 12y ago
Outgrowing Meteor is a valid concern. It's intertwined with your backend and db, so it's definitely a lot of work to migrate off of. I just want to make the distinction between that and JS frameworks that don't try to own your whole stack. Migrating from Angular is no more painful than migrating from Backbone. They're all frontend frameworks that talk to a rest api. When choosing between React, Backbone, Angular, Ember, etc ... it seems to me that migration effort shouldn't even be a consideration since a complete UI rewrite will be required in any case.
- notastartup 12y ago
  I find this troubling. Basically, I feel like we are reinventing the wheels 4 or 5 different ways but we are unable to swap out one for the other. Basically, we spend so much time writing the obvious things like CRUD in almost every permutation possible. Like back when visual basic was popular, you could easily pull together an app, here we are trying to make the web browser do things it was never originally designed for, emulating desktop like responsive app but with multiple vendor interests in trying to dominate this market, it's hard to say who to bet on and why because the developer mindshare is fragmented and we waste time trying to figure out how to create a login using Angular.js, Backbone, Ember.js etc., when short while ago you would just write a jQuery ajax or even better, render it on the server side and send it. The whole idea of having to run phantom.js to render your website because search engine robots can't index your site reminds me awfully like trying to keep up with a high maintenance girl who is more trouble than she's worth.

vqc 12y ago

What would be the opposite of angular, i.e. easy to migrate away from? Backbone? (Because it is less opinionated than Angular?)

joshkpeterson 12y ago

This seems like a low priority consideration. Personally I would try to choose a framework that will last you longer than a year!

swartkrans 12y ago

Meteor is a totally different way to write web applications. Between the merging of the concept of front-end and back, the distributed data protocol it uses, the live templates, there's nothing really else out there like it and no, migrating away from it will not be easy, but if you're a transient nomad with frameworks I'm not sure you should really use any framework.

KaoruAoiShiho 12y ago

I moved from meteor to an angular+pusher solution. I rewrote the entire thing in about 3 weeks. Almost nothing was reusable. The app is http://anonquest.com/ http://anonquest.com/ It's a realtime story writing community. Be happy to answer questions.

general_failure 12y ago
Angular 2 changes everything

kyllo 12y ago

That's because it's a higher-level abstraction than other web frameworks. Ripping out a layer and dropping down to a lower level of abstraction is always going to be a lot of work.

goblin89 12y ago

> For example, I love angular, but migrating away from angular after using it for one year would doubtless be a very painful process. I wish AngularJS’s dependency injection/forced modularity and HTML augmentation/templating were somehow independent and not requiring each other. > if I outgrew this, how difficult would it be to migrate away from it? I'm becoming successful at fighting my urge to migrate my projects away from things I outgrow. I reason that changed preferences alone should not constitute a reason to rewrite an existing and working solution. And in case costs of adapting existing solution are higher than costs of rewriting it from scratch, then this is probably due to some unfortunate design decisions or obscure libraries/frameworks used, so these are the things to avoid.

pluma 12y ago
> I wish AngularJS’s dependency injection/forced modularity and HTML augmentation/templating were somehow independent and not requiring each other. That was why I eventually switched to React after trying to find ways to have Angular-like components/bindings without the DI/IoC parts of Angular (even going as far as reimplementing parts of Angular). If you only want the bindings, maybe rivets or knockout is an alternative?

lopatin 12y ago

Outgrowing Meteor is a valid concern. It's intertwined with your backend and db, so it's definitely a lot of work to migrate off of. I just want to make the distinction between that and JS frameworks that don't try to own your whole stack. Migrating from Angular is no more painful than migrating from Backbone. They're all frontend frameworks that talk to a rest api. When choosing between React, Backbone, Angular, Ember, etc ... it seems to me that migration effort shouldn't even be a consideration since a complete UI rewrite will be required in any case.

notastartup 12y ago
I find this troubling. Basically, I feel like we are reinventing the wheels 4 or 5 different ways but we are unable to swap out one for the other. Basically, we spend so much time writing the obvious things like CRUD in almost every permutation possible. Like back when visual basic was popular, you could easily pull together an app, here we are trying to make the web browser do things it was never originally designed for, emulating desktop like responsive app but with multiple vendor interests in trying to dominate this market, it's hard to say who to bet on and why because the developer mindshare is fragmented and we waste time trying to figure out how to create a login using Angular.js, Backbone, Ember.js etc., when short while ago you would just write a jQuery ajax or even better, render it on the server side and send it. The whole idea of having to run phantom.js to render your website because search engine robots can't index your site reminds me awfully like trying to keep up with a high maintenance girl who is more trouble than she's worth.