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?” 
That’s where we are coming from as well. Apollo is the “new product”, it’s questionable whether it’s valuable to rebuild a whole new full-stack framework from scratch, which is basically what we would be talking about if it wasn’t something current Meteor apps could all migrate to, and it didn’t use any of the parts of current Meteor.
1 Like
@sashko my opinion remains the same about what should be 2.0, but thinking about the other side:
I would fork (if needed) and create a separate product. By not doing this and keep improving (it’s pretty clear where MDG wanna go, for me) my guess is that new Meteor will replace the old one.
Having a more complex / extendable product is fine, but calling it 2.0 means, at least for me, that at some point I can migrate. I understand that there’re branding and business discussions around this, but that’s my point as a developer.
Maybe with this scenario it’s time to assume that the new is the chosen one and leave Meteor as classic? And, of course, to community.
Developers will always want compatibility. It’s a silly question. But what does it really takes? For you, as a Staff, why are you considering this?
We’re using Meteor 1.4 in production for two apps. So we’re not really keen to make something totally new ourselves either.
2 Likes
It’s interesting to me to think about this kind of issue, because I don’t think there’s every really a right answer.
I think what would make sense to me to have a fork/repo with the core packages (and maybe a router?) from 1.2 that a Meteor newbie could clone to get started with the basics of accounts, pub/sub, templating, methods, etc. If devs are keen on running on this antiquated stack, I could see security updates supported by production apps running at 1.2?
Otherwise, for me at least, every 1.x release so far has been worthwhile in terms of how long it’s taken to migrate and the payoff. (Of course it’s not always so obvious in the middle of broken deployments, etc.)
I guess I’m curious what the real issue is here. Is the cost/benefit to the current migration and upgrade pattern not working for a majority of devs/projects?
We already do ship security updates for 1.2 as necessary - we’ve historically shipped patches for every release since 1.0 in the case of security issues.
3 Likes
Sorry, not trying to throw you guys under the bus! More just thinking about long term strategies for 1.2 =)
1 Like
Exactly my point, over time mdg will have other priorities and issues with minimongo, for example, may not be fixed.
1 Like
Sure but if that’s the case we will certainly accept fixes from the community and help enable community maintainers.
1 Like
For me, it would make sense to slim down Meteor.
If Apollo is the new 2.0 then let’s strip out from Meteor what does not make sense anymore, that is what Apollo does better.
Meteor should then be installable via npm, as already on the roadmap, and be developed focusing on just few awesome features that can make it stand out from the crowd once again.
We would use standalone Meteor for easy, not complex stuff, and add Apollo for the supa dupa projects.
3 Likes
I think it’s worth mentioning that if you don’t want/need to have data handling with Apollo/non-mongo databases then it’s still ok to keep using pub/sub 
I have a Meteor app that is 99% clientside and the only server bit is logging in. I’m planning on migrating this app to a static html/js deploy via S3. It’s already using imports, React, and Meteor methods (to another Meteor server acting as an API) and npm based packages.
The planned migration path for this one is to migrate login/signup to REST via the Meteor rest package (on the API) and then switching Meteor methods to Apollo mutations, and a couple subscriptions to Apollo queries. It’s slowly getting migrated.
For really complex apps with lots of packages using pub/sub I think the best migration (if needed) may be to accept that the app will use both pub/sub and graphql and then slowly migrate to graphql as you add features or improve/bug-fix old features.
1 Like
Also after re-reading my last post I don’t mean to come across as migrating away from Meteor, rather the flexibility if gives you if your business needs require it.
I still have 2 apps that are 100% Blaze, Pub/Sub/, autoforms, etc… 
I very much agree with this. I see “future Meteor” – hereafter referred to as PAM (post-Apollo Meteor) whereas v. <= 1.4 is simply “Meteor” – as a build-tool. In PAM, Apollo is the data layer and it manages code that connects to data sources – React/Vue/flavor-of-today is the view layer and an Apollo plugin passes data into each component. PAM becomes an opinionated collection of development and deployment utilities (e.g. run web server + Apollo server + maybe spin up MongoDB in development, provide boilerplate shortcuts akin to Meteor.isDevelopment(), and perhaps facilitate hot-module reloading in development as a bonus).
Clearly, this functionality is a significant pare-down from today’s Meteor. That means builds are as fast and light as I think current tools allow (does it get faster than Webpack?). This also means that PAM is in no way compatible with Meteor packages. PAM would bear a new name, while what folks have referred to as “classic Meteor” can forever remain just “Meteor”.
This breaking change would be painful at first for devs who move on to PAM (before Apollo-compatible replacement packages are written), but would turn out to be a healthy choice in the longer run because it would foster a new ecosystem built expressly for Apollo. A clean split between Meteor and PAM would make it clear which packages fit with which platform.
2 Likes
For me Meteor has always been attractive because it’s the easiest way to do authentication, pub/sub or websockets, and in 2012, handling modules.
I think Meteor has a strong future with more than just a build tool. One of the things I hoped the “post apollo meteor” would turn into, is a very nice developer API on top of standard tooling that could be opted out of at any time.
For example making a really nice plug and play implementation of Redux, Mobx, etc… where it’s typically a lot of boilerplate to get it going. Instead of example apps they could have boilerplates with a convention and for different purposes (like user login). Perhaps a couple of standard authentication solutions could be provided (even if it’s just in boilerplate form), in order to work with other systems… basically preventing the walled garden issue.
Apollo has already done this by making GraphQL easier to use than any other solution, and were the first (as far as I know) to implement the cross platform GraphQL type definitions instead of verbose code.
5 Likes
Interesting. Do you see Meteor, then, as an abstraction built on top of those common libraries? Rather than Redux.createStore(), would you rather use Meteor.addReducer()?
I guess I envision a build tool because I struggle to see what’s left over when you remove Minimongo, (much of) DDP, and all the Mongo-specific packages from Meteor.
1 Like
So for Redux my personal take to setup React, Redux, react-redux, redux-devtools, and react-router-redux was this api. It sets up a router, wires up redux, react-redux, and redux-dev tools. It shouldn’t take 200 lines of code to set this up 
import {registerRedux} from './simple-react-redux'
export const {dispatch} = registerRedux({
routes: require('./routes'),
renderToElementId: 'react-root',
reducers: {
app: require('./reducers/app'),
posts: require('./reducers/posts'),
},
});
and it could be further tweaked and augmented as needed for more complicated apps:
import {registerRedux} from 'simple-react-redux'
export const {dispatch} = registerRedux({
// default options are overridable
debug: false, // turns redux-devtools and logging on/off
renderToElementId: 'react-root',
disableLoggingMiddleware: false,
disableDevTools: false, // turns off redux-devtools middleware
disableLogger: false,
// pass in Routes component
routes: require('./routes'),
// router reducer is already included, add more as needed
reducers: {
app: require('./reducers/app'),
posts: require('./reducers/posts'),
},
// optioally add your own middleware
middleware: [
myCustomMiddleware(),
],
});
This is a wrapper I wrote a while ago: https://github.com/AdamBrodzinski/simple-redux-react
I guess I envision a build tool because I struggle to see what’s left over when you remove Minimongo, (much of) DDP, and all the Mongo-specific packages from Meteor.
Makes sense. I guess I always viewed minimongo as a really nice api/integration to an in browser cache/db like PouchDB.
I started out using Meteor packages for everything but stopped because there are so many bad ones out there, especially ones that don’t take performance into consideration. Building an app on these can result in something that crawls and is very brittle (Ruby on Rails has the same problem to be fair… the gem install hairball is too easy to save time upfront).
DDP is very cool but the lack of other systems being able to use it is a showstopper for me.
2 Likes
@SkinnyGeek1010 we are going on the opposite way here
We were using s3 to serve a static web app built with Angular. After almost 2 years doing this we are moving back. 100% serverless app need to be deep studied before you implement that. Not saying that it’s your case, but it was ours (sharing experiences). At some point we needed to merge heavy API results, have a better control of caching and other stuff that are only (or way more easily achieved) with a server.
Agreed, but that requires a lot of compatibility. I thought that this wasn’t your goal here.
What about the npm module that creates a standalone DDP client?
I don’t think MDG would take to the idea of leaving potential customers to the “classic” business strategy. Therefore the metamorphosis into an Apollo integration point we go.
Apollo is the foundation for the new revenue stream. And every platform willing to open up is a winner.
1 Like
As long as build times get better, without having to spend weeks migrating code, I’m happy with wherever MDG wants to go.
2 Likes
I hear this completely, but to me its a question of what the focus of Meteor’s future is.
Is it gaining wider adoption across the JS community to the detriment of backwards compatibility? or is it maintaining backwards compatibility to the detriment of wider adoption?
Apollo was in part spawned because of realization that building a monolithic stack requires just too much manpower and alienates part of the larger community when certain design decisions are more or less enforced (Mongo).
What does the future of Meteor look like given this lesson learned? From my perspective the only realistic long term future for Meteor that includes wider adoption would be to switch towards focusing on being the best boilerplate of community adopted tech + plus whatever ingenuity you can bring to that.
3 Likes