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
So I’m a part-time Meteor developer who runs a non-tech business. I used Meteor to build some internal software that vastly improved our operations. I’m in the process of upgrading/learning everything about Meteor 1.3/1.4+ES6, and it has been awful (I can’t even get my app to finish the update to 1.4). The added complexity of ES6, reliance on community packages that are constantly changing, and out of date tutorials littered across the web have made things very challenging.
I don’t think this is solely the fault of MDG or the Meteor community, because the wider JS ecosystem is rapidly becoming much more complex and the framework is trying to stay relevant.
However, when Meteor was brand new, there was something special about the framework, and I think that has been lost - ‘the Meteor way’. I think many thought this was the built in reactivity, because that was a shiny, new technology at the time, but I really think it was the simplicity that lowered the bar for beginning programmers. If anything, Meteor was making web development accessible to those who didn’t have the time or training to overcome the high bar required to make complex web apps. That’s no longer the case.
I don’t want to speculate too much on why this happened, but I’ll throw one theory out there - many developers who have been most vocal in the community are advanced users. They’re the most vocal because they have experience working on and contributing to open source projects, and aren’t afraid to post on forums and make contributions. However, they’re needs are decidedly different than those who are new to web development. Call it a blind bias towards advanced users providing feedback to MDG or whatever you want, but I’d encourage MDG and the leaders in the community to ask themselves if they are soliciting feedback equally from new Meteor users and advanced users equally.
To provide a hard example of how complex a building a new app with Meteor has become, take a look at how many loc are in the todo example app today vs at Meteor 1.0. If I wanted to build a complex JavaScript web app where I had complete control over every aspect of the stack, I would just roll my own using a node.js server. If Meteor wants to be the fastest, most technologically advanced js framework out there, they will always be 2nd place to rolling your own stack, and also serve a smaller and smaller user base, because most people don’t need that. If Meteor wants to focus on building an easy to learn/use development experience, then I am pretty sure they will always have new users willing to try out the framework, as more and more people are teaching themselves to code every single day.
As far as breaking off a 2.0 branch and backwards compatibility, I don’t really know, but I would encourage MDG to focus on making things as simple as possible for new developers, part-time developers, and those looking to get MVPs out the door quickly.
11 Likes