Meteor: platform or framework?

community
1

There have neen a number of posts recently in which comments have been made regarding the “Meteor framework” (my quotes), such as this one - a well presented examination of Meteor and getting to grips with the best way to structure an app. The main thrust of this post seems to be “why isn’t there one way to develop an app in the Meteor framework?” (my interpretation).

As it happens, you will struggle to find any official documentation referring to Meteor as a framework. The closest I got was on the Meteor Subprojects page which says “When building important software, whether in Meteor or with any other language or framework, good release engineering practices are essential.”

Generally, you will only find explicit references to Meteor as a platform:

  • 1 - “Meteor is a complete open source platform for building web and mobile apps in pure JavaScript.”
  • 2 - The Meteor Platform
  • 3 - meteor-platform
  • 4 - “Today, there’s a chance to create this new way — to build a new platform for cloud applications that will become as ubiquitous as previous platforms such as Unix, HTTP, and the relational database.”

Contrast this with:

  • emberjs - A framework for creating ambitious web applications.
  • angularjs - Superheroic JavaScript MVW Framework
  • rails - “Ruby on Rails® is an open-source web framework that’s optimized for programmer happiness and sustainable productivity. It lets you write beautiful code by favoring convention over configuration.”

So, why the disparity and why the confusion - especially as googling for “software framework vs platform” suggests that there is a difference and there is confusion? It’s actually quite hard to pin down what it is that makes a framework vs what it is that makes a platform.

Wikipedia say that “In computer programming, a software framework is an abstraction …” and goes on to state “…[a framework] provides particular functionality as part of a larger software platform to facilitate development of software applications, products and solutions.”

A interesting view on Platform vs Framework notes that “…a platform allows a software to run, which is not a framework requirement, since it is more focused on design.”

So, where does that leave us with the whole “what is Meteor?” question. Look at that quote [4] again: “Today, there’s a chance to create this new way — to build a new platform for cloud applications that will become as ubiquitous as previous platforms such as Unix, HTTP, and the relational database.” and then listen to @debergalis for an insight into his vision for Meteor. It is not just a framework, it’s something far more ambitious.

My personal, overly simplistic view is that while the Meteor platform helps you build apps, it does so only by providing fundamental tooling, conventions and infrastructure. You could equally use these to build a framework in which application development patterns are opinionated, and scaffolding and boilerplating are well defined - an Ember or Ruby for Meteor applications, if you like.

Meteor is young and developers are still finding their feet. As more and more people come to the Meteor platform from less ambitious frameworks, they will keep asking the same questions.

Perhaps MDG themselves should be a little less coy in not making their own vision more explicit. As a community, we should be fostering the adoption of Meteor by more and more developers. One way of doing this may be to give those that need it the reassurance of well defined practices…

Perhaps it is time for the first Meteor based frameworks to appear.

6 Likes
2

IMO a framework is a platform that encourages a specific structure in your project. That’s what a framework is outside of programming anyway. For example AngularJS is a framework since its design enforces the developer to follow a specific structure. Sure, you can do DOM manipulation from within your controller, but Angular will not help you if you decide to do so.

Meteor on the other hand is very abstract.

The first think you have to wrap your head around is reactivity. Not a command, function, library or toolchain, but an idea on how an app is laid out. Even calling it a Javascript platform feels a little irrelevant to me. If JS wasn’t the de-facto language of the web client, Meteor could very easily be it’s own programming language.

The Meteor Reactivity Language™ :wink:

As for the Meteor Frameworks, I already see hard workers on this forum trying to figure out what the best practices of that new beast are. The frameworks are bound to happen.

And I don’t think they are going to be like anything we’ve worked on!

1 Like
3

Look to the Cordova integration and Windows port and how they maintained an ismorphic API across each as a good example of the difference between a platform and a framework. Frameworks tend to be a bit vertical based on hardware, whereas platforms are more horizontal and provide functionality across hardware.

Ruby is the closest to being a platform of the items listed, since it’s language compiler gets installed on different hardware; but rails itself is vertically silo-ed within the Ruby language environment. Compare that to the proliferation of Javascript interpreters… you can find Javascript everywhere, from database shells to native chrome apps to embedded hardware (via tessel.io).

I can’t speak for the MDG since I’m not a member, but I’d hazard to guess that the intent is to focus on gathering all those sources and integrating them into Meteor.

3 Likes
4

My take so far is that Meteor is a nascent platform. I agree that it’s more than a framework now that I think of it, I apologize to MDG for belittling their work if I did. Since it has an extensive component (“package”) system and abstracts several lower-level dependencies away it qualifies as a platform. Though the boundary is tough to draw as a modern platform should offer some degree of framework-style assistance and opinion.

Meteor’s very opinionated as it stands, it says you can have any database you like as long as it’s called “Mongo” and ahem-encourages you to use a reactive design. Blaze is a framework for composing HTML that, while replaceable, is part of the Meteor core. I was pointing out in the linked post outstanding issues that I would consider platform-oriented rather than framework-oriented, though there are plenty of framework-oriented questions at a finer granularity than mine. I don’t see how a non-core framework would solve the problems I raised.

But here’s what I’ve gathered, though: the beauty of JavaScript, though I might call it the “Wild West” in how freeform it is, is its dynamism in both senses. Not only is it virtually anything-goes as a language, it’s continuously changing its consensus on “the right way to do things.” So we have 74K app installs of iron:router, nearly the entire Meteor population, but then flow:router shows up declaring Iron “evil” and worthy of deprecation. And good for that, it’s progress, and it’s good we don’t have more of a framework locking us all into more decisions and conventions than are absolutely necessary. Atmosphere has let 4441 flowers bloom as of this writing and the best of them minimize dependencies on each other and maximize interoperability and pluggability. That’s a tough balance to maintain but so far it’s very well done.

Most of the other really essential core platform additions (e.g. i18n) are already on Trello as future milestones so I just wish them speed in building them well. I do want a completed platform and more and better plugins/libraries and don’t particularly want a framework. Frameworks seem to lead to calcification while platforms lead to dynamism.

5

I know I’ll inflame people here for committing heresy but…

People are splitting hairs over this whole platform or framework thing. I mean, no one would call it a platform, much less have this conversation, if MDG called it a framework. Meteorites wouldn’t be saying “MDG may call it a framework, but it’s really a platform because of X, Y, and Z.”

If 37 signals had called Rails “The platform upon which our applications are built”, Rails people would be giving all the same reasons why Rails is a platform and not a framework; “Look at all the application and testing frameworks built on top of the Rails platform!”

1 Like
6

I like this. My take is that in order to encourage early adoption it’s necessary to have enough “framework-like” features to enable as many people as possible to actually build something useful. Inevitably, whatever the vision for Meteor, this will cause confusion.

If one accepts that the intention is for Meteor to become more platform-like over time, then one expects to see behaviours consistent with that: alternative databases, drop-in front-ends, back-ends, etc. We do see that in Meteor, although it’s coming out of the community rather than MDG. This leads me to suspect that a lot of what you describe as opinionated may actually just be pragmatism, given Meteor’s relative immaturity (that’s not intended as a pejorative).

It definitely wasn’t my intention to split hairs. When I introduced Meteor into my team (ousting Ember front-end and PHP back-end) I had a lot of negative reaction, which took me by surprise. As a result, I wanted to understand why there was (and is) confusion around what Meteor can and should provide in the way of structure and conventions. The answer seems to be “a lot” and “very little” at the same time. A huge amount of effort has gone into “what to use” (isomorphism, DDP, package management, etc), while not much has gone into “how to use” (application structure, naming conventions, best practices, etc). The former are more platform-centric, while the latter are more framework-centric.

Most of the how to use is coming out of the community, and with enough variation to add to the confusion for newcomers to Meteor. Search for meteor scaffolding, for example. There is a plethora of different ways to address the same question of “how do I structure my app?”

Would we be having this debate if MDG had called it a framework? Yes, I think we probably would. I would be asking why it was called a framework, when there is so much missing. Exactly the question I see time and again right now!

As for me - I like living in the Wild West. It’s not about confusion, it’s about freedom.

2 Likes
7

It’s a platform. I can’t recall right now in what MDG-published materials I’ve read it, but the difference was that Meteor is a framework plus tools (such as the build chain), which makes it a platform.

Cross-device deployment further makes it a platform, on top of which frameworks such as AngularJS can run via integrations.

8

You must be joking. The number one complain I get from people who don’t like Meteor is “it does too much”. The number one praise I get from people who like Meteor is “it does so much”.

For the sake of argument let’s say I agree that Meteor does very little. If that’s one of the reasons it’s a platform then Rails was platform when it was about Meteor’s age. And let’s be honest, compared to Meteor, Rails does so little “right now”.

Let’s take the argument of “you can build and use frameworks on top a platform”. If that’s the case then Rails certainly is a platform because, not only you can use frameworks on top of it, you can build your own. On my last Rails project I didn’t do things “the Rails way”. It was a SPA and I created my own little framework for moving data between client and server, saving, and a bunch more.

So far my point stands, it’s a platform because MDG says it’s a platform (which is fine). If MDG called it a framework, everyone would call it a framework and no one would bat an eye. Had 37 Signals used different terms and definitions, Rails people would now be talking about the Rails Platform.

Now I have no doubt people will be able to come up with a definition of platform that applies to Meteor that doesn’t apply well to Rails. But even if such definition can be concocted, does it really matter at that point?

At the end of the day it’s splitting hairs over definition minutia.

So yeah, Meteor is a platform! Hurray!

9

Here we go - my two pennies on this matter. If I have to make a quick opinion, Meteor is a platform and a framework. Allow me to elaborate.

A platform is usually a collection of technologies that together make magic to happen. Meteor does this by having NodeJS as its wheels through non-blocking I/O, fibers and other nifty stuff. Bound to MongoDB at this stage, which acts like a repository by default, confirms the platform story even more. Adding features and solutions to be reactive makes the platform story complete. However, Meteor does not feel like a platform at all. If the core team would replace NodeJS with something awful, MongoDB with something corporate and still want to achieve reactive solutions, I bet they could.

A framework is a bunch of libraries and tools that allow rapid development that can be done in collaboration. Conventions, documentation, best practices are born by having standards and reusability allows efficiency. This is where meteor becomes the framework. Allowing developers to focus on one language only - JavaScript (or be such an utterly untalented artist as myself having the need to speak dialects such as CoffeeScript to re-enact nostalgic Ruby-feelings) - provides a less complex environment to work in. Solid ORM (or however them meteorians call it) through Mongo, templating with Blaze, package management with atmosphere and a serious amount of helpers gives that framework feel. If one would add the iron-cli package, I bet they would just like me abandon their Rails apps and start haunting Meteor forums for they have found a framework that gives them the jiffies like in 2006… My… precious…!