I’m looking to developing a web and mobile app. They will share a common database. The features that I’m looking to have are as follows:
- Material Design
- Web Components
- Highly Modular
- Responsive
- Faster rendering performance
I would say that you can achieve your goals with any of the mentioned technologies 
It would be great if you can suggest the best option out of the lot
We made the same quest before starting with our new app few days ago. We decided to give the React space a chance and after some days we are still happy with that decision.
I’m not quiet sure what the current status of using Polymer with Meteor is. I think it is not widely used and still bumpy.
I think a better alternative is a UI framework like:
- https://atmospherejs.com/materialize/materialize
- https://atmospherejs.com/semantic/ui
- https://atmospherejs.com/twbs/bootstrap
Angular 2 is not released yet. Learning it will take some time. http://angular-meteor.com/angular2
Blaze and React are both great. They both allow you to create modular UI components.
TL;DR: Polymer is super bleeding edge. If it weren’t for the new Polymer+Meteor issues I’d say use it right now! If you can work around those without hacking some stuff together use it. Otherwise wait one or two more months, they’re aware they need to make it easier to integrate in other frameworks. React has been proven production ready afaik, though I can’t speak from experience. No Web Components though.
Polymer works great until you throw it into Meteor. Unfortunately there’s a pretty big issue with Meteor+Polymer when switching routes, not sure if it’s a Polymer or Meteor issue. Some components break (probably only with the new, faster and more performant shadow dom polyfill, old one worked fine). On top of that you gotta be careful with updating DOM in a custom element for now (though they already have a patch for that in the making).
I’m really hoping for this issue to be resolved soon. Unfortunately it doesn’t seem that either Google nor MDG are looking into this issue. I might be wrong about it though.
If you want to use Material Design maybe try out React for now (unless you know your site won’t go into production in another 1-2 months or so, Polymer’s development speed is really fast right now). I didn’t like using materialize. I’m using it on a project right now, I just don’t like using it. Too many CSS hacks or incomplete features. That’s why I do love Polymer. It makes everything easier when working with the components.
If you truly want to use Web Components, then there’s no way around Polymer afaik. But there are the performance issues with the shadow dom polyfill. (Though I think this can be ignored very soon. Mozilla already had a shadow dom patch in the making for months and vendors are doing some final meetups (or hopefully last week was the last one) to finish the specs, then I believe FF will implement it. Microsoft Edge will probably follow in the next 6 months and well Safari is just Safari, forget about supporting it 
.
1 Like
I’m currently working on a Meteor-Polymer app, and I agree with pretty much everything you said. So far, most obstacles haven’t been too bad in getting the two to work together, with the glaring exception of routing. My current work-around for that is to use the shadow dom instead of the default shady dom until Polymer’s experimental patch-dom.html is fully functioning (I’m hoping it will be released in Polymer 1.1). I’m also currently using Polymer for 90% of the front end, but still rendering templates and passing data with Blaze - I plan to change over to Angular 2 when it comes out (and if there isn’t such a huge recoil among the community that its future isn’t questioned).
Rich, for the patch-dom, I doubt it will be. It seems sadly their focus is more on more paper-elements, probably because the community is whining so much about missing elements with the transition from 0.5 to 1.0 because nobody gets that Polymer and the elements are two different things.
Patch dom and the other framework work seems to be not advanced enough yet. The framework stuff doesn’t even have a public github branch yet. But let’s hope 
.
1 Like
Is it possible to use atmosphere packages like autoform with any of angular or react?
Agree with Sanjo, but would also add that Blaze is not that good if you’re thinking of easy to maintain reusable components. Sure, you could use BlazeCompoments, I use this package in one of my projects, but React looks much better for me for now.
So, choose React for now. In future, when we’ll have Angular2 and Blaze2 it will be much harder to choose 
Yes, you can mix React and Blaze. In many cases it will work fine, but sometimes you’ll still need to dance with drums around that stuff.
None of these frameworks like if u mess with internals of their components/elements/templates or so.
For now only Blaze and React have official connectors to Meteor event systems.
As you can see yourself in Polymer’s case, there is not much cooperation possible in Shady dom atm as it bleeds internals to DOM. And shadow dom is still long way from widely available. So for now if you want to use it with Meteor and widely compatible, you would need to prepare mixins similar to React ones to hook Meteor-Polymer internals. Than in theory you can just render all Polymer with its full framework functionality and reactive to meteor actions.
Me personally see future more like storing state in Flux store and than any of these UI frameworks subscribing to state changes. Every one of them can wait for these emited events and react appropriately. In their uniq way and using their internal functions/ways/workflows.
And with time travel state (action history) debugging which is UI framework agnostic it would not matter which UI you use, debugging will be still same. There will be just performance difference for various platforms etc…
For now we can say that React and Angular 2 should have no problems with this approach, throwing “large” state objects at them, as they both have shadow DOM and will apply only diffs to browser DOM. Others without it would need some kind of optimalization to not redraw whole DOM state from scratch.
Maybe some interesting model could be put together with immutable structures to reduce also these changes, who knows. I am just noob here.
But after playing with Reagent for a while my mind bended a little to that direction 