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.
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?
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.
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.
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.
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.
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.
@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?
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.
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. It does use 1.3 beta, but I also wanted to keep the boilerplate āsafeā and somewhat close to MDGās official guidelines.
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.
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?
It does use 1.3 beta, but I also wanted to keep the boilerplate āsafeā and somewhat close to MDGās official guidelines.