Does It Make Sense to Start a Meteor 2.0 to Retain "Classic Meteor"?

core
36

@SkinnyGeek1010 we are going on the opposite way here :stuck_out_tongue:

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?

37

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
38

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
39

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
40

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
41

It always comes down profit margins. MDG is a corporation with VC backers that want a ROI. MDG couldn’t figure out a way to make the ROI attractive enough to their VCs with the Meteor classic strategy.

Enter Apollo and the new business strategy around it. Part of the new Apollo strategy is to leverage existing Meteor classic “potential” customers, hence Meteor classic is being transformed into an integration point for Apollo.

Corporations corse correct, drop products, change strategies all the time. It just so happens that MDG had a good product in 1.0 and was growing their install base rapidly, but like many startups, profits were an afterthought. This caused its own problems, for just a couple of examples,

``> MDG is in a position where they’re having to do damage control with their existing install base,

``> MDG is having continue investing resources in their original “abandoned” business strategy (aka Meteor classic).

In an alternative universe, if MDG was making sufficient profits and growing their install base with their Meteor classic/Galaxy strategy – we’d have an army of MDG devs working away improving Meteor classic as we speak.

3 Likes
42

I think this is an accurate description of the situation.

That would have been great! Meteor classic was really unique in terms of developer productivity, I’ve seen many frameworks and technologies in the past and it was really a breath of fresh air, it just worked…

What is interesting about Meteor classic is that it opened the floor for many entrepreneurs and non-technical people to start building apps with little programming background and I think there is a long-tail of potential developers that perhaps could have been monetized…

https://i-msdn.sec.s-msft.com/dynimg/IC136879.gif

But echoing what @bsbechtel said above, I also think that advanced users tend to be more vocal, active and demanding and might resulted in blind bias toward them…

2 Likes
43

I too was a new developer when I started developing with Meteor and the simplicity of getting started was a huge benefit. As @aadams mentions though the the pivot away from that simplicity model was for two reasons AFAIK: 1) the monetization approach is through hosting and you just can’t make much money hosting beginner apps 2) making things that simple in some cases lead to tech choice limitations and scaling issues, so presumptive developers of higher use apps were hesitant to go all in on Meteor

For me the talk of 2.0 is a lot about re-aligning Meteor with the perspective and philosophy that led to Apollo. Its been said many times over by MDG members that moving away from developing a walled garden to developing stuff that has a wider applicability is critical. So the march of 1.3, 1.4 and beyond is to start de-coupling some of the pieces. Make more of them stand on their own. The problem with that is though is that many of them will not stand on their own or its unlikely that MDG will want to commit enough resources to make them stand on their own.

Will the build tool ever stand on its own, or otherwise be competitive to Webpack? If it won’t why put more time into it? From a legacy app perspective, give me an relatively straightforward migration path to using Webpack in my Meteor app an I’m happy to do the work.

For new apps, I personally want Meteor to be a collection of loosely coupled widely adopted packages with just a little bit of MDG magic sprinkled on top. They can stay focus their extra polish on Apollo and maybe even Useraccounts. Make it easy for me to deploy that app to Galaxy and I’m happy as a clam.

Or maybe Saturn is Meteor 2.0 and nobody wants to say it too loudly yet.

5 Likes
44

I have a hunch that you’re spot on there. That’s totally okay with me, Meteor is pretty stable and mature at this point (despite all the bickering and complaining on these forums). My only issue with Meteor is scaling with pub/sub and db-heavy apps, and Apollo should help solve that by letting you use whatever db solution meets your needs. Saturn appears to be taking the Meteor ideology of making setting up an app and it’s main features stupid simple, and applying it to the more broad and open JS ecosystem instead of entirely in-house solutions. That sounds perfect to me.

2 Likes
45

But wait, according to one of the Transmission podcasts (I’ll go back to find it eventually), Saturn is NOT Meteor 2.0, was for internal use, and (I can’t remember exactly) will be discarded?

@SkinnyGeek1010, do you have some inside-baseball about Saturn?

46

any chance you’ve got a link to that podcast? I haven’t kept up with Transmission since the first few, that was just the impression I got from awhile back

47

I think this is what you are looking for:

1 Like
48

TL;DL on the Saturn part of this:

Saturn was an experiment on how to setup a javascript project that has a fairly complete non-Meteor stack. Webpack config, SSR, server framework, test infrastructure, babel, hot module reload, etc…

Giving it a formal name of “Saturn” probably gave the illusion that it is more important than it is.

For now its going to stay internal:

  • Not complete enough for people expecting a Meteor like experience
  • Too magical for people who want to set stuff up themselves

Aware that it probably does not make sense to make the build tool a feature for feature WebPack competitor.

1 Like
49

Note that we don’t use Saturn even internally right now, as far as I know. We are using Meteor for the new Optics product.

3 Likes
50

Optics? Any chance that’s A/R related?

51

I think this is the relevant optics link: http://www.apollostack.com/optics

52

Ah. Thanks. ‘Optics’ as in ‘Insights’. Gotchya. :slight_smile:

53

This seems right - just make a new name, and new product. Keep Meteor more or less Meteor in a backward compatible way, while still iterating forward where you can. I think this is exactly what MDG is doing, and that’s great.

At the same time, new products are great! Company != product. It’s good for a company to have more than one product, and products change all the time (imagine if the iPhone 7 was just like the original iPhone).

54

I don’t think anyone is suggesting otherwise. I myself have said this much in another thread some days back. But one thing, I’d change your condition somewhat, to this: MostForProfitCompanies ==Product(s).

What I think says a lot is the fact that MDG post a comment like this – which is fine – but then does not squash talk of Saturn one day replacing Meteor at the helm.

55

Agreed. At first (when I first created this thread) I was thinking a 2.0 would be a better solution… thinking about it further, a new product name would be a better alternative than a 2.0. Not only for backwards compat. but the other stack puts you in quite a different mindset when building (functional + declarative).

1 Like