I’m quite not sure what do you mean by zig-zagging? 
Anyway, we declared some rules like for the view layer and other tools from Meteor play nice with it.
As far as I know, Meteor 1.3 will be the biggest hit. There may be some stuff for the data layer along the road. Not sure about the view layer. But that’s fine for Mantra.
To me the solution is easy–well at least straightforward:
End of story. That means no giant meteor fork to maintain of which there are no clear leaders emerging willing to take on such a task. It means core packages are unbundled in a way they never have been. Just giving them their own GitHub repo will go a long way to achieve that; each repo will be more likely to end up with people who rise as their leaders due to their own personal commitment to, maintaining, say, Blaze.
HOW DO WE DO THIS?
meteor-base
tracker refer: ultimatejs:tracker
blaze refer: ultimatejs:blaze
My final thought is: this will also allow for each core package to acquire a life of its own outside of Meteor, something for example Blaze was never able to achieve living inside the gigantic meteor/meteor repo. Packages like Tracker can’t compete with Mobservable or Blaze with React or Minimongo with Redux or LiveQuery with GraphQL or DDP with JS Tokens if they can’t also live and grow as independent entities. I’m not sure what the thinking has been to keep them so sequestered within Meteor–I assume because originally there was a lot more coupling–but they seem pretty unbundled and decoupled at this point; they just aren’t made to feel that way to application developers. Blaze certainly is unbundled. So if the final step is mainly about interface and marketing–and at least for many core packages is easy to do–it should be done! The packages whose code isn’t truly unbundled yet just won’t yet support the “refer” option specified above.
I wanna be able to specify a forked core package version in my .meteor/packages file!!
And of course that will go a long way–if not all the way–to achieve @aadams big picture aim in forking all of meteor. This basically means the only things that can’t be switched out are the build system. And the closer we come to being like NPM, that won’t be a problem either.
It is not for fork to fork. The reason of fork is to focus on fundamental difference. There are fundamental different interests between Blaze and React groups from vision to principles at present. There are even more conflict interests such as dissolve Meteor packages to adapt NPM modules as well as SQL database or not. In one word one group prefer to have a tight unified Meteor but another want to have a dissolved component based Meteor.
Each group should be encourage to develop its own sub-ecosystem instead of force one group convert to other. That may let one group to leave Meteor at all. So from beginning Meteor should provide two sub ecosystems for selection. Developers can make their own selection. And both pathes are safe and long time guarantee.
Look at how Apple deal with migration from Objective-C to Swift. Apple said they will continue to support Objective-C for 20 years officially. In contrast Microsoft forced developers onto Windows 8.1 new generation programming and intentionally depreciated Windows 7.
What is the result? Apple’s App Store boom but Microsoft’s Windows Store doom. Any developers are interested in developing Windows Software?
I think for some the first objective is to see the Meteor Development Community, if one is so inclined, encourage MDG to preserve and then promote Blaze and Tracker to first class citizen status. At least to the extent React is being integrated into and promoted by MDG.
Just as React is not developed by MDG, only the integration points, Blaze too should be fully open-sourced and community driven, and MDG should only manage the integration points if necessary (even this could eventually be taken on at some point). And Tracker likewise.
Since Meteor at its core is moving to a more NPM modular-model, I think it’s in the Blaze and Tracker projects best long-term interests to embrace this model. If this means Blaze and Tracker as separate NPM projects, so be it. As long as the experience is similar to what we have today and there’s a clear upgrade path for those inclined to continue using a tempting system for the View Layer.
Also, I’m not suggesting this will be an utopia where Blaze + Tracker will transform into super projects and surpass React + Data-pipeline (would be nice). But with some, I think, modest enhancements and bug fixes to an open-sourced community-driven properly modularized and Meteor-integrated Blaze + Tracker project(s), template-developers could see big productivity and performance wins.
Also, @arunoda
MDG will likely go into your space soon. Which makes sense as they want a complete platform. Things are about to shake
zig-zag… going back and forwards, and from left to right… no course plotted
You can’t have it both ways. Either you’re interested in keeping up to date with the absolute newest tech and prototypes, and there is constantly going to be debate about different ideas, or you want something that is totally stable, in which case you should just read the meteor guide and ignore everything else.
[quote=“sashko, post:93, topic:15932”]
totally stable
[/quote] Would be great, but… Meteor Guide writes extensively about Blaze, which MDG first implicitly declared obsolete and since yesterday, is trying to reduce that impact. We welcome that. But, the answer was a bit half-half so we have to see how things materialize. Let’s face it, after a great 2014 & 2015, during the last two months of 2015 we are a bit in the mud, and we are not out yet.
We for one do not want the latest greatest, I wonder who does? We like things to work good, stable and fast. We like to be able to ask questions in a non-fragmented community.
Perfectly aligned with your view. I love Meteor but I’m worried about how the platform will be structured in a year from now.
And BTW, will it still be a platform or it will be mutating to a framework? I loved the platform idea as @debergalis discussed some months ago at Stanford. It would be interesting to have his point of view on this topic.
Decomposing Meteor to make it more opened to the rest of the Javascript community worries me a lot if it means abandoning the Meter consistent platform approach.
In the mean time I’m going to keep using what is perfectly integrated and available, like Blaze.
Is React a better solution?
I don’t know actually, but redesigning my application would cost me months of work and the result would be probably suboptimal compared to what Meteor-React integration will provide off the shelf in a year from now.
Can you elaborate that a bit more on this?
Why do you think that “monetizing aggressively in the enterprise” is a bad strategy for an open source platform?
Thanks for this post. It’s always useful having your point of view about Meteor and MDG.
Exact the reason why we love Meteor. An opinionated full stack approach with strong coherent ecosystem.
Question / Concern #1: Meteor Guide, Alternate Stacks, and MDG’s maintenance of parts of the current Meteor stack.
Yes. We sell commercial support of the current stack to companies that have built their businesses on it. It’s not going away.
We’re going to continue improving support for other view layers (Angular and React) until they’re at parity with Blaze, including the Guide. In the longer term, we expect that most of the usage will gradually shift from Blaze to Angular and React. How long MDG maintains Blaze will depend on how much usage Blaze continues to get in the community, especially among our business customers.
Question #2: Will there be some kind of relational database support directly by MDG soon? I ask this both open ended and specifically regarding the existing stack–reactivity, accounts package, etc.
Absolutely, this is a major priority and we now have multiple people working full time on it. When they have something that’s enough to get early feedback, they’ll share it here. Yes, it has to be full support including the accounts package.
Question #3: How will Atmosphere (also recommended by the Meteor Guide) play along with NPM packages?
Meteor 1.3, which you can try out (and give feedback on) in prerelease today, includes massively improved support for npm as part of the ES2015 modules support.
In the long run, I think we should transition fully to npm. Whatever strengths that the Meteor package system has, we should work with the npm community to bring to npm. This is a big project and is not going to happen overnight. The improved npm support in Meteor 1.3 is a good next step. A later step will be to release the Meteor core packages themselves in npm.
Ben, thanks for this. I care very, very much about the job candidate experience at MDG and I will discuss your posts with our recruiting team.
I hear you on the need for more evangelism (I like the word “advocacy”) bandwidth.
Can you elaborate that a bit more on this? Why do you think that “monetizing aggressively in the enterprise” is a bad strategy for an open source platform?
Meteor needs to be a genuine open source platform with broad support. Some investors who don’t know how this works would be tempted to (try to) cripple the open source product to get a short term boost in sales. For example, trying to put key Meteor features in a closed source “enterprise fork”, or telling MDG engineers not to post on the forum so as to not “give away free support” that could reduce demand for Developer Subscription. This is not the right path for an open source platform. The best outcome is ubiquity both inside and outside the enterprise and this requires longer term thinking.
Meteor is going to blowup after this happens. Or what Trump would say: “It will be HUUUUUGE!”
P.S. Don’t vote for trump.
The gap between Blaze and React is bigger than people think. HTML/CSS files are separated [quote=“gschmidt, post:98, topic:15932”]
In the long run, I think we should transition fully to npm. Whatever strengths that the Meteor package system has, we should work with the npm community to bring to npm.
[/quote]
Then how do you maintain the consistence of Meteor packages without Meteor package system?
Autonomous? So does that enable us to use custom loaders/bundlers, such as webpack? That would sound like a dream come true, solving so many dependency issues (i.e. node v5).
ETA this year?
When it comes to Blaze vs React (here we go again), the JS / HTML / CSS is the smallest difference. You can still use normal css in a separate file and with the “new” UI component strategy (which mostly just consists of the JSX part: a.k.a. a HTML template language) there is separation of concerns, just like Blaze. If it’s possible to build BlazeReact on top of React, that should say something about the similarities. Real differences are not being able to manipulate the DOM with things like jQuery, because of the virtual DOM.
I’m just as happy using Blaze (which we use for our production app, serving many users) as using React (for other parts of the system).
Why does it matter if a package is on NPM or Atmosphere? The code can be exactly the same. There are also React and Angular packages (to name 2 random frameworks) all over NPM and they seem to do just fine.
npm install blaze-thingy - vs - meteor add blaze-thingy: Both fine by me 
I do hope so 
This falls inline with how @faceyspacey envisions things. I would love to see that come to fruition myself. I think moving meteor away for being some monolithic walled-in-garden is the way to go. I Imagine being able to to build an app that uses Meteor, not just a Meteor app. I think it’d be great to see somewhat of a divergence between Meteor as a Platform, and Meteor as a Framework.
I understand and agree with you.
Nevertheless, as you mentioned, the enterprise market is definitely a target market for Meteor as a software platform to make application building less painful. The enterprise is continuously looking at new ways to make its own software development standardized and faster to be built. They love open source platforms –more than frameworks – because they are “opinionated” and very often bring a method with the software itself. Meteor is pretty close to this concept and it’s probably the very first platform the can be widely adopted by the enterprise in years. It’s pretty simple to start working with it and it’s based on Javascript – which they already reply in production.
IMHO the main threats which can mine open source adoption in the enterprise are:
The enterprise market is also very important for many of us, because is where our customers are.
In my understanding 2016 will be a year off big changes for Meteor with the aim to get closer both to the Node community and to the emerging front end de facto standard frameworks – like React.
I think that it would be very useful for us as a community, that you could share with us where we are going to be by the end of the year.