Angular2 is pushed by Google too.
The fact that Google is behind both of them, makes Googler’s answer more objective.
I think that the real reason is the internal support of browsers.
Especially Chrome, which is developed by Google too.
Today, WebComponent based apps run better under Chrome, because of the native support, while other browsers need Polymer to run these apps.
any suggestions for further reading on webcomponents vs polymer vs angular?
Isn’t angular 2 very component-based?
Maybe to stay on topic the OP should have a more concrete (useful?) question to discuss.
This is a very prepossessed, don’t you think? If all you get is a glorified build tool, then yes, everybody would agree it does not make much sense, not much to discuss.
Even though you start by stating you don’t want this to be a flame-bait post, it kind of is the same discussion we’ve seen here a thousand times by now. I don’t think much valuable has to be gained from discussing it once more. The reality is that there are now a lot of other popular javascript projects that functionally overlap with Meteor. If they fit your project better than Meteor, you should use those. That’s basically all there is to it.
2 Likes
And there you have your answer! It depends.
Try other stuff. If they really are more productive for you, use them. But this is a Meteor forum where we try to make Meteor better and help each other out with Meteor issues. Discussing alternatives? Sure. Shooting down Meteor again and again… why? What can we learn from those other platforms and integrate into Meteor?
Personally I still like Meteor very much and can’t wait for the 1.3 release. There are beautiful things coming our way like NPM and module support. MDG is making some good decisions, but all focus seems to go to a view layer discussion.
Opposed to what? Support everything you ever desire? They have some hard decisions to make and downsizing on some parts is a smart choice if you ask me. It gives me the idea that they know what they are doing. Outsourcing some components and keeping to standards (NPM, ES2015 + modules) will open up the way for many (node) developers.
We have a great tool in our hands called Meteor. Appreciatie it. Be critical, but positive and help improve it.
My 2 cents.
10 Likes
There is a specific standard (well, still some disagreements…) for WebComponents, which is implemented INSIDE browsers. It’s already fully supported by Chrome and Opera, and in various phases in the rest.
It contains 4 building blocks:
- Custom Elements
- HTML Imports
- Templates
- Shadow DOM
Polymer is a library that brings these features to browsers that don’t support them yet, as well as some other features. I would say that Polymer is Google’s elegant way to force the other browsers to adopt GOOGLE’S definition of WebComponents, because with Polymer, developers are not afraid to use Google’s standard: they know that their code will be supported natively by the leading browsers (or at least Chrome), and in the worst case (e.g. IE) - they always can use Polymer.
So WebComponents and Polymer are not competitors.
Regarding Angular2, it’s true that it adopted the concept of components, but not according to the standard that is being adopted by Chrome and others.
This is why many people claim that for the long run, WebComponents will beat anybody else.
The most vocal in the forum are using Meteor as a build tool. The other 95% are building product, fleshing out ideas, and using Meteor’s tools to iterate quickly.
For example, I use:
Meteor 1.2
Meteor’s React Mixin
Meteor’s React package
MongoDB
jagi:astronomy
Nothing fancy, nothing crazy.
With these five tools I’m building a social network website that otherwise would take so long and ultimately be a subpar implementation.
Want a notification system, here ya go:
NotificationsList = React.createClass({
mixins: [ReactMeteorData],
getMeteorData() {
var data = {};
var handle = Meteor.subscribe('notifications.unread');
if (handle.ready()) {
data.notifications = Notifications.find({}).fetch();
}
return data;
},
render: function() {
return (
// iterate through these mamajammas,
// show notifications records
);
}
});
// And in your server...
Meteor.publish('notifications.unread', function() {
return Notifications.find({ userId: this.userId , isRead: false });
});
Is there any other tool out there that gives you this power? Data on the wire out of the box, reactivity out of the box, React cohesiveness with minimal ceremony? Of course not, that’s why we’re all here. 
You know how long this took me? Design (my brother): 3 hours - Implementation (me): 15 minutes.
Don’t let yourself be discouraged by the developers that follow trends. It’s good they do that, otherwise how would we know what is worth looking at. But don’t follow them down that rabbit hole.
18 Likes
This reply sounds so condescending I’m not going to even bother.
You should always critically evaluate the pros and cons of a tool before using it. If what Meteor gives you is not enough for your case, then the logical decision would be to use a different tool.
I feel like the title of this post is one of those questions that has baked-in assumptions that reporters like to use - “has Kim Kardashian broken up with Kanye? Find out more inside!”
I think these posts are great, but would be a lot more valuable if they were more specific, for example: I want to build an ecommerce app and I’d like to use React for my frontend - does the Meteor data system still work for me, or should I switch to something like Redux? Or similar.
No tool is abstractly good or bad independent of the environment and use-case, so I think these conversations are inherently futile since each person is coming from a totally different place. It’s kind of like those Mac vs. PC or iOS vs. Android discussions which never go anywhere because there are pros and cons to both.
11 Likes
Hi @sashko , very fair point - I agree with your analogies and I apologise if my post seems like it’s just to stir things up un-necessarily. Over the last year I feel like I’ve been on an uncertain rollercoaster ride with MDG. However, I imagine my question will be one many are/will be asking as we move forward and it’s not something that can be boiled down to “it depends” if it begins to negatively affects MDG wallet through lack of customer acquisition. Of course that’s an “if” I hope you never have to deal with, but it would be silly to ignore.
To be clear, if I’m building a React SPA with Webpack - all of which are possible without Meteor, I just want to know that the Meteor bits are the best they can be.
Are you mostly using Meteor for the pub/sub mechanism then?
@sashko To clarify, personally I use Vue.js (building outside of Meteor) and yes, at that point Meteor is simply handling pub/sub and some backend processes.
For those interested in Vue.js & Meteor, here’s a great example https://github.com/vuejs/vue-webpack-meteor-example/blob/master/.client/app/app.vue
Also, Evan You (the author of Vue.js) currently works for MDG, which is fantastic. 
1 Like
Yeah in that case I would suggest titling your thread like so:
“If I’m using React with Webpack for building my app, what benefits do I get from using Meteor for the data layer?”
3 Likes
@sashko Apologies, lesson learned. Given your suggested title, is this the direction & area where we’ll start to see MDG focus their efforts?
No, I’m just rephrasing the question you stated in the form of a thread title. It seems like if you’re set on using Webpack and React, what you would get out of Meteor is: data, accounts, mobile, deployment, and perhaps some other things. It would be nice to have a thread that asks a specific question, I just gave an example of such a thread title.
3 Likes
My main reason for using and supporting Meteor is basically still the same after nearly two years of using it:
Smart developers that work on infrastructure concerns of my app that are not unique to my app for a very low price.
The main big feature for me is still easy real-time data synchronization between server and client.
I feel like the JS community’s moving too fast for MDG to keep up, hence why they’re downsizing the components that they are directly responsible for.
Makes sense to me. Focus is key. I don’t need MDG to focus on building things that are already done better in the wider JS community. Instead I value that MDG focuses on making those better things usable for me (in a Meteor app) in a well thought though way.
13 Likes
I don’t understand these posts, just use whatever you want. I’m learning as much as I can because I don’t know which framework or view, or whatever is right… But i know JavaScript is the way to go…and Components are obviously the future whether it’s React or Polymer style… Just choose whatever you want. Meteor is hell of a lot easier than setting up build tools, and gathering everything from scratch.
4 Likes
But that’s my point - when other projects also setup build tools etc., where does that leave us? Eg. see https://www.reactstarterkit.com/
Youre comparing Meteor with a series of cobbled together libraries. Would you compare Rails to that? What about Phoenix? What about Django?
Rails is similar in the sense of installing Gems and packages you need to build a project… rather than building your own web platform from scratch in Ruby using some build tools. Meteor IMO is like a low level OS that allows for rapid development, because they’ve taken care of all the hard work already, they’re allowing multiple View layers, soon more databases, etc… to work out of the box. Like I said… no one is forcing you to choose Meteor, if you enjoy configuring WebPack to compile, minify your files, hot reload, code splitting, setup server, configuring your database, choosing a model and view layer, etc etc… then do it your way?
1 Like