I’m using meteor for last 8 months and fill big need of some kind of component architecture. It seems, that many people also want that and some already created their solution.
I did small research and from what I found, I would be happy if ideas proposed by @sashko in Blaze2 discussion on hackpad will become reality. The only question is when and if…
Now I’m looking on a few already woking solutions:
I’m quite not sure when Blaze will come. But there are a lot of components solutions popped up. I can tell you about flow-components. It worked for us. But we are not comfortable releasing it yet to the public. So, keep that in mind.
React is getting the momentum, so give it a try. Do your research first. Once you picked a solution, you may need to use it for a long time.
@arunoda, what to you mean by we are not comfortable releasing it yet to the public? Your package is already available publicly on atmosphere and has 160+ downloads.
Does it mean that you’re not planning to support it and do active development using your meteorhacks:flow-components? Or you just think that it’s still very green and not good for beginners.
After looking at all of these last night I can’t see React losing. There is too much muscle, too broad an ecosystem, plus React Native… No one will write Meteor-specific UI components when they could just write React components and use Meteor as the reactive stack underneath.
Blaze and others might survive for people who like a certain separation of content and presentation and are just targeting the desktop web but frankly those are dinosaurs. A components-based solution is going to follow the component ecosystem. React is a natural for Meteor and removes a lot of legacy oddity IMO. Try it.
I just spend 5 hours or so to look at React. Sounds interesting, but I feel that I’m the type of person who likes separation of content and presentation. However, I’ll try to create some small project in React (and probably using some other components package) to check how it feels to code in their way. O at least to use React/BlazeComponents/FlowComponents for part of my app where components needed.
I think a lot of the magic comes in in ES6 with inline HTML. You can use that now I think with e.g. grigio:babel.
When you think about components as such, don’t you want everything in a component wrapped up into a neat little package? A lot of the separation benefits become costs when everything is component-oriented.
For working with designers, I’m of the opinion designers shouldn’t handle code at all unless the code is super-accessible. They can do wireframes, PSDs, CSS on placeholder HTML and that can then be shattered into components by the developers with no roundtripping back to the designers beyond the CSS. (Er actually, now I’ve gotten to the point of seeing React using inline, JS-coded styles, so I suppose the designers just have their own mocked version of the app to work with and the developers keep syncing it to the component version…)
Do you know any good example of bigger app written on Meteor with React? Would be interesting to see the code. Leaderboard isn’t really good example, so example of todos or telescope type of apps would be awesome.
Just curious because I’m looking into it myself - why is the interest level in Polymer so low? I agree that React is gaining a lot of momentum right now, but I wonder if/how that will change when Polymer moves from 0.8 to 1.0
Polymer packages/components are too big and don’t work well with Safari and earlier IE, useful for mobile app or desktop application like Atom editor is planning on using Polymer.
I agree with @proyb2, Polymer components are too big and too raw for now. If you’re using not Chrome, they are very slow (because of lack of support of some EC6/EC7 features polymer use).
I was quite optimistic about Polymer, but at the moment it’s simply not ready for production.
Actually, we most of the development in public. So, that’s doesn’t mean it’s ready.
It worked for us and we are using it and we need to maintain it. But we don’t have proper unit and integration tests yet. That’s why I told it it’s not ready.
And this is a very competitive topic with a lot of choices. No one is mature yet.
I recently spent some time working with flow-components. The only real issue I have with it is that it completely disconnects you from the blaze data context. Data context values end up being copied into component-specific reactive variables. This sounds great in theory due to better encapsulation, etc. However, in practice it causes a lot of extra overhead. Reactive changes in the data context force a deletion/recreation of the component.