When I first started using meteor in the pre-1.0 days (circa 2012) the Meteor documentation had seven principles:
Seven Principles of Meteor
Data on the Wire . Don’t send HTML over the network. Send data and let the client decide how to render it.
One Language. Write both the client and the server parts of your interface in JavaScript.
Database Everywhere . Use the same transparent API to access your database from the client or the server.
Latency Compensation . On the client, use prefetching and model simulation to make it look like you have a zero-latency connection to the database.
Full Stack Reactivity . Make realtime the default. All layers, from database to template, should make an event-driven interface available.
Embrace the Ecosystem . Meteor is open source and integrates, rather than replaces, existing open source tools and frameworks.
Simplicity Equals Productivity . The best way to make something seem simple is to have it actually be simple. Accomplish this through clean, classically beautiful APIs.
Agree 100%. These are still valid. I did have a brief discussion with @sashko back in the day, when these principles “disappeared”.
One of his arguments was that the Simplicity Equals Productivity was questionable, because the Meteor API code itself is not simple. I believe that doesn’t matter. What’s important is that the developer experience is simple - leading to greater productivity.
Data on the wire - subscription and method calls still work. You can also add express easily for REST API
One language - still JS in server and client
DB everywhere - can still use minimongo client side
Latency compensation - can still work
Full stack reactivity - 10x better with client side state management and React
Embrace ecosystem - 10x better than before with NPM
Simplicity - OK, not as simple as before, but boiler plates like Cleverbeagle and also Meter creat --react make things easier
Sorry, I wasn’t clear. I know and love these features but they aren’t advertised as prominently as they used to be in the top of the docs.
Seems like good marketing materials for developers got thrown away. I had to clone the docs repo and checkout a commit from ~2013 to find the principles in the docs.
MDG could totally market these core values as proof that even in a world of mind numbing change, picking the right things to hang your hat on pays off.
Then highlight any of the awesome things Meteor brings to the table right out of the box that other frameworks just don’t do as well.
I agree. This message should be PROMINENT. Always lead with your unique value-add.
As a Product Manager, I can’t imagine burying this or removing it from my home page.
I am currently attempting to persuade a Managing Director of a leading VC to transform a company they bought 2 years ago that has been unable to scale or drive profitability. In part this would be achieved by scrapping the entire proprietary stack and starting over on Open Source with Meteor as the centerpiece. These principles get to the heart of why this kind of radical change is possible AND advantageous.
@techplex Thank you for fishing this out of obscurity… I hope MDG will dust it off and put it at center stage with a spotlight, cause this is the reason that Meteor should be the star of the show.
IMHO, it shouldn’t, because it isn’t really true any more. Meteor is more of a configurable build tool and server platform, with some awesome devops (this is under-valued, or at least under-communicated). I’d prefer to see Meteor make a pitch more in line with these 3 characteristics. It’s more accurate, and I think it’d be more effective in terms of marketing.
Most of the things that added up to the “7 principles” are extractable or interchangeable. If a team is building with React client side, and using Apollo with MySQL, they’ve already lost like 6 of the 7 principles, yet this is a perfectly viable way to use Meteor.
Also, that particular sales messaging works great for a certain segment of the market, but it’s actually off-putting for a (what I think is larger) segment of the market - those who prefer to control the lower level details.
That said, there’s no reason there couldn’t be a derived-project built on Meteor core (a bundle of tech called Meteor Classic?), which still advocates for that level of simplicity - it’s literally still possible to do all that, the original way on Blaze/Mongo, etc. That backwards compatibility is one of Meteor’s strengths.