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.