Live data from Hacker News

Announcing Meteor 1.2 – ES2015, Angular, React, and More

info.meteor.com

131–140 of 140 posts

Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More

#131

I am debating between meteor and relay at the moment. I am thinking relay. Maybe because of graphql, maybe because I don't like the fact that Meteor was pushing Blaze up until recently. I don't know yet. Anyone want to do a comparison of the two? :)

I have looked at both and Meteor has had the architecture that Relay provides for a longer time. On top of that, it is easier to use / setup and allows you to get developing at a faster pace and still use React.

TLDR; Meteor and Relay are very similar, but Meteor is much easier to use.

Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More

#132

Earlier quoted context omitted.

If I'm not mistaken every page on this site is React, rendered on the server: https://kadira.io/blog/ More info: https://kadira.io/blog/meteor/meteor-ssr-support-using-flow-...

It does indeed appear to be so - and it works great if you disable JavaScript. In fact, if anything, it works better if you disable JavaScript, because it doesn't flicker and jump around as it renders. You might almost be forgiven for wondering why it wasn't just exclusively rendered server-side, really, except it'd probably be heretical to conceive of such an antiquated idea.

They don't exclusively render server-side because it's tremendously CPU-heavy: https://twitter.com/kadirahq/status/620467416749838336

Over the years, Rails has evolved a lot of ways to do server-side rendering while sharing as much as possible between runs. React isn't there yet, but there's no reason that it can't do the same given enough time.

Until then, in many ways, as a user of a site with a modern JS-enabled browser, I'm providing my own CPU power to render dynamic content, thereby subsidizing the site's cost of supporting older/non-JS browsers with SSR at negligible cost to myself (though I suppose everyone's utility function handles occasional flickering differently). I, for one, don't see any problem with this arrangement.

Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More

#133

Earlier quoted context omitted.

Works great. Just isn't part of core. Meteor core is stubbornly trying to force use of atmosphere for everything. But everyine I know immediately installs https://github.com/meteorhacks/npm which allows for using regular npm packages. I think inevitably the meteor team will bring this into core, or something similar, and we will be able to have our mix of atmosphere and non libraries.

Thanks. Should any other packages be in core that are not?

A router. But I don't think the community has quite solidified around a single router yet.

Iron-Router was the lead for a while.

I don't think these should necessarily be in core, but here is my list of pretty much always-installed modules:

stevezhu:lodash iron:router meteorhacks:npm meteorhacks:async aldeed:collection2 aldeed:autoform aldeed:tabular xolvio:cucumber yogiben:admin

Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More

#135
post #27

Earlier quoted context omitted.

It's not just useful for SEO; isomorphic React apps render much quicker on first load and for deep linking into your app.

> isomorphic React apps render much quicker on first load source?

The issue is not so much about whether React components themselves are rendered on the client or server, it's about the network: all the JS and other data that has to be loaded in general before the browser can begin rendering.

With React you can use the same component code used on the client side to generate HTML on the server side and send that down the wire for first page load. The browser doesn't have to sit there waiting for entire libraries to load and then start building s.

Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More

#136
post #132

Earlier quoted context omitted.

It does indeed appear to be so - and it works great if you disable JavaScript. In fact, if anything, it works better if you disable JavaScript, because it doesn't flicker and jump around as it renders. You might almost be forgiven for wondering why it wasn't just exclusively rendered server-side, really, except it'd probably be heretical to conceive of such an antiquated idea.

They don't exclusively render server-side because it's tremendously CPU-heavy: https://twitter.com/kadirahq/status/620467416749838336 Over the years, Rails has evolved a lot of ways to do server-side rendering while sharing as much as possible between runs. React isn't there yet, but there's no reason that it can't do the same given enough time. Until then, in many ways, as a user of a site with a modern JS-enabled b…

Yep. We don't render all the pages. But most of the pages of https://kadira.io is public. So, we cache a lot.

Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More

#137
post #134

Hopefully not too off-topic but is there a reason some people refer to the new spec as Ecmascript 2015 or ES2015 vs Ecmascript 6 or ES6? I was a bit confused and had to look it up, and had never heard of previous specs being referred to as ES2011 or ES2009.

It used to be called Ecmascript 6 (aka ES6), but the name was changed to help enforce a more frequent update. So, it changed from ES6 to Ecmascript 2015 (aka ES2015).

Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More

#138

Earlier quoted context omitted.

So... as it happens I have a lot of experience deploying Meteor apps to servers that don't belong to Meteor. In fact, I may have a greater variety of such experience than anyone. As the lead developer of Sandstorm.io, I have deployed Meteor: * As the Sandstorm front-end, where Sandstorm is designed to be installed by end users on their own machines. * As apps that run on Sandstorm, and are designed to be extremely fi…

> On Sandstorm, we find Meteor apps much easier to package than anything else, because the Meteor tools will output a self-contained app bundle that operates in a consistent fashion for all apps -- thus allowing us to write a common packaging tool that works with all Meteor apps. What does that mean exactly? I admit, I only kind of know what sandstorm does from it's marketing page (looks like it offers VM's in a more…

The easiest way to understand what Sandstorm does is through the demo: https://demo.sandstorm.io

Try installing Wekan, which is a Meteor-based app.

The thing that makes Meteor easier for us is, as I said, the meteor tools have a command "meteor build" which gathers all of the app's code and package dependencies and puts them into a self-contained directory tree with a start script that is executed the same way regardless of the app. This makes it easy for us to build a tool which turns any Meteor app into a Sandstorm package because the input is in a well-defined, self-contained format.

We are, of course, building tools for other stacks as well. It just takes more work.

Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More

#139

Earlier quoted context omitted.

Are there any good guides/videos on getting started with Meteor+React?

There is an official guide: https://www.meteor.com/tutorials/react/creating-an-app

Thanks for the link.

On first glance seems like writing in React is way more verbose and cumbersome than the Blaze equivalent. What are the benefits of going the React route?

Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More

#140
I love meteor and can wait for galaxy! atmosphere is awesome, so I can only expect something amazing.

The react integrate is pretty cool too I just did a trello clone to learn more about react https://github.com/hipstersmoothie/react-meteor-trello

Now I just need a new project to use react with!

Post reply on HN