10 Likes
Well I was going to say something sassy, but your analogy is quite a bit better!
Meteor is gracious enough to give you everything for free. Yes it is your âpowerâ to quit, but you quitting or not will not power the lights at Meteor HQ. It has absolutely zero effect on their bottom line.
Tapping into the enterprise intranet market with SQL will.
Tapping into the legion of React and Angular developers looking for an integrated backend will.
You cannot grow a business, by intentionally not growing it.
I disagree that itâs worthless. They are reading this. And when they form their opinions they will respond. In essence, they are learning from us, which is why there is plenty of âworthâ to writing this even if they havenât provided an official response yet.
MDG isnât some all-knowing coding god. They are like us: BUSY WITH CURRENT PROJECTS. Which means itâs impossible for anyone to keep up with everything happening in the javascript/technology world. So itâs crucial that we inform them with novel and helpful perspectives. Believe it or not, itâs very easy to essentially become a entombed in your own castle. So we gotta show em the light from the outside world. The light happens to be dark and shadowy, foreboding of a future where Meteor is dethroned as the best full stack javascript solutionâthat is, if MDG doesnât see the full picture of whatâs going on with the âFacebook React Stackâ gradually encroaching upon and soon crushing its business.
12 Likes
Your argument is inconsistent with itself. Meteor is not getting money neither from people using Blaze, or SQL, or React. But by providing Galaxy. So the question is not which technology is better or which technology will get more people to use Meteor, but what will get more people to use Galaxy. It is true that more people will use Meteor probably more people will use Galaxy, but there are also other things which will get Galaxy users: and this is overall code stability and support. If operations people (who are those who will use Galaxy) see Meteorâs track record as somebody who abandons parts of their codebase they will not really be happy and might not give their blessing for using the stack. You want both LTS and Galaxy for them to make it happy. Then they will say, wow, great stack, they are stable, and they provide us with Galaxy to keep it running. We support it.
And this is what this thread is about.
6 Likes
Thereâs a whole list of those things (not a physical list, but a theoretical one). Stability is just one of them.
1 Like
I can easily imagine React and Angular devs not being eager to go for Galaxy so theyâre not stuck with Meteor in the longer run, when they may decide to switch the backend. Even if Galaxy wonât be directly tied up to Meteor only, its connection with Meteor will make people treat it this way.
1 Like
Companies like meteor historically do not make money off the product, but by providing training and technical support contracts through partners. IBM, Microsoft, RedHat or the smallest software concern, itâs no different.
IBM sells you an AS/400 for $100k to $750k. They make their real money on that $15k a month support contractâŚ
Gee, look at whatâs coming in 2016⌠Galaxy is just one piece of the monetization puzzle.
That only is going to work, if they tap into the literally untold thousands of an untapped market for a cohesive application platform that comes from React/Angular devs looking for a backend.
Sorry, but Suszyâs online recipe book and itâs 15 users isnât going to keep the lights on, let alone repay the VC injection.
2 Likes
In that I suspect we just have a different opinion. I think lack of communications is a very important indicator for issues later. I donât care about the choice they make I care about the communications.
2 Likes
Sorry but I see MDG as much more capable than being entombed in their own castle. I think we should not underestimate the team.
3 Likes
I totally agree with @mitarâs opinion. Meteor convinced me because it was heavily oppinionated and provided a one-stop solution instead of the typical Node / MEAN stack puzzle. Now, this opinionated perspective is dissolved more and more, which already caused a lot of friction in the community. Yes, having options âon topâ of the core is nice, but the core itself should be ârock-stableâ and âtrustworthyâ. And there should be a clear commitment about what belongs to this core and what not. If one of these core components really have to be replaced by a new go-forward solution, there should be a clear communications strategy, including migration plans, time-lines etc. A kind of âhidden soft fade-outâ is not a good solution.
10 Likes
well, at the end of the day too, or I wouldnât waste my breath. I think they are capable of making the hard decisions (and seeing them). they still need to hear it from us though. itâs also a matter of degreeâthey may not take this all the way in the direction it needs to go unless they hear exactly how important it is from us. I highly doubt right now MDG is ready to double down on Blaze and take it to the âBlaze Nativeâ level necessary to compete with React, and if they choose to go the other way, I hardly doubt they are ready to make a big bet on âThe React Stack,â replacing all their stuff with GraphQL, eventually doing the same down the stack.
Judging by the fact that so little has been done to Blaze lately, itâs obvious they have been hoping to sweep it under the rug, close their eyes and pray, etc. Am I the only one that saw David Greenspanâs components for Blaze video 2 years ago before Blaze even came out, and am wandering why it was never finished/released??
Clearly the reason they havenât invested much in Blaze is because they saw that it might be a waste of time time given the rise of React. What that means is they havenât made the decision to âdouble downâ on Blaze and take it to the level of âBlaze Reactâ (fixing performance and adding Components along the way).
So, see what Iâm saying, we canât just trust MDG to make the right decision without hearing from us. And they donât expect to either. The right decision should in large part be based on our vocal opinions. They may very well need to hear from it us to know exactly how important it is.
4 Likes
Itâs not just React.
Meteor folks were at a recent Angular conference, introduced by the keynote speaker. The Angular folks are working directly with MDG, so when Angular 2.0 finally is finished Meteor will be a âgo toâ backend product on all fronts.
One backend to rule them all. Very smart move indeed.
3 Likes
Well, I have considered doing the switch to React now, as my app is still small enough to do it. Yet, what has stopped me from doing that, was all the posts I read about things that are (not yet) working with React. IIRC, even the UserAccounts do not really work with React. I cannot speak for others, but I prefer bringing my app forward fast instead of switching to the âbleeding edgeâ too early and struggling around with a (not yet) mature ecosystem. I have no problems with âfirst-moversâ like you doing this, but I want to focus on business value first.
7 Likes
Most of what you see are merely growing pains as people are new to React and trying to figure out best practises with Meteor. To flux or not to flux, etc.
Thereâs you a nice video tutorial on how to create a custom login system with React. You can also use the stock Accounts UI package, by wrapping Blaze in your component. Or, there are a number of total re-writes of the Meteor account system as React components in progress.
There are currently a few dozen Meteor/React boilerplates available on github.
That is currently my favorite, as some of the others appear more to be Webpack boilerplates than React boilerplates and I donât need the added complexity to learn React.
However, none of them would be very useful if they didnât let you log in. 
As far as âbleeding edgeâ, well React has been around since 2013. Angular iirc, 2009.
2 Likes
There isnât really such a thing as a main branch in Node, the non-meteor javascript ecosystem is a big mess. Related: http://nolanlawson.com/2015/10/19/the-struggles-of-publishing-a-javascript-library/
A year to address all of the problems and put them far beyond competition.
Maybe make it a week and let them also build a teleportation device, nobody has that yet.
I also fail to see what giving up on Blaze has to do with GraphQL and Relay.
4 Likes
I will just put this here https://www.jwz.org/doc/worse-is-better.html
TLDR: The #1 thing that matters the most to any software(especially open source) is having a huge community.
Doesnât matter how simple and easy to use meteor is, but if you can count with one hand(arunoda) how many people are making contributions to this platform then it will go no where.
1 Like
Iâm not an experienced developer at all. So, maybe my opinion has little value, but this topic is important to me so here it is anyway. First, I agree with @mitar. Second, hereâs what MDG has on the Blaze page: âWe built it (Blaze) because we thought that other libraries made user interface programming unnecessarily difficult and confusing.â. I couldnât agree more. After one tutorial, I was sold. Simple html templates, straightforward JavaScript. Iâd tried to learn Angular before, but it seemed like such a hack compared to Blaze. I tried React too. Couldnât stand how you have to use attributes like className. These sorts of abstractions to describe attributes that already exist just feel wrong. Another thing you have to memorize. Sigh. As a noob, I say to myself, great! any day now somebody will come up with a front-end framework to handle React! Weâll use nameOfTheClassName and handle the shadow of the shadow DOM. 
So my point is, I hope MDG continues to fully support and move Blaze forward, even if the technology behind React is better. Why? Because there will always be something better out there. Next year is Angular 2, who knows. And Meteor can choose to chase the next big thing or have a strong opinion about certain aspects of the stack. I think the front end is an important one to keep close to home. Facebook is on the ad business. Google is on the ad business. Meteor is on the revolution business. By not doing much to Blaze, youâd be essentially delegating an important part of the stack to companies with different agendas. So I hope that MDG can clarify what they intend for the future of Blaze. If they say go full speed React, Iâll follow. I just hope that they make that decision based on principle and not on pressure. It would be a shame, not for me, who get to use this awesome framework for free nevertheless 
, but for the team that dreamed up what Meteor should become, those early days at Y Combinator.
20 Likes
it was a very smart move, and well played, but my hunch is they think thatâs all they gotta do. I keep saying âReactâ because Facebook keeps moving their technologies down the stack, whereas thatâs not happening with Angular. They should follow Facebook down the rabbit hole if they want to complete that thought. Otherwise, it will end up just being mediocre as the Facebook Stack progresses. MDG needs to know they gotta take this extremely seriously. Ideally they follow facebook down the rabbit hole AND double down on Blaze, taking it all the way to Blaze Native. Iâm just saying you canât do any half-assed stuff in between.
If we only had the resources for one, me personally, if I had to choose, Iâd choose doubling down on Blaze, taking it through components, fixing performance, all the way to Blaze Native, and take on React head to head.
But, if even that requires more resources than they have, iâd pick the Facebook option over just hoping the interoperability they just gave us is enough.
They need to be extreme, super opinionated, and build solutions to the maximum. Meteor could easily ârest on their laurelsâ (so to speak) and just kinda work interchangeably with everything, but not kick-ass like it used to. There was a time where it was head of the pack in terms of Reactivity. Reactivity has always been the #1 selling point of Meteor, above isomorphic bundling. Thatâs my perspective at least. So they hoped the industry wouldnât have progressed so quickly that they could move other things up the priority chain. I could be wrong, but that just seems like the psychology any shrewd developer would have in their shoes. Anyway, that didnât end up being the case; so if they wanna maintain their Reactivity Crown (which is their best piece of marketing, their core value proposition), they gotta refocus on reactivity and get ahead of the pack again.
Letting others fill in the blanks (i.e. React) isnât good enough because there is a limit. By âlimit,â I mean it will soon not be able to keep up with the competition as slick integrations are made down the stack. React + Relay + GraphQL will be better than anything Meteor can do with plain old React soon enough. And thatâs my main hypothesis here. It was uper duper smart to interconnect with React and Angular right now. But the timing probably should have been a while ago. And the timing will just get worse as it gets harder to interconnect as Facebook moves down the stack. How are they supposed to see how important GraphQL will be? See, nobody knows yetâthatâs the point. It may not be, and Facebook may never move much farther down the stack, and Meteor could rain supreme as the king of full stack development tools for a long time without many challengers. So what Iâm saying is rather than leave it up to fate and luck, Facebook preemptively pioneers the Facebook stack, implementing GraphQL before anyone else, as well as anything else they see down the stack, or at least be poised to do so.
3 Likes
Actually, what I get from that page is that simplicity is the single most important aspect in software. And that this simplicity will result in a larger community.
If you look at github and atmosphere, there are a lot more people than just Arunoda, heâs just doing exceptionally much.
Thereâs also a big difference between company backed open source projects and open source projects with no company involved. In open source projects backed by a company people are usually like: âIâm not contributing, thereâs a company making money of it, so they should solve my problems.â. Meteor seems to have a healthy ratio of users who contribute vs users who donât contribute compared to other projects I follow.
1 Like