Sure, just publish it as a fork on Github. I would be very keen to check out what you’ve added.
Please don’t be concerned. If we go back to my orginial sentence I state:
"MDG will no longer maintain Blaze… [In this sense] post 1.4 it will be officially depreciated… The jury is still out as to what becomes of Blaze. [new emphasis added]
I don’t want developers to pretend like nothing is changing. I think it’s important for developers to have a full understanding of the situation so they can make more informed decisions. Judging by some of the comments on this thread, some developers where confused by earlier comments and chose Blaze, when they might have chosen React.
I don’t want to parse terminology, but to me what said above is still valid. As far as new development and maintenance is concerned, MDG will no longer be involved with Blaze. To me this means Blaze is “officially” deprecated. To me there is no negative cognition here, it happens all the time (but I can understand the sensitivity and will try harder to choose softer words next time). But, again as I said above the jury is still out on what becomes of Blaze, because the community has not had a chance until now to step up and advance the state of the Blaze art.
To further put things into perspective, this could be the start of the golden age for Blaze. Blaze has been almost untouched by MDG for a very long time. The community has an opportunity here to step it up and really advance Blaze into the technology we always knew it had the potential to become. The community still has a moment now, let’s see what happens.
Again, I don’t want others to get the impression that MDG is taking care of Meteor classic components. I want developers to understand that they need to step up and take on DDP, Tracker, MiniMongo – to advance these components – because I think MDG will not anymore. For example, when MDG sends Blaze out to the community, do you think MDG will not do the same with Tracker? Just look at this post on github from today:
@mitar referring to adding Blaze to NPM:
OK. So, feel free to make a pull request moving to NPM. I think we could extract Blaze to it, and then use compiler plugin from Meteor package only, like @stubailo wrote above.
The issue with NPM is that there are also dependencies. Like Tracker. Then we have to move those to NPM as well.
@stubailo, what should we do with those packages? Would MDG be interested in moving them to NPM and then providing just thin backwards compatibility Meteor packages?
…
@stubailo, @tmeasday, what do you think? Could we move Blaze dependencies to NPM?
…
@stubailo 's response:
@mitar Yeah I think it could be cool to have tracker on Atmosphere just be a simple package that Npm.depends on tracker from npm. Do you have an idea of the full list of Meteor packages that would need to move to npm to make this work? Is it 2? 10? 50?
Or how about the future of DDP?
There has been very little “direct” statements from MDG on any of this. We’ve come to know what’s going on by small posts by MDG here and there. For example, just in this thread:
I agree, I’m on 1.3.5.1 and I’m enjoying it. As I’ve stated in previous posts on this thread, we can keep our Meteor classic. Just know that in the relatively short term, the various tech within will not be advanced anymore by MDG – again the developers in the community that have the time should get involved if they feel passionate enough. Further, we will be able to pick and choose what parts of Meteor classic we want to keep and throw out. For example, if I want React with DDP/Tracker/SubPub and Mongo, I can have that. If I want Blaze with Apollo, I’m all good.
This is actually the best of both worlds now that we have more choices. We have the stability and tight integration of Meteor classic, with the option to replace pain points with tech from NPM. The only question now is: will the community advance the tech that we know collectively as Meteor classic.
I’m right there with you. I’m all for solidarity and comradery. We’ve all been in the Meteor-classic trenches for a year or more. But I also have to be practical.
Let us speak plainly, if we are wrong, then we’ll be corrected soon enough. So please, if someone feels passionate about Meteor-classic and wants to get involved, pick a portion of the stack and ask MDG if you can contribute. Become the owner of that portion and advance the state of the art. We are all counting on it.
I’ll answer the question, is it time for a community fork? Doesn’t seem that way for now, since MDG is willing to help guide the community with the heavy lifting.
There was a bit of a conversation about it above, but I don’t think we really reached a consensus. Should we open a new thread about it?
I’m 99% sure MDG will not be able to prioritize this, since we’re going all-in on the "GraphQL is the abstracted syntax for any database or backend API angle (as you can tell from Apollo). But I suspect this can be done entirely in community packages, and if there is anything we can do to make it easier to build those, then I’m all ears.
We also built a minimongo-compatible postgres experiment here: https://github.com/meteor/postgres-packages
It didn’t require any special support from the rest of Meteor, except for the fact that Mongo is a bit privileged in the command line tool (which we can definitely work on fixing)
That’s literally Apollo. However, as @ramez mentioned above, you can just as easily put server-side SQL data into a Minimongo collection on the client, so it’s just a matter of refactoring the server-side accounts code that accesses the “real” database.
We sure appreciate it now! I hope everyone agrees that we’re doing much better in this department now than historically.
All of our production apps use Meteor - it’s not like we are going to rewrite them from scratch. I think it’s been a flaw, not an advantage of Meteor, that it was entirely built and maintained by one company. Any healthy open source project needs to have multiple investors, and while Apollo is built that way from the start, Meteor needs some work to get to the point where it can have a diversified set of stakeholders and not rely on one particular business.
I found that using React in my apps provided a HUGE value add, but YMMV.
Really excited about this conversation!
Also, not that this is relevant but I built a hackathon app last weekend with Meteor 1.4 and it was pretty great; so I still truly believe that Meteor is the best option for getting an app out the door quickly. The main issues from that POV are (1) the getting started experience has acquired a few speed bumps (but still way easier than Webpack/Express IMO), and (2) there isn’t enough flexibility on the top end for people who want to be more involved in technology choices, like databases, etc. I think (2) is currently being addressed in spades, (1) is maybe something that the community could help with.
5 Likes
Regarding a fork, I’m mixed both of excitement and reluctancy.
Right now, I really do love Meteor “classic”. As it works now I’m very happy with it. My biggest project for work we have decided to stick with Blaze. And while I would like some improvements (such as improvements to loading files/loading speed, security updates in the future, more efficiency improvements with things like imports, etc). I’m pretty happy with the overall processes of using Meteor.
On the negative, right now using Meteor I’m a bit worried about the future. 1.3 made Meteor much less about being pleasurable to use & less focused on development speed. I’m worried about this continuing in to the future, and with the major changes, I’m not sure if more and more of these efficiency features are going to be deprecated for functionality. And I’m worried that the Apollo-Meteor stack will function very differently from the current way Meteor functions. I’m pretty happy and don’t want much to “change”, I just would like some “improvements”.
My #1 concern is efficiency, it’s why we chose Meteor in the first place. Our biggest concern is Meteor is becoming less efficient, and has became harder to train new employees in.
Regarding a fork, I’m excited for that idea because it would ensure the “Meteor Way” as it exists now, without any more efficiency downgrades. It removes the deprecation worries, and allows us reassurance that any major security updates to Meteor could be applied to the fork, and Meteor won’t just go out of date suddenly.
But I’m a bit hesitant. Because I am happy using MongoDB for the moment (although this wouldn’t matter to much if as you say, it still uses Mongo syntax). And I would like the ability to do some projects in React if I decide to - even though we have not switched our main project to React, it’s a skill I’m working on & practicing so that I am prepared for any projects in the future.
So I’m wondering how exactly do you plan do handle these potential issues for users? Is the intent of “Meteor Classic” just focused on the current data layer? Or is it intended on keeping a more opinionated stack? Will Meteor Classic still have all the current options we have in Meteor 1.3/1.4? (I think 1.4 would be a good starting point due to improved node version).
Can you go into detail about what in Meteor 1.3/1.4 you consider to be an efficiency downgrade?
I think we are starting to feel the need of a really good Meteor IDE.
Webstorm IDE works great with Meteor and provides breakpoints on the server as well as on the client. When you set up a new debug environment, you just select Meteor from a dropdown menu.
2 Likes
Yup, I tried it, but it has some issues with Vue 
Wow, great!
My dream, since the first day I met Meteor (about 2 years ago), has been to have the same thing exactly (without all the mess of Apollo and alternatives to Blaze), but with SQL, especially PostgreSQL.
SQL in general and PostgreSQL in particular, was the first wish in Trello, with more than 1000 wishers, while the React support was the last wish, almost with no wishers.
A combination of Blaze with PostgreSQL (and also MySQL, but Postgres is more urgent) can make Meteor a popular option, and even beat the leading frameworks.
If it succeeds, there are 2 future scenarios:
- We will have the best framework
- MDG buys you
Both of them looks great…
If you have SQL support, with reactivity and accounts support, for the classic Blaze-based Meteor, you’ll become the king of the web and mobile development!
Now I am still Meteor newbie, but when I’m more than that, I’ll be happy to help!
2 Likes
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.
1 Like
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.
2 Likes
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.
1 Like
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.
1 Like
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.
2 Likes
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.
2 Likes
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.
2 Likes
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.
6 Likes
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.