So. Here’s a few little questions to think about. What if…
- a different development direction had been taken with Meteor?
- and that the real value in Meteor wasn’t viewed as realtime reactivity, but in the curation and integration of community packages?
- and a router had been pulled into core?
- roles had been pulled into core?
- simple schema and autoforms had been pulled into core?
- and user models were in core?
- and all those API pull-requests that had been made over the years had been accepted?
- and it was assumed that Blaze would stick around (or at least the Spacebars API)?
- and a more Cathedral .Net approach had been taken, rather than the Bazaar free-for-all of NPM?
- What would Meteor look like at this point? On a pragmatic, day-to-day basis?
- What resources would devs go to on a daily basis to look up API definitions?
Well… it might look a little something like this:
Yeah, it’s still a little rough around the edges.
Entry has a lot of functions that aren’t documented yet;
HipaaLogger needs to be moved to
SchemaHydrator probably needs to be attached to
SimpleSchema, which isn’t added yet. etc. etc. etc. But those are all sort of tactical things that can and should be discussed.
The real point here, is that we managed to:
- get a bunch of packages that people have been asking to go into core into a release distro;
- we’ve got JSDoc formatted comments and documentation on the major API objects and functions;
- we managed to clone the JSDoc site for the Clinical Meteor release; and
- we have a reference version of Meteor that has all of these pieces working together.
- by the end of the year, we should have integration tests on all of these packages as well.
So that’s pretty exciting.
And icing on the cake is this: we’re going to add an addition 100 API objects from the HL7 Argonaut FHIR project in addition to the 16 objects we’ve just released. It may take another year to work through those 100 new objects. But if anybody want’s a roadmap of what we’re doing… well, there ya go!