Check out MARKO and let us know if this new UI lib can be used with Meteor if you’re interested.
3 Likes
MarkoJS by eBay is a very fast and high performance (…faster than React and Vue - according to the doc) UI library powering eBay.com. I haven’t seen any integration point with Meteor reactive data, though can be used easily with Apollo or meteor methods for data fetching…It’ll be nice to see its usage with Meteor reactivity.
1 Like
I’m not familiar with framework integration processes. MarkoJS seems really interesting to me, but I’m wondering what would need to be done to integrate it with Meteor. I could certainly wait for someone to do it one day, but if the process is not too complex, maybe I could try it out myself… Can anyone give a hint at what the steps would look like?
1 Like
Maybe the same way as meteor choose to back React?
Searched Marko docs and found this:
Please note that I have no experience with Marko but I’m looking at it as a developer that really want to use it with Meteor 
Somebody else chip in here please as this might not be the best way?
2 Likes
That looks promising. The issues around integration with Tracker are likely to be the same as with Blaze - avoiding unnecessary re-renders.
1 Like
If Marko is as clever as Vue, you shouldn’t have to do anything special. All that the vue-meteor-tracker integration does is use Tracker.autorun to copy the whole collection.find().fetch() results to the Vue component data on every change. With the v-dom and other optimizations Vue has, the rerenders are still kept to a miminum.
Having said that maybe it’d be better if it used cursor.observe instead to more selectively update the data 
1 Like
Yeah - the issue is around “how do you know your reactive data has finished changing, so you can render?”
The answer is that you can never be certain that it won’t. The best you can do is wrap the whole component in an autorun, so multiple, concurrent, independent changes are absorbed into one requestAnimationFrame render cycle.
1 Like
Hmm I don’t think you should have to worry about that, that’s something the UI framework should already handle, if it’s a reactive and data-driven framework.
LOL. I don’t worry about it, but the fact is that reactive changes are unpredictable and Blaze (as an example of a reactive and data-driven framework) doesn’t handle concurrent, reactive changes well.