One of the criticisms of react is it’s an alternative to web components and really we should be heading towards an open standard. Seems the whole meteor+angular meteor+react meteor+blaze is just going to split a very small community into many subcommunites of people building stuff that won’t work together further hindering getting a lot of robust and mature packages that work well in a eco system.
So I wonder if its a mistake for MDG to integrate this stuff and instead it should take it’s own opinionated approach of creating a good eco system?
I like React; some people like Angular; others like Blaze. I feel like it would be pretty hard to convince people to drop their favorite view framework to use Meteor.
just as hard as asking them to give up sql? .net? php? rails? or any other web tech to get meteors reactive stack? I don’t think its really that hard. I think its harder to get people started when the meteor story is going to be split across too many tech stacks. Now there’s a real risk in choosing meteor+react that you are going to choose the dud branch and meteor+angular is going to get the cool stuff… or whatever.
One of the problems with web components is that compatibility and performance are horrible. Once this gets better I would imagine that React 2.0 will use this under the hood while using a thin abstraction. Likewise I imagine Ember, Angular would follow suite.
[quote="keithnicholas, post:1, topic:6970"]
Seems the whole meteor+angular meteor+react meteor+blaze is just going to split a very small community into many subcommunites...
[/quote]
I would imagine Meteor will get much larger because of this. I can’t stand using Angular but i’m glad it’s being added as a first class citizen. I also wouldn’t use Meteor if Angular was the only view layer option
I definitely disagree with this. Ideally I imagine Meteor like a middleware, that handles all integration and does the whole magic for you (latency compensation, reactivity, package system, etc) - your job will be to choose the best tool for your project (Blaze, React or Angular for your frontend, MongoDB, mySQL, RethinkDB for your data storage).
Specifically talking about React, will might not like it, but you can’t close your eyes for the hype. Attracting people through React is strategic for our community growth.
Meteor pitches itself as an App platform ( meteor.com ). Not middleware.
It says “Build apps that are a delight to use, faster than you ever thought possible”
It clearly is pitching a full stack and an opinion on how to create the UI. Its not “Build apps that use whatever front end you like for whatever front experience that front end framework may or may not give you.”
I got nothing against react. I use React. Its ok. If the reason for including React is its marketing potential for getting new people. I think that is the wrong reason. It should be because its the best thing for full stack Apps on meteor and then kill off blaze and angular. Then the meteor ecosystem will create a nice world of react/meteor packages that have a better chance of being able to be used together. I think its a bit crap the first decision you have to make when you come to meteor is ,hmmmm, should I choose blaze, react, or angular, with the following replies of … well it depends…blaze has a bunch of meteor specific stuff, but the cool kids have moved to react, so those will probably go stale… etc etc.
There is a great talk from wicked good ember where a netflix engineer has build a web components implementation using the ember glimmer engine (more performant than react).
Either way, while react is nice and supporting officially will definitely bring more people to meteor, I think it is more important to separate the view layer infrastructure from its abstractions.
So I imagine some sort of low level api that does rendering (react, vdom, web components, what ever it needs to be pluggable) and on top of that you can build your abstractions, whether that be react components, web components or blaze templates.
That way everyone wins, you get to have your react now but switch the implementation to web components when browsers support it natively.
I am into React for about 3 weeks now and i have to say it when you wrap your head around the immutable props and the simple way of defining components in tags and being able to not dig through templates it makes things easier.
I think React and Meteor are a great combination even with its early libraries.
I had the same experience as well. It’s unfortunate that there’s such a learning curve that you have to go through to really appreciate it. I hated it when I first saw it
React is great; until a couple years in, and the inline HTML becomes a tangled mess similar to PHP libraries. The pattern isn’t new. The industry has been down that road before, and there are known downsides to organizing code that way. I find most of React to be well thought out; but the inline HTML is what makes me cringe.
I think some people have implemented ways to keep it in a separate file if it makes you feel better. Nevertheless, I think components are the way to go, pure UI and all that.
It’s not simply a matter of feeling one way or another. It’s has a lot to do with managing legacy codebases, onramping team members, and having upgrade paths. If MDG is going to fully integrate React (and Angular), then we need refactor paths between Blaze and React. Otherwise, it’s just going to cause confusion.
We need something like this (which is where keeping the JSX in a separate file comes into play). [HTML, CSS JS] <==> [JSX, JSS, JS] <==> JS[JSX, JSS]
Hey, I’d love to hear more about what you think a more complete tutorial would include. Honestly, it probably won’t end up in the first official one, but it is good feedback for the future.
We don’t get much useful feedback about the tutorial, other than “it should include routing” (which I personally agree with)
Well for people like me who are brand new to Meteor, I come in to a tutorial looking to learn about most / all aspects of the platform. What you have currently, which I did complete, feels like the person already understands the platform and the code is just an example of what React looks like compared to Blaze.
What I would ask for, and this is obviously a 5 year old’s Santa wish list type of request, would be something along the lines of the Discover Meteor book. Chapter by chapter explanations / incremental code build up showcasing not only React code, but what Meteor as a platform offers and the code that can implement it, using the backdrop of an example app with github commits etc. (How cool would it be to have a chapter on React / Material-ui implementation?!?!?)
That way, anybody coming in new to Meteor, doesn’t have to use multiple books or tutorials and try to translate in between.
TL;DR: All I want for Christmas is a Discover Meteor knock off written for React.
Are you actually a couple years in on a React project? If not, I don’t think it’s fair to predict that. And having worked a little bit with React and a bit of legacy PHP code I can say the difference between outputting raw HTML as strings with PHP and creating components with inline HTML in React is night and day in terms of cleanliness and flexibility.
React has also provided more flexibility than yet possible with Blaze for a number of things I’ve had to code up.
One was an interactive grid layout we wanted to be able to embed arbitrary components into. I haven’t yet found a way to create a Blaze template that performs the grid layout and pass a bunch of various child templates into it that go into the blocks. The way this is done is React is crystal clear: the children that I pass into my BlockGrid component (which can be literally any components) are what get embedded into the grid blocks.
Another was notification toasts. I was able to create a toast store such that if I write toastStore.putToast(<div className="alert alert-danger">Something messed up!</div>) that div pops up at the bottom of the screen as a toast. And again I could pass absolutely any component into this store. As far as I’ve been able to tell that would be impossible with a blaze template without encoding information about the possible child templates that it could render into it.
This is a weird discussion anyway. It’s already pretty easy to integrate React/Webpack with Meteor. People will keep doing it regardless of what technologies MDG works on integrating.
