I’m new to Meteor and am trying not to bother anyone with FAQs, but after extensive Googling I felt a need to clarify some points.
First of all, I was somewhat taken aback by the use of the global namespace in a modern framework full of 3rd party packages just waiting to conflict with it. The testing system (Velocity) is just coming together now, and I wonder how DI will be achieved. But presently I simply have to get things working in the first place, and file loading order issues have cropped up. Putting all my globals into
lib/_namespaces.js is brittle given the load order rules (you have “
main” as loading last but no reliable rule for loading first).
I decided to use the Iron:CLI system with its router and “scaffolds” as a standardized way of structuring the app (suggestions to “just refactor your directory structure as you go” don’t sit well with me…frameworks are about leveraging the experience of others no?). Correctly it makes individual files for each collection. But combining this with aldeed’s autoform package and its reliance on a global Schemas object presented the load order problem. It seems aldeed suggests just throwing all the Schemas for all the Collections into a giant “common.js” file which clearly will get unmanageable for a production app after a few hours of coding.
I read somewhat wandering proposals about namespacing using lazy resolution and then terse suggestions about using packages that seem to make more sense. There are a few rarely used packages on Atmosphere concerning namespacing, nothing promising. So I went ahead and learned how to make my own package and exported the Schemas global from that. Seems to work so far, but wow—there’s an uncanny valley between cowboy-style freecoding with globals and using the package system to impose some degree of structure. A learning lurch.
The next investigation was just what was required in practice to realize the write-once-run-anywhere promise with desktop and Cordova mobile apps running on the same reactive codebase. I figured there must be cross-platform HTML5 frameworks that cover Web, Android and iOS in one go, each with their native standards. Sadly no luck…I found Bootcards to be in a primitive state, and while Ionic does Android and iOS in one go, it doesn’t do desktop web at all. Ratchet, ironically, was developed by largely the same team behind Bootstrap, but they inexplicably made the two incompatible. With this mess I would probably be best off implementing individual mobile apps (perhaps in Framework 7 and Materialize) even though most Meteor stuff is expecting Bootstrap. But how to avoid DRY violations and maintenance headaches that would come without a common codebase? Isn’t that the point?
SO pointed to this example which selectively exports from packages to desktop and Cordova. This site comes to the same conclusion. Any app of any size, I would say anything beyond a day’s sketch, seems to really need to be factored into packages from the get-go with Meteor as it’s designed right now. It’s not taught that way in any of the main materials I could find, they’re all just “Dive in cowboy-style, go ahead and repeat yourself, Mongo denorms everything anyway, etc.”
Is this the consensus among the experts then? Packages-for-everything is the best and only solution to building anything production-capable in Meteor? Is that going to be the case moving forward? Am I asking too much of this framework too early in its evolution?