Yeah I guess I just feel like there is an option not to care - in my universe, the primitives of React are props, state, and render() - everything else I don’t really care about. But I guess it’s fun to invent new ways of doing stuff, which is great because sometimes you stumble onto something really special.
4 Likes
but if you did continue to care, meteor developer @ccorcos’ Elmish is a great concept:
I’m still undecided as to what’s better: Elm or Cycle. Elm doesn’t beat you over the head with observables the way cycle does. Therefore, a true Elm clone in JS could be a fantastic option, perhaps something right up Meteor’s alley. It might also be something that can render to React. That said, Cycle might be that “something really special” you’re talking about. I mean it’s really ridiculous (in a good way) what the guys is doing there. Here’s a conversation I started on Reddit about Cycle vs Elm vs React where Andre Staltz came in and did a really good job breaking it all down:
In short, Cycle is even more fractal-like than Elm and has first class support for the “observable primitive” as I’m calling it (i.e. higher order observables), and seems to intercept user input at the perfect place, i.e. doesn’t resolve to any “hacks” regarding attaching callbacks in rendered elements. Minus the language (javascript), Cycle is as pure and fractal-like as it comes. Fractal-like == smallest API surface area necessary to learn.
I hope/bet React takes a turn toward playing the role of the underlying renderer. That way they don’t make you choose between Cycle and React and whatever competitors eventually emerge. Like, it would be cool if Facebook accepted this and built even lower level primitives to make it so all these frameworks can easily interface with React Native.
1 Like
I’m not sure about react being the standard. At least in Europe, if large enterprises decide to do a web app today, 9 out of 10 they choose for angular. React is still too new for them (as in: they haven’t even heard of it). These are the kind of companies that do not easily switch technologies and Angular 2 will therefore be their next choice (even though it is quite different, it’s a name they know and trust). I think the beta of Angular 2 came just in the right time (probably why it was a bit rushed) to ensure companies stick with Angular.
I’m not saying Angular is the best framework (it isn’t), but Angular 2 is very good and if Meteor wants to attract enterprise-grade customers, angular support is important.
2 Likes
I agree on what you’re saying. There are plenty of enterprise customers and developers just like me that feel that this whole web thing is a real mess as a new technology is delivered on a nearly daily basis and what’s the de-facto standard today won’t be the same in a couple of months.
Things are moving way too fast and technologies aren’t settling as stable before they become obsolete.
I’m one of those that likes to see a full-stack framework that is stable and that takes the best of other worlds and integrates it into its own components without breaking everything every now and then. IMHO Blaze should be the #1 choice and eventually other view engines could be used but that shouldn’t be the proposed best practice.
At least for me, it did 
Actually, it was a great idea from Sacha to leave a “cliff-hanger” in part 1, so I was even more eager to read the “positive” side of the story, too. Don’t worry. @Sacha: Thanks for sharing your thoughts on the current status, highly appreciated from my side.
2 Likes
I never used React but willing to try if it comes out in the next version with supported documentation. For my current project I will have to strict with Blaze as I have already started.
Been away from Meteor for a while and sad to see it in a wobble.
I sat down today to start on a site (landing page, email capture, payment integration, blog mb), linking to a back end contact db/utterly basic crm i’ll have to bash out (with +30k+ records if anyone has any advice for Mongo). Yes - i like a hard life, when i cd just sub to a provider…
- My point being that as a solo/micropreneur - an definitely not a pro, although im not code shy - I would never have considered taking on and finishing such a project in a short time frame…Really - having the chance to build out an idea and market test so rapidly: its a dream come true…
Today made me realise how much I love ‘meteor add’ (I am not a developer btw, so please be gentle!)…But also, how we have been spoiled for anything else 
(My thanks go out to those brilliant package developers without who I could never have enjoyed web dev so much)
So Meteor future? Please make it as good as Meteor past I always thought its unavoidable technical future was to become like Socketstream and commercially to become the Tomcat of real-time JS web. I think theyre brilliant enough to avoid both traps Change is the only assured thing though - and I can see that React is a game changer for dev teams. I quite like it myself, with the caveat that I am philosophically for the open web (as a goal, not a constraint!)
If Meteor can eliminate the cognitive load of React/GraphQL/Redux/Relay for me like they did with Node, express, sockets, mongo - then they’ll have no competition afaiac and might well become a no-brainer for start-ups, agencies, intrapreneurs. … so colour me happy with the lower heaven of Meteor, rather than the higher hell of anything else
6 Likes
I just recently wrote about that very thing - https://thoughts.spacedojo.com/why-meteor-development-group-needs-react-facebook-ee340ed842a4#.7xrrcsu7a
2 Likes
Personally, I think the wording of the headings tends towards the overly negative.
For example, what is a “failed experiment”? I think the whole goal of an experiment is to prove or disprove a hypothesis, and in this case the experiment was a success because it helped clarify that the livequery approach won’t work as well with Postgres. Which is, in my mind, not a failure since it was the whole goal of the project. Also, IMO the standalone Blaze thing didn’t work out because we never promoted and maintained it, not because people weren’t interested in using Blaze outside of Meteor.
I definitely agree with the conclusions, and that’s aligned with what we have been trying to say - that it makes sense to get on board with great communities and stable and useful new technology.
I just wish the phrasing of these posts was more positive, rather than having the tone “Meteor is failing, let’s desperately try to save it by outsourcing everything to Facebook.” For example, “Meteor is good for some applications today, but it could be even better if it integrated some of these great new technologies that a lot of people are excited about”.
7 Likes
Yes! You’ve expressed my vague, unformed thoughts on this perfectly.
1 Like
I posted a part 3 to wrap things up: https://www.discovermeteor.com/blog/the-state-of-meteor-part-3-aftermath/
Last one I promise
2 Likes
But that is just it, open source is never a ‘Build it and they will come’, it takes effort and marketing to attract people and get them to use the platform. That google group had people wanting questions answered…
The reason I think it is a failed experiment is because the learning part was never shared. A direction was never given from MDG. SQL support is easily the top question I get from people on the Meteor Club mailing list every day. People have been waiting a long time for it as it has been prominent fixture on the roadmap… Your response is the first I’ve heard of a conclusion and I pay attention to a lot of Meteor news
I didn’t have any tone about Meteor failing, was just pointing out some community frustrations and how I think Facebook has important solutions to it. Simple math tells me a profitable hosting company needs to outsource work that no other hosting has taken on… Investors want a return, if they didn’t we would see MDG setup as a non-profit .
1 Like
So you think Meteor should close the door, make the React people and the ‘fourth segment’ happy; alienate people who love Blaze or Angular?
Instead of keeping 4 doors (Blaze, React, Angular, i-dont-care) open?
There are more React people (outside the Meteor community) right now because React is the new shiny thing. This ‘jumping to new things’ is a reality of our industry and everybody knows that nothing stays new. Soon people will start complaining that React has no separation of concerns (when writing code), that it is ugly to write HTML in your JS, that it makes life painful for web designers, … and then a new technology will emerge and React will start losing popularity. Or maybe Angular will eventually gain more traction and become more popular.
We (you) can argue that React is better than Blaze; but you would be dead wrong. No technology is better than the other. Each and every technology/solution does and will have its pros and cons. Blaze has it pros and cons. So does React. It’s a matter of choice.
Let’s replace Blaze with OSX and React with Windows (or vice versa, doesn’t matter really). If you are writing a desktop application and want as big a userbase as possible, your app must run on both OSX and Windows. You can’t say ‘I will only code for OSX’ (again, if you want as big a userbase as possible).
IMHO, if Meteor wants to be a go-to solution for developers, it has to support Blaze, React and Angular. And if some other technology emerges and becomes popular enough (although the ‘enough’ part is subjective) Meteor has to support that too. You can abandon a technology only if its popularity is not ‘enough’ anymore (yet again, if you want to be an all-encompassing).
I understand your point of view. You think React is so very popular, and that if MDG stopped trying to support every technology out there and instead focused on one, things would progress faster.
The problem is that you are seeing React like a de-facto standard. Sorry, but it’s not. It is very popular, yes; but it’s not the single most popular way of doing things. Even if that were the case, it is not a logical reason to let the others go.
Think PHP. Anybody experienced in PHP (with some other languages thrown in the mix) will tell you that it is ugly and way behind in some areas. That doesn’t change the fact that PHP is one of the predominant ways of doing things. (You can replace PHP with C#, wouldn’t matter.) Yet although PHP is much more popular and dominant (sector-wise), we are not only looking for alternatives, but also testing them and switching over if we can.
Blaze is one of the main reasons some of us switched over to Meteor. It provides a way to do things simply, easily and beautifully. I don’t care what technology outside Meteor is popular. Blaze is a beautiful and elegant technology with a very low learning curve (mind you, low learning curve does not mean useless in advanced situations).
If Meteor decided to stop supporting Blaze, and forced me into using React or Angular (or something else) that would be the day I stopped using Meteor. I would be sad, but I would leave. Something tells me there are people that think like me, loving the simplicity of doing things the Meteor way (easy yet powerful).
We did not abandon IronRouter entirely when FlowRouter came along. It’s the same (for me) with React and Blaze. Having a new friend does not (should not) mean abandoning the others.
I propose a different solution than yours. I propose we support them all, but not expect everything from MDG.
From where I’m starting, MDG can’t keep up with the community (which is normal), and it needs to create separate repositories / developer groups / anything else for each technology that Meteor uses, needs or supports. One group for Blaze, one for React, one for Angular, a subgroup for Blaze-IronRouter, another subgroup for Blaze-FlowRouter, … These groups do not have to work for MDG. They have to work for Meteor.
My two cents.
7 Likes
That’s not what your blog posts says. Your opening sentence says Meteor is in a state of flux. And the next sentence says Meteor is abandoning this and that. And you go on to say ‘React is very popular right now, so let’s abandon Blaze and focus on React’.
Sorry, the newest thing does not mean the best thing. Not for everyone. It doesn’t matter if you’re a newcomer or an experienced Meteor user.
3 Likes
This is the hide agenda of MDG?
Good arguments.
The reality is whether you like or dislike to use React you have to use React in Meteor or leave Meteor in the future.
As Meteor is entirely bet on React, the future of Meteor is only a sub-group of React. One thing I need to point is that large corporations don’t like to use React because of its poor form processing capability. Angular 2 will be widely used. Unfortunately, Meteor has several years early opportunity to enhance Blaze and replace Angular, in corporation business market, but wrong selection made. React is good for startup but not for everybody. It is in growing pain. Even its syntax changed dramatically.
This is strictly not the reality. I feel like people are extrapolating from our announcements and assuming we are hiding something about a secret plan to force everyone to use React. That couldn’t be further from the truth.
4 Likes
Npm and module loading should do the trick, if I’am not wrong…
@sacha I agree 100% on using components that the JavaScript community has made and then making a good abstraction for the Meteor parts. In the past so many packages are either tightly coupled or are just a wrapper that locks in the NPM version.
I think this practice will also level up developers to make great abstractions that are view/database independent.
I just created an issue on GH for Griddle… looking to add a loading indicator that will work with Meteor publications 
1 Like
Agreed! Meteor is fantastic as a bundle of server and client-side libraries. React is winning, so embrace it fully and continue being the bundle of various React-relevant server and client side libraries, rethinking what fits and what no longer fits. It’s time to be opinionated and declare a winner instead of trying to be all things to all people. Not when development resources of MDG is limited.