Good points
I just want to make sure I am picking cement blocks rather than (soon to be) waddle and daub…
Good points
I just want to make sure I am picking cement blocks rather than (soon to be) waddle and daub…
I agree. I started using Meteor when it was just Blaze (pre 1.0). At the time one of the core value props was to people who didn’t normally identify as developers but as casual (business) coders or tinkerers to be able to more fully prototype and realize an idea - quickly and easily. It was empowering. It said, 1 language, easy templating, come on in and see just how easy it is.
In other words it sold accessibility and (relative) ease of use that was harder to get elsewhere.
Right it feels they are trying to ride the fence between developers who want flexibility and the latest hot framework (react / angular etc) but also try and keep the orig. value prop & message for the “casual coder”.
The only issue is no casual coder is going to learn React. They aren’t and shouldn’t have to. I’m not arguing whether or not React is great or better than Blaze - it’s about what the value proposition is and to WHOM.
Right now I have an app that is languishing because of this - and frankly am gun shy to spend too much time in fear that more will change and therefore the orig. value prop that existed will be wiped out (keep breaking). No one wants to re-learn / re-build constantly and it feels like that right now. It doesn’t feel “stable”.
If React is the thing so be it. Then I agree, commit. Focus on 1 value prop for a single base. It’s not about Blaze vs. React or what’s better overall - it’s what the value proposition and the benefit it provides to a casual (business) coder (accessible, easy to get up and running, get to a full stack prototype fast and easy) vs. developer (build the most highly scalable, dev op efficient, with latest language / flexibility etc etc etc).
In the end the best products and services focus on 1 core value prop and 1 core product for a core set of users rather than “hedge its bets”.
If Meteor goes the way of React then do it - I would be sad as a casual coder because I really liked Meteors early simplicity - but at least I would know that I should stop using Meteor and stop trying to build things that may stop working for me depending on what direction they choose.
They way I see it, Meteor has just been extended with more functionality - more freedom of choice if you will. The old ways are still valid, and will probably continue to be for a long time (guessing).
I think the whole “Meteor vs The future” discussion boils down to a couple of things happening simultaneously due to the way Meteor has evolved over the past 6 months:
Confusion of what view engine to use (aka least headache in the foreseeable future).
Adapting to the new app structure.
Understanding imports
and other new ES2015 conventions.
Knowing that more changes are waiting around the corner (Apollo).
These issues paired with somewhat fuzzy directions from MDK and the Meteor Community during this time has caused a lot of unnecessary confusion.
I think all of this can be fixed quite easily with clear directions and guidance from MDK.
Yep - this was really the purpose of my original plea: too much choice is not always a good thing.
UPDATE:
I decided not to throw out the baby with the bathwater: I have followed @sacha’s Study Guide and also followed the same pattern that he used to update the Discover Meteor website up to (but not including) the actual adoption of React.
I am sticking with the Blaze that I know and love, but, should it become necessary or desirable I am now in a position to make the switch with considerably less pain. I have also familiarised myself with React (via this excellent tutorial) and have found that it is not too scary. But I prefer Blaze and I am hoping that it will remain a viable alternative - preferably with the active support of MDG.
Glad you found the study guide helpful! And if you like Blaze, I hear good things about https://vuejs.org/ I can’t say I’ve used it myself though.
Oh no! not more choice!
Problem is, the “clear default” according to their public announcement (last users heard) was Blaze. The public announcement stated Blaze was still their main recommendation and that “may” change in the future.
So right now, their recommendation (also in the guide) is still Blaze. But many of the React advocates feel it’s pretty obvious they are focusing on React (and it’s true that it does seem React may become more related to Meteor - since Blaze is now going to be community ran).
This leads to a lot of confusion. The official recommendation is Blaze,but ironically Blaze is not going to be officially supported further. Which is kind of a weird situation.
But in this case, the question that should be raised imo is what would be best for NEW USERS of Meteor to learn on? Blaze or React? When it comes to new developers, you can be pretty sure all of them have experience with HTML (which means they can use Blaze), while not all of them have had experience with React.
So even in the long run, should the roadmap for learning Meteor be better suited for Blaze or React?
@Spyridon I’m a bit surprised, because I was not under that impression. Can you point me to where you read/heard that, and what part of the guide you are referring to here.
Specifically, this:
For now, between React, Angular, and Blaze, there is no single best choice. All have pros and cons and you can’t yet “have it all”. Speaking as MDG, we are going to continue making Blaze our main recommendation for new apps in Meteor, while also standing behind Angular and React for those that prefer them.
Let me push back for a second. I’m reading a lot of criticism, but I’m not sure you guys realize how good you have it.
I am also a business owner turned midnight programmer. And I’m new to Meteor. In 2011 I learned LAMP, but two years ago I needed a real time app with a single source of truth on the client. I had many false starts. But recently, after 6 agonizing months, I have a real time inspection app written in React/Redux/Webpack/Socket.io/Node/Express.
And then I deployed it with reverse proxies, web socket tunnels, etc.
I found Meteor after an exhaustive search for something better. The grousing over Blaze vs React makes me chuckle. I encourage everyone to drop back to node and hand write code for optimistic updates, error handling (did you know database errors and script errors are totally different in the promise/catch? I didn’t either), authentication, socket emits, endless endpoints, etc to fall in love with Meteor all over again.
And to those worried about React, my amateur self felt comfortable with it in a few hours. The JSX syntax is natural, and the concept of state and props intuitive. I highly, highly recommend guru Wes Bos’s React class: https://reactforbeginners.com Then take Steven Grider’s excellent course React with Meteor 1.3. https://www.udemy.com/meteor-react-tutorial/learn/v4/overview
React becomes complex with data stores (Flux implementations like Redux and MobX are the leaders). But Redux is largely redundant with Meteor. Redux would be helpful for integrating Meteor with a third party API.
All frameworks have growing pains, and that’s a good thing. But I wouldn’t lose sight of Meteor’s genius. The genius isn’t in opinionated view layers but in dramatically simplifying boilerplate that adds years onto development. To that end, it doesn’t seem to have changed.
Robfallows beat me to the link, but yes that was the last “public” announcement that I know of where MDG addressed React & the main recommendation. Here is a link: Angular, React, and Blaze
I’m a bit surprised staff is not aware of this, as this post has been referred to many times since 1.3’s release.
I also want to extend a bit past the quote that robfallows linked. Here is the continuation of the quote at the bottom of his message:
The reason for this is that the ecosystem of full-stack packages around Blaze is so powerful – we can write a much better Guide against Blaze. Eventually we may switch that recommendation to React or Angular 2 as they come up to parity with Blaze.
Anyway, I hope that now you can see where the confusion is coming from for us users. We were told the recommendation is Blaze, and it seems staff isn’t even aware that React is not the recommendation. People don’t know what is best, and more importantly don’t know where to start.
I already chose to stay with Blaze for the time being on my project, due to the fact that I have to work with other employees and can not count on them all knowing React (or having to train them). And honestly, even Blaze has been difficult to teach them with Meteor 1.3 onward (having no suitable tutorials for absolutely new users to Meteor I had to teach them myself). We are using ViewModel, so we may switch to React later on in the project (ViewModel makes it easy now that React support has began to be released). But as of now the plan is to stick w/ Blaze for the time being.
Going through that experience recently (the new employees started in early April) I believe it’s important that we ask ourselves now… which is best for NEW USERS to LEARN Meteor with - Blaze or React. My thoughts are that Blaze may be better suited for the very first tutorials users have with Meteor - as everyone knows HTML/CSS but not necessarily React. But that is up to MDG & the community to decide.
@robfallows @Spyridon Thanks for the link, I remember that post, but I didn’t remember that it made a specific recommendation. I think the point that Geoff made about there being no single best choice for every app is still true today.
However, it seems that some more detailed guidance from MDG could be helpful. Maybe a good way of doing this would be through the transmission podcast, where someone from MDG could go into more detail on what we think is best for what kind of app?
Yes. The impression that I gain from all of thee posts is that Blaze is the solution of choice for newbies and for those wishing to throw together a prototype quickly and easily. Certainly that is my experience.
For larger, more involved apps, it competes with (but is not necessarily inferior to) React.
Since most newbies do not expect to be newbies forever - and since prototypes often grow into full-blown projects - developers want some assurance that they are not working with a redundant or doomed technology (Blaze). Who better to provide that assurance than MDG?
Of course you are right and I hope we have not been too churlish. If it seems so, it is only because we care.
MDG - love your work. Obviously.
MDG can provide reassurance, but with Blaze being run by the community, you can be sure the community isn’t going to give up on it.
I do think it’s superior for prototyping and easier for new users to learn on. Until traditional education starts incorporating React in to their lessons, I do not think React can really compete for new users with Handlebars. It’s just not intuitive enough for users who already know HTML/CSS.
While React is really not that complex, it’s overwhelming for new users to have to learn React PLUS all of Meteor. Plus, users already have to “keep up” with Meteor’s changes. If you are running a Meteor project with React, you have to keep up with both Meteor AND React.
Actually - as someone who has been overwhelmed (and a non developer) Vue is actually awesome. Super simple to use and written by a really smart guy who wants to see it stay simple. It kind of feels to me how Meteor was in the very beginning.
it’s a joint NSA/CIA plot
seriously, React is one of those polarizing technologies that just suck all the oxygen out of of anything else around… either you use it, and then half of Meteor is moot, or you avoid it as Blaze works fine and makes Meteor sense… I think the confusion in the docs represents the massive split in the community.
Many people from the non-meteor JS world recently joining Meteor are going to presume React, but other folks are like the OP…
Flow-Router is abandoned…
This thread is now over 4 months old, please open a new thread for new discussions.