Hey @netmask
Thanks for your comments. We are in the progress of releasing the package on Github so @vlasky, the original developer can take a look at it. We know it works with MySQL and likely plain SQL. We could work on an interface for PostgreSQL or you can lend a hand in the conversion of the queries from Mongo to PostgreSQL (unless you are OK just making straight SQL calls).
We’re with you on that one! We are hoping to have our conv soon with @thea to get that going for us.
Primarily it’s that Meteor became much more verbose. This is even very obvious in the tutorials, the “my first Meteor app” page has proven to be a big downgrade from the <1.3 version. I had to personally teach our new employees how to use Meteor after those tutorials, and they contributed more confusion to them than contributed knowledge.
With even bigger changes to Meteor coming, and none of us really knowing exactly how Apollo is going to affect Meteor when it becomes integrated, it makes developers like us very worried that Meteor will become more and more verbose in to the future, and that’s not what we want - we chose Meteor for it’s efficiency.
This is a bit of a 2 fold problem for those of us who have pre-existing Meteor projects. There wasn’t really any features for helping users migrate from pre-1.3 to 1.3, and the process takes quite a bit of refactoring, considering the directory structure completely changed, and the import backwards compatibility is only temporary. At my job, it’s basically a cloud looming over our heads at this point.
In this case, I really wish Meteor came with some sort of functionality to assist with refactoring. I mean, just including something in the new directory structure to assist with this would have been great. Even ViewModel for React comes with some features similar to this.
In terms of 1.3, it was presented as being temporary, and this is a way as basically encouraging (or forcing? if worded less lightly) us to upgrade our projects 1 step at a time to support the “new Meteor”. But that is the last thing users who picked Meteor for it’s efficiency really want.
Then, in terms of efficiency, most of the plan for the future seems to put efficiency on the back burner, which is very worrying. Nearly all major changes will be making more work for us, not less. Even more refactoring, our packages will be breaking, and it seems things will again become more verbose.
One thing I’m not sure if MDG understands, is what these things communicate to the users of Meteor. It sends a few very negative messages. It breaks trust a bit, considering much of the advertising of Meteor pre-1.3 (and even now) is focused on Meteor being efficient to use, and the “fastest way to build js apps”, but it’s not quite as fast as it used to be, especially if you have an existing project. It communicates to us that MDG isn’t very considerate towards developers in this situation, as refactoring large projects is a nightmare without any added functionality to support it. With the package system eventually being deprecated, it leaves us in a position where our project relies on a package that may not work at all in the future. It leaves us worried about how much more verbose Meteor will be after Apollo (as from all indications, Apollo itself is much more verbose, at least in the last state I took a look at it). It kind of disregards the part of Meteor much of us were happy with, and forces us on to a new path.
Yes, we all know these changes are being made to fix problems with Meteor and resolve some of the biggest complaints of Meteor - but the way this path was laid out is taking away some of the very best parts of Meteor, it made it more verbose (which I’m sure nobody wanted) and it is basically ripping the backbone out of our existing projects as the transition continues.
Thinking about it objectively, does it really sound like a good idea to continue with Meteor considering all these things? When we don’t know just how much more verbose it will become, and we will have to basically refactor and rewrite our entire project & packages that it relies upon? When we don’t know what else will be deemed unworthy and removed next?
I guess if I were to sum it up, my point is that efficiency isn’t just working with it for new projects (although Meteor is quite a bit more verbose, it’s still pretty efficient, if you have a 100% new project). But also, a big part of efficiency is also being able to keep up with the new changes and use Meteor in to the future. That’s the part that seems to not be understood (or acknowledged).
A fork will hopefully solve most of these problems, and if things go well, it will hopefully give my job another option to continue supporting our project that is more reasonable. Because to be 100% honest, Meteor’s path laid out for us is not really reasonable unless MDG starts caring about our situation and giving us features to assist with the transition. Temporary backwards compatibility isn’t really assistance, it’s a push in a direction.
I totally see where you’re coming from on this, and it’s definitely a result of all of our educational materials focusing on more “maintainable” development practices.
I think it’s important to make a distinction between “the tutorials became more verbose” and “Meteor became more verbose”. I think it’s pretty reasonable to say we went too hard on making the tutorials fit the “modern JavaScript” template rather than emphasizing ease of getting started. But the framework works exactly the same way it did before.
I’m still completely convinced that Meteor is the fastest way to build JS apps. It’s not as fast as Meteor 1.0, but it’s still way faster than any alternative I’m aware of.
You don’t need to do any refactoring though. I think perhaps we tried too hard to bring people into what we believed was a better way of writing apps than the classic Meteor way, and neglected to reassure people that the old way they were used to would still be around. This is an honest mistake on our part - people inside Meteor and most of the customers we talked to about it were convinced that using modules and NPM was much better than the classic auto-loading system.
Perhaps - I’m curious if we can just solve them directly, though.
But do we really want that? Because being so unopinionated means:
-Having your tutorials in a couple of flavours.
-Having the forums filled with questions where user A does it the old way and user B does it the new way
-What direction do I follow when learning Meteor? What book should I choose? … Learning a new framework is always a bit confusing at the start and this doesn’t help.
-This is part of the reason why the meteor build tool is very complex, which makes it slow, buggy and hard to contribute to.
A fork could be a good thing for Meteor since it could allow to throw out the old stuff somewhere in the future, without screwing the people who like the old stuff.
It is quite normal that there is a bit of a controversy when something new is released, but in that controversy most people are still hopeful and feel that although there might be some pain, it will be a good thing in the end.
In this case it’s different. I read about the plans and changes and all the fantastic things the masterminds are creating, but… I’m not the least bit excited. I have no need for the stuff that they are building. The right thing would, IMHO, have been to announce a new project, with a new name, which would have attracted those interested in edge tech and allowed those who just want to create some functional websites swiftly and painless to stay where we are.
It would have saved everyone a lot of work also, had Apollo or whatever it should be called, started from scratch (just taking the good bits from Meteor (apparently not many)) since it seems like most of the work involves removing Meteor from meteor. Also, backwards compatibility is little worth when we have to refactor anyway. One refactoring when The System That Came After Meteor is finished would not have been more work than what we need to do now.
I know, the developers needs our respect and gratitude and they have mine, but they are not the only ones investing time and money in this.
I hear you and this effort came from the frustrations of the changes (and how they were communicated) to the platform.
Our hope, is that as the community takes an active part in this, we will be able to please as many stakeholders as possible.
Personally, I’m not sure that everyone using the old stuff would see it that way.
I’ve thought about this a lot as well. Angular 2 is basically an example of that approach - they announced they are building something completely different that will require a lot of work to migrate to. I still don’t know if it was the right approach or not.
Apollo did start from scratch. That’s why it’s called Apollo, and not Meteor.
I don’t agree. Try going to your manager saying you just want to refactor your entire application for the next two months…
Having backwards compatibility allows to refactor part by part while you still keep building new stuff. In each development iteration I try to incorporate some time for refactorings anyway, since there’s always some technical debt that builds up over time in some areas. Meteor has always supported this and I’ve found that very valuable.
Don’t underestimate the stability of Meteor. If you have a well tested project including chimp test, so really browser testing, and you read the change logs upgrading is not a big pain.
It may feel like missing the new features but it’s stable. On 1.4.1, most recent version now, an app with atmosphere packages and blaze still works just fine.
We have one rule on this and that is that we stay up to date constantly. So yes the day after a release we start spending some time on upgrading etc. but we do not upgrade to all new ideas like angular, imports etc.
For example in our case es6 was very useful, cleaner classes, less prototype and scope stuff. It improved our development experience and most important readability for developers new to the code.
We just implement that, even our tinytest cases keep working.
What I do see happen and which I find really risky is staying a lot of versions behind. Then you will likely get stuck. Because every upgrade has some issues. But what you don’t want is all those issues on one big messy stack. Then upgrading will feel like climbing the Rocky Mountains. We like the little steps.
That being said there are major issues like longer build times, unclear npm errors which will bother when you don’t use it. Yes, there is a trade-off. But if you do not yet use them they will be quite minor.
@sashko is right, the guide went too far. I think it might be great for newcomers but it’s an offense, not sure on the wording here, to existing invested users.
The guide is something like an optimal all shiney brand new app. And the old docs kind of disappear. That’s not a good thing for the future which needs to be addressed. Just like he addressed the involvement on the forums. It’s not perfect, but so isn’t the software you write. We all need to try to accept failures and changes, learn and improve.
Don’t underestimate the stability of meteor, it is actually more stable than you might expect. The guide is trying to catch up. It started late but becomes steadily a great resource.
Yes meteor is not perfect but also it is a very good platform. Nobody knows an absolute direction which meteor is going. But every latest release shows a quite stable release for this kind of platform. And for sure you don’t have to adopt to every new feature now packages like blaze, today a first time, gets moved into a separate package. That is one great step into the future. It seems small but it’s not that simple to move into that direction. Fact is it is happening and more steps are being taken.
You see how little I know 
So much of what is in the pipeline are of no interest to me, at least not until it is finished. If anything is ever finished.
As I said, backwards compatibility is not much worth if you have to refactor anyway.
If this “new” Meteor would have been a separate project I would probably not have needed to do any refactoring at all. Maybe next project would have been with Cool Stuff, maybe I would refactor some of them if it seems worth it, maybe not. Currently I have no choice, I have to sit on this morphing vehicle or jump completely. Well, if the Community Fork does not become a success.
Apollo is a data layer not a new Meteor.
Yeah yeah, I have already said I don’t know the this and that, and more importantly - I don’t care. What I care about is that Meteor is going in a direction where I have to care.
Well the answer to that is: currently not. You will encounter that the guide does not show the classic approach, though most info is there. But in terms of functionality it’s all there in 1.4.1. No essential parts are changed or removed.
And now with more packages becoming separated you may have to include them again but they are the same. @mitar also intends to have blaze stable with fixes and develop a new v2 on the side.
That being said, it’s software, it will change. So build your application so you are stable and able to change. Meteor actually takes part of that, see: iOS 10 compatibility you could update all by yourself or wait for meteor to integrate the changes. That’s what you get when choosing for a platform.
I am working on two bigger projects, both with meteor/mantra/react. Mantra tells you perfectly, how you can embrace a component-driven design and react is definitly the better tool for this approach, than blaze. It sometimes scares me as well, how different it is than the classical meteor way, its also much more verbose. But it gives you also so much more power and control, so that - at least for me and my team - , this is definitly the way to go (for now).
Pub/Sub is the only thing, that doesn’t really fit well anymore. I’m therefore desperately looking forward to Apollo! 
I also have some blaze apps and I love blaze for its simplicity, but they only require little maintenance and i am pretty sure that blaze will work as long as these applications are alive. I am glad to see it in good hands with @mitar.
Is there suppose to be a link that comes with this? 123 replies and for what?
Anyone willing up update and maintain a new version of mantra? At the repo there were no major updates/improvements as @arunoda is now working on other projects (zeit.co).
I have a project running on mantra as well and I really like the container/component-driven pattern.
I am still working with mantra (altough pub/sub) and like it too.
there are three pieces of mantra:
mantra-core: is a small library that does some basic wireing of (client)-modules At the moment mantra-core does what it should, but there are minor issues with it (It has some imports of react-komposer and react-simple-di that need updates.) as well as some missed opportunity to make the module-stuff more flexible (e.g. server & client side modules, leaverage meteor 1.5. code splitting, etc.) so i am thinking about to fork it, if needed. I also would like to see it go more in direction of recompose, redux and apollo in the future.
mantra-spec: is only a written specifications. The ideas are still valid, but in some details its not up to date anymore. But honestly, I don’t care. 
Having a spec is nice to have, but something more to maintain.
mantra-cli: I am contributor on mantra-cli and add new features occasionaly. At the moment, i have a planned release that allows a slightly different folder-structure that enables meteor 1.5. code splitting.
I have also some mantra-based npm modules that emerged from some projects we did at our company:
https://github.com/panter/manul-i18n (translation solution)
https://github.com/panter/manul-files (slingshot based file uploads)
https://github.com/panter/manul-admin (a ui-less, simple admin-solution that does basic wireing for CRUD, a default UI is in the making. documentation is not totally up-to-date yet. )
https://github.com/panter/manul-alerts (a toast/alert library)
They are all very early and are subject to change, but all have proved usefull, so i hope I can release a version stable 1.0.0 of one of these modules in the next months.
Hi @macrozone,
I really appreciate you working on Mantra, especially since we’re betting on it for the next version of our service. Are you familiar with the work of @warehouseman?
Our company is in the process of growing, in we’d be interested in chipping in on funding the development of MantraJS.
What do you think about such a collaboration?
I don’t pretend to be a Mantra expert. In fact, my original tactic with taking over maintenance of the Kickstarter was to learn from the experts by getting them to discuss the validity of what I was doing. It took me a while to realize that Mantra was abandoned entirely, not an expert left anywhere in sight and that I’d be plugging on all alone.
So, my work on it has been more about building out bits that interest me, and increasing my understanding, than meeting anyone else’s expectations. I’m extremely eager to have collaborators, if only to validate what I have been doing.
Does that alter your thoughts about collaboration?