3 ms·

What blocks you from digging into the source? I want to make that easier for you. Nearly all of the Meteor code is broken out into various packages. They imp

What blocks you from digging into the source? I want to make that easier for you. Nearly all of the Meteor code is broken out into various packages. They implement components like publish/subscribe, client-side data caching and snapshotting, reliable remote method invocation, live page updates, and hot code push. They're the building blocks for a rich client application. Now, we have some work to do on better separating those components so that you can pick and choose the parts you want, like using livedata (publish/subscribe) with Angular, or using Spark (our reactive page update engine) with a legacy REST endpoint instead of livedata. Those combinations are technically possible today, but not particularly accessible. They should be. (That is one of the two front-burner project we have going today. The other is scaling.)

d0m 14y ago
What blocks me from digging into the source is mostly that even if there are separated components, I still need to understand all the aspects of Meteor. I can't just open the file and change it. Will it screw up the deploy system? Will all the data-binding continue to work as expected? Maybe yes, maybe no. Unless I totally understand the system, I can't really know. You say "like using livedata (publish/subscribe) with Angular", but that's the problem I'm talking about. You need to tweak the system to make it work with Angular. But what about the hundreds of other smaller angular-like libraries? Or tomorrow's most popular one? I can't just <script src="it">, I'll need to create a meteor package and make sure it works good with all the rest of the system (Which unless I'm a Meteor expert, I have no way of knowing). That could actually be a good blog article, "How to use MooTools, django template system and MySQL with Meteor". I.e. Going through what's needed to be tweaked to make it work. Compared to say, express, I could tell you use the mysql node library, normally include mootools in your html files and use mustache (Or whatever library already exist to mimic Django's libraries).

d0m 14y ago

What blocks me from digging into the source is mostly that even if there are separated components, I still need to understand all the aspects of Meteor. I can't just open the file and change it. Will it screw up the deploy system? Will all the data-binding continue to work as expected? Maybe yes, maybe no. Unless I totally understand the system, I can't really know. You say "like using livedata (publish/subscribe) with Angular", but that's the problem I'm talking about. You need to tweak the system to make it work with Angular. But what about the hundreds of other smaller angular-like libraries? Or tomorrow's most popular one? I can't just <script src="it">, I'll need to create a meteor package and make sure it works good with all the rest of the system (Which unless I'm a Meteor expert, I have no way of knowing). That could actually be a good blog article, "How to use MooTools, django template system and MySQL with Meteor". I.e. Going through what's needed to be tweaked to make it work. Compared to say, express, I could tell you use the mysql node library, normally include mootools in your html files and use mustache (Or whatever library already exist to mimic Django's libraries).