Framework discussion: Mantra vs. Space vs. Space Kitty vs. Redwood vs. etc

I want to start a new app, I already decided to start using Meteor 1.3, ES6, React, etc. However, should I start using a framework?
I have already decided to start using Mantra, High Maintainability and Future Proof, sounds like music to my ears. :slightly_smiling:

But I’ve seen that there are other options like Space or Space Kitty

Space looks interesting, but it doesn’t seem to give support to Meteor 1.3 yet.

Space Kitty looks like an extension of Mantra, it comes in the form of a command line tool. It seems very useful to get all the scaffolding for your app quickly.

Do you know any other framework? Which one would you use and why?

1 Like

I dont really get what those do.

is Meteor 1.3 out yet?

No, I don’t think so.

No, it’s still in beta. Release date is not confirmed, but I’m think I’m right in saying this is the list of issues MDG are still working on for the 1.3 release: https://github.com/meteor/meteor/milestones/Release%201.3.

It sounds like it will be in the next month or two though, so targeting 1.3 seems reasonable for new projects?

For me I’d ;eave it until its out. For someone who has the time to play around, they might as well use the beta version.

I personally have my eyes set on Space as it brings Domain Driven Design to Meteor (See this DDD introduction), which in my opinion is the most future-proof way you can build apps that tame complexity and survive the test of time, regardless of framework. I have seen a few enterprises turn to DDD in my time, as their teams got bigger, technology changed and their software more complex. Eric Evans wrote the book in 2004 so it’s nothing new, and the technique is more applicable and powerful today than ever.

Future proof is partly about the technology you use, but it’s also about the architecture and design principles you use to write your software. Having an architecture that isolates your business domain entirely, means that even if you move away from Meteor all together, you can take the domain logic with you.

A word of warning is that DDD and Space will come with a learning curve, which is well worth the effort, as learning only makes us better.

I have complete respect for Mantra and the ideas behind it, and the efforts of SpaceKitty so you’d be making a good choice if you use them. Just make sure to keep your code clean, decoupled, small and tested whichever framework you use.

3 Likes

@PolGuixe I think it’s way too soon for people to be building these architectures around Meteor. But that’s just me.

Look at Rails, and how it’s been out for years before something like Trailblazer popped up: https://github.com/apotonick/trailblazer

There are not that many very large Meteor apps that people can use to learn what works and what doesn’t work. It is my understanding that MDG is in talks with the larger companies that use Meteor and their conversations are what’s shaping the Meteor guide.

I would use the Meteor guide: http://guide.meteor.com/

2 Likes

Perhaps a bit too soon for a framework with 1.3? For boilerplate: @sergiotapia don’t forget your own work, perhaps not a framework but Mantra is not a real framework either yet, your Mercadera app gives a great starting point, using 1.2.1 and React!

@ffxsam has a bleeding edge boilerplate prepared here and is very active with it.

1 Like

Yeah, Mercadera is a great example of what a production-ready Meteor app looks like with 1.2 and React. We intend to launch the app for real usage as well, so we will integrate any performance gotches we may run into, but as it stands, we’re being very smart about data structure and subscriptions so I don’t think we’ll run into any trouble.

None of these are “frameworks” per say. More like philosophies/guidelines… Honestly, you should read them all and make your own. NOT EVERYTHING needs to be open source, and def not everything needs to be shared.

1 Like

Are you planning to move Mercadera to Meteor 1.3 as soon as it’s out?

The concept of a ‘war’ is overly antagonistic and just stirs up arguments, implying that there is no room for collaboration. Can you tone down the title a bit? There’s plenty of constructive feedback back-and-forth from the folks developing these frameworks.

That being said, we’re preparing to release the Redwood Methodology in a few weeks. It’s going to be a bit of a departure from the astronomical and/or healthcare naming convention, with a few different stakeholders than usual, and is going to be more of a journal article and whitepaper. So you can add that to the list.

While preparing the whitepaper, it’s become rather evident that the different application architecture have different goals in mind. There’s obviously a school of thought that is seeking to support as many concurrent consumer users as possible (Facebook model). The Redwood Methodology, by contrast, is seeking to manage decades of records used by physians and nurses; so we’re focusing on a multi-tenant approach (Wordpress model) with a lower number of concurrent users per tenant, but which supports petabytes of data. Significantly different use cases and architectures.

I hope we can have the various framework authors speak up a bit and discuss the goals of the different application architectures. I’d like to hear from Mantra, Space, and SpaceKitty which scaling parameters they are optimizing for, and how their architecture addresses those needs.

4 Likes

@sam how is Space bringing DDD, because of the modularity?
I still don’t get DDD 100%. Do you have simple example comparing the DDD vs other approaches?

@awatson1978 done. Looking forward to see the Redwood Methodolody.

Yeah we will upgrade the app to 1.3 - and our priority #1 is going to make code that’s small and easy to understand.

Consider Mercadera to be the anti-architecture bloat project. There are tradeoffs, but obviously I think the tradeoffs are worth it. For example, using our structure, it may not be as easy to switch data stores. Do I think that’s important, not really. That’s just one example.

Things like this, don’t make sense to me. Too much indirection.

// From meteor.space:
var library = { sayHello: function() { console.log('hello!'); } };
var injector = new Space.Injector();

injector.map('OtherCode').to(library);
injector.injectInto(dependentObject);

dependentObject.sayHello(); // logs: 'hello!'

Our key intention: Make the code easy to understand.

5 Likes

Haha - then you must be happy that MDG hasn’t let Mr. Spring Framework bias their architectural decisions … :slight_smile:

Totally agree. I also think it’s important that Meteor not lose the one thing that attracted so many people to it: simplicity.

Actually in my post, I said it was not bleeding edge. :slight_smile: It does use 1.3 beta, but I also wanted to keep the boilerplate “safe” and somewhat close to MDG’s official guidelines.

1 Like

Here’s how Space is bringing DDD to Meteor

Have a look at this example .Net app for a good DDD example:

http://cqrs.nu/tutorial

1 Like

As the maker of Space Kitty, I would recommend sticking with Mantra. There is a lot still the pipeline that I will be changing in order to move more toward the Mantra structure.

1 Like

The most of the people dont need it.

In my last project I had a introduction to Space (offered by Darko, one of the creators and a briliant dev). 98% of Meteor webs (and web development in general) dont need a usually so complex architecture.

With MVC in the client, and a REST api in the server with a place to put some business rules is enough as I said in the 98% (sure more) of the cases. If you are going to port Wordpress to Meteor or something like that take care of it but if not…why do I need anyhing like that?

1 Like