Why?
You should be able to revert back to an old version.
Blaze has been removed from core Meteor repository and a community Meteor organization on Atmosphere has been created. I think now it is time for community to start contributing to Blaze. We can also now release our own versions of Blaze.
12 Likes
Awesome. Something so important should also be announced in its own thread as well IMO rather than just 100 posts deep in this one.
6 Likes
OK cool.
My concern was mainly over the incorrect use of the term “deprecated” - a strong negative term meaning that that something is being discontinued and is on its way out, being kept purely for backward compatibility and/or to provide sufficient time for people to move to something else before it is eliminated in its entirely.
For example, Facebook deprecated version 2.0 of its Graph API on August 7th 2014 and they totally disabled it on 8th August 2016, so any app that tries to access it will receive an error.
For this reason, “deprecated” should not be used willy-nilly.
When it comes to Blaze, the only way I would consider correct is by saying “Blaze has been moved out of the MDG meteor repository and is now community-supported”. That way it is clear that it is still alive and people know that others have been assigned the duty of maintaining it - it is not going to be turned off in any sense of the word.
I am not familiar with these indirect statements - I try and avoid making inferences as its easy to get things wrong. As you say, MDG have not made any direct statements about DDP, Tracker and the others. I haven’t really needed them to - the important thing is that MDG staff are responding to and resolving issues on Github and that is really good.
Right now, I see the current version of Meteor 1.4.1 as being the best one MDG have ever released. For us, it’s been a succession of monotonically increasing improvements since we first started with Meteor in early 2015.
As someone whose main business activity revolves around Meteor “Classic”, I want to do what I can to provide the necessary inspiration, motivation and means for its continued support and enhancement.
4 Likes
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