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.
14 Likes
[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.
1 Like
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.
2 Likes
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.
30 Likes
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.
3 Likes
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.
21 Likes
Meteor is going to blowup after this happens. Or what Trump would say: “It will be HUUUUUGE!”
P.S. Don’t vote for trump.
6 Likes
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?
2 Likes
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 
1 Like
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.
3 Likes
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:
- Frequent changes in the platform foundation modules or in the method to build applications itself
- No assurance to keep legacy applications compatible during platform evolution.
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.
3 Likes
I agree, but I’d love to be able to choose. Sometimes the “monolithic” approach is the way to go.
Is Meteor going to be a platform or become soon just a framework?
This is a very good question and I think that a clear vision shared with us by MDG CTO will be very appreciated – as I suggested in a previous comment:
It is simple NPM includes packages that will not work with Meteor. A Meteor package may contain many hint packages inside. Meteor system needs to resolve conflicts among packages. By using meteor add you give developer a certified package that will work on Meteor.
@debergalis When I got a reply from MDG, I was told that I needed at least 6 years of experience (I have more) with a reputable company?
I see your point. Although meteor add doesn’t necessary give you a working package (other view layer, other meteor version, other database). But agreed, it does give a better guarantee then just NPM, at a cost of less packages and packages being out of date compared to their NPM equivalent.
The point is that NPM will give you many packages that WILL work. That is for me way more important than packages that won’t work. If we keep to a standard, like a meteor- prefix, we can still find them. Just like gulp- or react- prefixes.
I’ve been a node developer for years and can’t wait to have all the great node tools and packages available in meteor. All the wrapper packages for things like moment are no longer required.
2 Likes
Instead of meteor-prefix I prefer to meteor add npm:package and you can use npm install -g for utility tools in meteor.
1 Like
can we not have something like this ? http://react-components.com/ but catered for meteor ? But that will be like atmosphere again right ? Maybe a prefix will solve it. After all the goal is to take advantage of NPM’s current repo right ?
3 Likes