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.
It’s not difficult to integrate Polymer with Meteor. We started using the example from Differential but found a better development experience using a split solution.
We have been using Meteor + Polymer for implementing a SCADA system for industrial control with great results. Polymer + only the client side part of Meteor was used to build the app UI, and the rest of Meteor for everything else. The client side connects to the meteor server to get DB data.
During development, Polymer iron, paper and our own components requires A LOT of files, and using Polymer directly with Meteor without “Vulcanizing” these files makes it painfully slow to rebuild the application. To avoid this, we run meteor server and then the client part of the app using node http-server. This way, any change on the client side of the app doesn’t trigger a rebuild/restart of the entire app.
The Polymer app includes the client side part of Meteor in order to have subscriptions/tracker/etc. available. You can use something like frozeman/meteor-build-client to get meteor code. It will also include all client side packages included in meteor.
To build the final app, we use the vulcanized version of the Polymer app.
Our application have a screen showing 1500 variables at a time, representing different states of polymer components (motor states/speed, analog and digital sensors, etc) with excellent performance.
I loved Meteor when it started out with blaze. Now that there is supposed support for Angular & React I feel like the community is split & nothing I use actually works without a lot of troubleshooting. I haven’t tried the React tutorials but the Angular tutorials are a complete disaster - even the bootstrap section (on the very first page) lists outdated packages & doesn’t even list all the require npm packages.
I just wish Meteor would stick with 1 client-side framework that just works or makes sure that tutorials are kept up-to-date for all supported frameworks. Even though I think web components are the way to go I’d be happy learning React if I was sure that going down that path wouldn’t result in the same problems I’m having with the Angular stuff.
Let’s hope that one day Meteor finds its way back. Until then I’m going back to alternatives.
The thing with webcomponents is that you can just use them in Meteor or most other build tools. They just work these days. Polymer for example (which is now so stripped down that there’s barely any library left) is just a bunch of JS imports. No magic needed to work with Meteor.
I can understand your frustration with documentation and support for frontend frameworks, I think the issue is just from the “legacy” era of needing to stick with some framework as support. Moving forward, tools like Meteor shouldn’t say “works with React, works with Angular”, etc…
Given that Meteor supports modern standards (which it does), we should assume it works with everything, as long as the framework is aligned with open standards. Then it all boils down to people maintaining good docs and that would be it. No more integration hassle.
Well if we look the poll currently running about what frontend would u use the battle is between Blaze and React it is about 50/50. Ifhttps://nos.nl/artikel/2206015-aanvullende-zorgverzekering-levert-niet-genoeg-op-afschaffing-dreigt.htmlri by example React wins the option Blaze users might leave on the otherhand is Blaze wins React users might leave. Blaze now as opensource but how will mantain it for longterm. Also supporting every type of frontend like angular vue, blaze react leads to high cost.
For starters Blaze is good start and at lots of directly usefull standard at https://atmospherejs.com/.
For React it is the same if it becomes to complex to choose the community will not grow but slink perhaps
I fail to see how web components are going to solve this problem. You still need a front-end framework to build the application. Meteor does not make it easy to integrate with front-end frameworks because of the lack of documentation. Either create generic documentation about how a framework could be integrated or drop “support” for Angular completely.
If Meteor had said “use React” I would have gone that route & not spent weeks building components in Angular 2 only to find that I now cannot use them with Meteor without spending hours to figure out how to get Meteor to play nice with Angular. I now have to drop Meteor in favour of something that works with Angular.
What you said is not quite true. If you read their documentation you will actually understand how easy it is to integrate Meteor with any view layer. It’s mostly a matter on how to integrate Tracker (respond to reactive changes)
Many people successfully integrated it with Angular, Vue… and React ofcourse.
Meteor actually suggested shift to React when they dropped Blaze support.
It is not just the run time integration to consider - you also need build compilers to process the different file types. Besides the meteor-rxjs runtime package there is also angular-compilers (encapsulating 4 build packages) but you can never be sure what state those packages are in from one release to the next - even now the boilerplate app crashes after fixing the errors just to get Meteor running. This might be because I’m on Windows but Meteor is supposed to support development on Windows. I either have to fault find meteor-rxjs & angular-compilers or maintain 5 of my own packages (updated at each Meteor release & each Angular release) just to get Angular integrated - that is definitely not cost effective considering something like webpack has a large community supporting their build plugins which actually do work straight off the bat.
Bottom line: Meteor should remove claims that they support things that they don’t! Having a half baked something is worse than not having anything - at least you don’t waste time on it, thinking it will work.
