While reading long threads Is Meteor Dying?, Phoenix as alternative to Meteor and all kind of discussion about Blaze2 and Webpack vs Meteor1.3 imports and similar I come up with feeling, that while working on Galaxy MDG lost focus on Meteor and now is trying catching up.
Wouldn’t be good for MDG business (Galaxy) to start running as well other real time apps? ( e.g. Phoenix + React, Go (with channels + React etc.) But if they would decide to move to that direction, it would move their focus even more out of Meteor. From other side bigger engagement from community is really welcome but is not as big as it could be because many people just waiting for input from MDG.
I think that earlier or later MDG will need to establish some king of Meteor fundation which will be community driven organization for Meteor development (with a few paid people from MDG and that time maybe a few paid people from some other corp.) and will concentrate more on their business (Galaxy - hosting, consulting, performance monitoring tools etc.)
I think they might have chose to use more of their resources on a long term play (Galaxy) and then got caught in a very fast moving period (2015). In the last year there hasn’t been much improvement in core (Windows support being a notable feature) but they realize that and are playing catch up.
The bright side is that having hindsight can be an advantage… they can look at what is popular and sidestep around all the problems with modules and webpack. Imagine if they chose AMD in 2012-13… whoops (that’s what I chose/used then).
Wouldn’t be good for MDG business (Galaxy) to start running as well other real time apps? ( e.g. Phoenix + React, Go (with channels + React etc.) But if they would decide to move to that direction, it would move their focus even more out of Meteor.
I think hyper focusing on one thing is key to winning in business. Even more so when it’s competitive. If they split anything it would make both mediocre. Better to have a smaller marketshare that does it exceptionally well than a large one that does it just ok (cough cough… Heroku).
I think it’s unfortunate that a lot of those drastic titles get the clicks and click count may seem like a lot of people agree with the title… I doubt that all of the Meteor user base is up in arms. Kind of like Amazon reviews… those are typically pissed or enthusiastic customers with the middle not leaving as many reviews.
A community driven Meteor is interesting but it would likely start looking like Express, Koa, Hapi, or Meatier
Instead they were wise to choose Atmosphere… whoops…
Thats why they choose to focus on Blaze, Tracker, Publications, and not wander without a direction between blaze, react, angular, graphql… whoops again
That’s a really good point. Being on the cutting edge certainly is a double-edged sword. (what punny metaphors) But I definitely want to shave down the lag behind the most current practices. [quote=“SkinnyGeek1010, post:2, topic:15430”]
then got caught in a very fast moving period (2015)
[/quote]
no kidding. JS is the most rapidly mutating thing I’ve ever seen. It tops nearly all the charts for activity on github and thats not event a good metric of how the language is changing.
Now that MDG has Galaxy out there… Well, that’s pretty much their only revenue stream afaik. Like it or not, as a corporation MDG can’t exist without turning a profit. Galaxy was a big investment in man-hours, and will continue to be, but I suspect there’s no longer that we-had-to-get-this-out-yesterday sense of urgency to ensure the business’s viability. So, in pushing so hard for Galaxy MDG has let Meteor has kind of fallen by the wayside. MDG doesn’t get paid directly for advancing Meteor as platform. Their success is dependant on Galaxy’s usage, which is in turn depends on the web’s/business community’s perception of meteor’s worthiness for adoption. That concept might seem superfluous/silly, but it is a profound distinction.
What’s best for MDG isn’t always whats best for Meteor.
That’s just the way it is.
I can’t be upset with MDG for their course of actions; they made the right/necessary calls to keep themselves, a new startup, afloat. Meteor wouldn’t be what it is without them driving the effort. On the other hand MDG, can’t afford to sit by and milk Meteor as it stands now. Meteor has been established, now Galaxy is established as well; their two critical objectives have been met. It’s time for meteor to start moving forward with core now that it’s once again—at least half of—their top priority.
The just really sucks for them because JS is advancing so gawd damn fast. Now they’ve got to play catch-up. Mind you, ecmascript/ES6 only just became officially supported in like less than 3 months months ago.
Meteor has a super huge investment to build the web framework of the future. I’m not sure the investors were interested in Galaxy Hosting as it’s money maker.
Meteor is the big picture. Galaxy is a way to make some recurring revenue, and also ease Meteor deployments. But it comes second to Meteor.
I don’t agree with having them separated. Meteor should be #1 priority, with Galaxy coming in as a far second. If any other tool did something similar to what you’re suggesting it would be incredibly odd and off putting, wouldn’t it?
Yea I agree. However, one thing to note, they started out as internal packages and the community made Atmosphere which started the problem of wrapping github/npm libs.
Also worth noting in 2012 meteor add bootstrap was nice because it was common to use script tags. 2013 brought Bower because NPM 2 dropped the ball on browser packages which NPM3 has fixed.
Still, I agree, not ideal It seems like NPM support will help us going forward. Hopefully Atmosphere will turn into something like React Parts which aggregates modules on NPM for you.
There’s still a lot to of stuff to do to catch up to do where vocal members of the community, and I would like meteor to be. but with what I’ve seen so far, I think they’re doing a pretty good job.
The meteor guide is a good start. But some things need to be carved out and/or modernized; there needs to be even more huge overhauls; (cough couch node LTS couch bundling cough) My only real criticisms of MDG are:
they are too reticent to make sweeping changes. (this is easy for me to say because I’m not the one at the responsible, don’t have anything that legacy apps to maintain) But the longer they wait, the further behind they, we(the community) get. Now that Galaxy is a thing. I think they need to wake up and smell the (*bacon emoji support must be added). All the negative posts covering this forum—side note: much respect for keeping it transparent/not suppressing things making negative results come up in google from their own website—will really affect people who are indeterminate choosing a which platform to adopt/invest in ⇨ decline in Galaxy revenue ⇨ MDG sinks ⇨ meteor drowns
They’re not bold enough to take a chance and attempt to future-proof their architectural choices. (ie: doing custom implementation of es6 modules instead of a pre-established loader say… SystemJS—this is a grievance I’ve argued before, the current approach is less than Ideal imho, reinventing the wheel… but at this point, it’s best to keep going along the current tract) meteor’s certainly gotten burned before with atmosphere/blaze, but you’re not likely to win by not taking chances.
MDG is getting much better at this, ala Meteor Guide, but I think MDG should deliberately, explicitly get the community involved in planning the road map. My suggestion:
a. break down design choices/into specific chunks that need to be addressed, design questions we need an answer to e.g. Blaze, Modules, Bundling/Lazy Loading, data(what do we do about tracker, mergebox, etc? adopt GraphQL? ditch hard dependency on mongo? AnyDB? {two dozen other suggestions}?
b. have community vote on solution, this does not have to be 100% democratic, but I think more people considering a problem results in a better solution.IMO the most important part is having a explicit structure presentation of approaches, have OP's main post/whathaveyou summarize proposals, have literal poll widget (maybe reddit style rankings)
c. have community vote on priority. Do we get on LTS before we address GraphQL? Can we all agree that Blaze2 should come after we figure out `{INSERT HURDLE}`? Let's rank them. collaborate on a road map
MDG doesn’t need to be it’s own seperate thing from the Galaxy Team, but I think the architecture solutions/roadmap should be much more collaborative.
all trying to do much of the samething. this is getting spread way too thin. Guide should be it’s own thing for documenting working bits of code/design patterns that have a consensus. If MDG really want’s to get the community’s input, ultimately their customer’s desires, it needs to be right out there. all formatted and organized preferably in a “tree” type thing where solutions get discussed, then we can talk all we want about different solutions but if its spread across 50 different threads/issues/posts/tasks.cards/whatever then the meteor community is doing itself a disservice. If I took all the things ive seen concerning es6 modules in meteor and struture them my god I would have been able to give the same input in 2hrs that it takes me 2weeks of snooping arround between disparate sources.
@sashko I’m interested to hear your input/MDGs stance on the subject. imo MDG has in no way been “bad” at community involvement, but I think that its can be improved dramatically. Posts here about specific topics are great we get to share some ideas, but we’re not exactly drawing blueprints.
It seems like NPM support will help us going forward. Hopefully Atmosphere will turn into something like 
(*bacon emoji support must be added). All the negative posts covering this forum—side note: much respect for keeping it transparent/not suppressing things making negative results come up in google from their own website—will really affect people who are indeterminate choosing a which platform to adopt/invest in ⇨ decline in Galaxy revenue ⇨ MDG sinks ⇨ meteor drowns 