To preface I would like to keep this a discussion and not a trolling thread.
Meteor is going through some changes and a lot of people don’t care for it. While listening to the latest Transmission episode with @sashko and @pauldowman I was wondering why MDG doesn’t cut off a new version 2.0 at some point in the future? Having a 2.0 could eliminate the backwards compatibility struggle.
Ruby on Rails is on 5.0 and every major release has breaking changes that can’t be easily upgraded and large companies are still on v 2/3/4 and still productive.
Meteor 1.X could be classic Meteor and the atmosphere ecosystem can exist for those packages. Security updates can still be applied and users who are happy with this stack can enjoy a stable system. Open source could add in new features as needed (but stability seems to be a major concern).
Meteor 2.0 uses a more “modern” stack and doubles down on making that as fast, easy and efficient as possible. NPM could be the only way to get packages. If React and GraphQL is going to be the ideal standard, Meteor could become something as good or better than the Ember CLI… making it the most productive Meteor stack (just spitballing).
Does this seem like this would be the most helpful for both parties?
I’ve had a similar idea… basically, as MDG embraces React, GraphQL, Webpack, etc, it just seems to make more sense to build a new stack instead of trying to mold Meteor into something it wasn’t mean’t to be.
People we’ve talked to don’t want a 2.0 - they want backwards compatibility. I’d be interested to hear more from people on, say, Meteor 1.2 and how they would feel about this.
I can only speak from my own position, but my main concern is that the large project I am working on now still works a few years down the line from now. Which basically means any security issues, etc, need to get handled. My #1 worry is that there would be a vulnerability found that would force us to upgrade the project, which would take loads of extra work to refactor.
Regarding backwards compatibility, the current backwards compatibility for things like imports is great. In my situation, after meeting with management, the decision was made to hold off on imports until backwards compatibility is removed. We rather all work hours be dedicated to development of our software for as long as possible.
So I think to clarify things a bit, the reason many users (such as myself) have hoped for backwards compatibility is simply because we want to make sure our project still works in the future without a huge workload.
I think this idea would be completely fine for most users. It’s really the same idea as the “fork” discussion last week. It would solve a huge issue for my current project, as well as solve a big problem in the Meteor world right now, where developers are scared to start a project with Meteor because of all the upcoming changes.
So count me as +1 for this idea. I don’t see why most users would be against this, the only people I could think of that would really be against this, is if they REALLY need X upcoming feature for their current project. But I think in most cases, if Meteor 1.4 is not able to do what they need for their project right now, they likely would not have began their project in Meteor. And if this idea does go through, and they are told up-front that they will have to wait for Meteor 2.0 for that feature, that is a clear message they will be able to plan around.
A note to MDG staff - a lot of negativity is out there for the poor communication from MDG, but if you were up front as I just mentioned, this would allow teams to clearly work around MDG/Meteor’s plans - and that’s where MDG has been lacking in the past. I can personally say, my primary issues using Meteor as a whole, were worry for the future.
Last time I played with Apollo it required a lot to get data from the server to the client. Is it any easier now? Is it reactive like old Meteor or Horizon?
That’s why it has a different name, and is not backwards compatible in any way at all - it’s our new interpretation of how this stuff should work, not an easy drop-in replacement.
I get that it’s not backwards compatible, the question is “Is it easier to use than a few months back, or does it require the same amount of effort to get it working?”
Meteor set the bar in terms of developer experience, moving data between client and server. The people at Rethink met that bar with Horizon. Firebase met that bar with their service. Last time I checked Apollo was far from it, given the amount of code/effort involved in getting data to the client (I don’t think it had reactivity, don’t know about that now).
Meteor’s data system only works with MongoDB. Horizon only works with RethinkDB. Firebase only works with a proprietary service. Apollo works with everything.
Isn’t this the point of versions? If you want the stuff from 1.3 and not from 1.4, then you just stick to 1.3. And with the recent update to Meteor to decouple specific package versions from Meteor updates, it’s even easier to only get the updates you want.
If there’s one thing I would like to see in a future Meteor, it’s the stopping of automatic importing and no longer needing the imports folder to do it. I, like many, used to love the ease of simply adding a file and things working, but now, having built a large project, I recognize that imports are the way to go. Since this would be a breaking change, it would have to be in 2.0.
What these systems do with specific databases were pure fantasy before Meteor came along. I’m no expert in JS frameworks and history but as far as I know Meteor was the first to make it dead easy to move data between client and server.
If you told anyone how easy it could be, even if it was tied to a DB/service, you would have gotten a condescending pat on the head and “That’s a nice dream, but here in the real world…”
Saying it has to be hard because Apollo works with everything is like saying “moving data between client and server has to be hard” back then.
Yep I agree. I was thinking a 2.0 is clear to everyone that it’s a breaking change. It also allows MDG to set the build tool aside and start with something (anything) faster. Also it’s a clear marker in a different way of thinking about the view and data handling. It would be easier for people to keep packages up to date if this were that case as far as I understand, since atmosphere packages would not work on 2.0 at all, one could still assume mongo, accounts, etc…
Yeah I figured you guys have already been down this path. I wonder if it were re-asked with a strong priority on maintaining security fixes if that would change their answer? I also understand that the most vocal on the forums may not represent the community as a whole.
In fairness those same users would also have said they wanted support for insert favorite DB without migrating to Apollo if you had given them that option.
Really I think how this conversation is framed has a huge impact on what people will say.
If you give me the choices of:
You can have a much faster build tool with lazy loading that is used by the larger js ecosystem in a relatively short timeframe but you will have to migrate some code.
vs.
You can have a somewhat faster meteor specific build tool possibly without lazy loading in a longer timeframe but you won’t have to migrate any code.
Despite having a production Meteor 1.3 app, I really think I would choose the first option for a number of reasons:
I don’t believe that improving the existing build tool is in line with the refocused part of the MDG philosophy of working on things that have wide applicability
As part of the above I think any improvements will be a stop gap rather than an attempt to make the build tool more widely adopted
I believe that MDG could come up with a relatively easy migration path
I think it would take less time for MDG to do it and maintain the ultimate solution, freeing them up to do other awesome things
It’s something people in the Meteor community want - sure some would want it only if it comes with backward compatibility, but for many I don’t think that is true
@sashko, my company is using 1.4, but just to keep updated, let’s say that we are coding in 1.2 style. From a company view, backwards compatibility is important, but not critical.
If MDG announces that is going to follow this path my main concern would be about support. We are used to incompatible versions. Of course that if you ask I’m not going to say that again
But why do I want that? Simple, I want a stable meteor classic version. A version that I can rely on without thinking about what’s going to happen next. We are already following different ways, why not make this official?
Let’s keep in mind that I’m not talking about rewriting everything if I want to migrate. But maybe 1 or 2 weeks of work to go from 1.4.1 to 2.0? That’s ok.
If we keep pushing new things inside the same version a lot of things that I use on 1.2 will desapear over time, but not for me. With different versions we can release a 1.5 version with fixes that makes more sense for blaze users, for example. Are we going to do this with the current state? I don’t think so.
For what it’s worth, the path to migrating Apollo/GraphQL is fairly straight forward with React. I presume Blaze will be a bit more tricky but i’m not sure. I’m also going to take a stab this weekend at recording a screencast doing just this (with React).
The largest hurdle IMHO is moving to page/template based subscriptions. Once you do that you can remove a subscribe call(s) one at a time and replace those with Apollo and the children should re-render just the same.
With React you would likely use the apollo-react module and replace getMeteor data with that (essentially replacing this.data.posts with this.props.posts.
With Blaze maybe setting the response data into a Session or local minimongo to keep the view templates the same. I think eventually someone will make an adapter much like the React one which can cleanup boilerplate.
[quote="moretti, post:18, topic:29058"]
_Let's keep in mind that I'm not talking about rewriting everything if I want to migrate. But maybe 1 or 2 weeks of work to go from 1.4.1 to 2.0? That's ok._
[/quote]
I think the main benefit of potentially doing a 2.0 is that you could free the large barnacles, like Meteor packages and packager, minimongo/mongodb by dependency, etc… Otherwise a 2.0 wouldn’t do much good. If one was using classic Meteor that would be nearly impossible to quickly migrate to without those.
Anyway just throwing around ideas. I really doubt a breaking 2.0 change that’s not easily upgradable would happen. I guess a new product/name would be more ideal than that.
In two weeks I can (including my team) change packages to npm (if available) and do some good changes inside the app. I agree with you, but it needs to still be Meteor. Otherwise, let’s change this tread to “Does It Make Sense to Start a new Product?”
