My request to you, fellow Meteor developers and forum participants:
This new modern/legacy bundling system is unique to Meteor, for now. No other framework (to my knowledge) has anything like this, and I’m honestly not sure how most of them are going to implement it, without all the advantages that Meteor brings to the table. More so than ever before, Meteor is now ahead of the game, and other frameworks will have to catch up. Please read the blog post, learn how to explain this powerful technology clearly, and then tell every web developer you can about it. Ask them if they’ve ever wanted to use native ECMAScript features in modern browsers. When they tell you “sure, but that won’t work in IE10,” smile and suggest they have a seat, because you have some great news for them.
The voting algorithm penalizes directly links to the article. So if you can find the article on https://news.ycombinator.com/newest it’d be a bit better. The title of the article is “Meteor 1.7 and the evergreen dream”
You guys should coordinate the hacker news posts better, and get the community to sync so that it can get front-page time! The blog post was really awesome, thanks for taking the time to explain things so well
However, I tried to upgrade to 1.7.0.1, install babel/runtime and meteor-node-stubs, but upon starting I’m getting like 300s of babel transpilation, which eventually crashes with Too many files open error. Am I missing something, or is this a new shiny bug?
I don’t see how polymer can provide this since they don’t serve the files. Sure, they can make multiple bundles. But that’s not different than having multiple .babelrc configurations and that’s not really what is new here. What’s unique here is that depending on the features / packages you use Meteor will automatically determine what it needs to do and automatically serve the correct bundle to the browsers.
I think he is referring to the webcomponents-loader.js, it seems that it does a client side detection and dynamically load the required pollyfills, not sure if this is similar to what Meteor 1.7 does, I’ve to look closer.
Either-way, I’m extremely happy with Meteor 1.7! benjamn and team did an incredible job pushing above and beyond what’s out there.
Meteor 1.7 definitely wins in this comparison, since we send modern assets to any client whose User Agent string (from the HTTP request) can be reliably classified as modern (and everyone else gets legacy assets), so we don’t need to do any client side feature detection or dynamic loading with additional HTTP requests. That’s what I was getting at in this tweet. This means the modern bundle can use a totally different compilation strategy (not just different polyfills), which is what allows us to ship native async functions to modern browsers without compiling them down to ES2015 generator functions.
Meteor gets a lot of hate from parts of the wider JS/coding community.
Most of it is unfair and probably stems from people trying Meteor in 2013 and hating on certain elements of it.
Has there been any thought in reviving the brand/community a little?
I feel like in the JS world people just move on to the next shiny thing that comes up…
