Hacker News Reader

Comment by stevebmark | Hacker News Reader

I'm really excited about this! While working on an "isomorphic" app, data fetching gets incredibly complicated. There are many edge cases. For example, when rendering on the server, you have to block all renders until all data fetching is complete. But on the client, you can show the view with a "loading" indicator, as in not block. But you only need to fetch data for that route on the client if it hasn't been fetched on the server...the rabbit hole is full of wheels you don't want to reinvent.

I'm hoping Relay solves the data fetch problem in a way that makes isomorphic applications much cleaner.

View on HN

Meteor already does this. In your template (Blaze) you can wait for your subscriptions to be ready and in the meantime render a loading icon or something else. Check it out!

In this case, I think the more accurate example would be Meteor + React [1]. You can still show the "wait for data to be ready" state as you described. (For those interested, follow the linked tutorial.)

The Kadira team have even gotten Server-Side Rendering working with React [2][3] while no-one has yet for Blaze because the Blaze templates aren't currently available on the server due to how the bundler works. I'm sure MDG will make them available soon and then we'll be able to have SSR with both React and Blaze.

1. http://react-in-meteor.readthedocs.org/en/latest/

2. https://github.com/kadirahq/flow-router/tree/ssr

3. https://kadira.io/blog/meteor/meteor-ssr-support-using-flow-...

you have to block all renders until all data fetching is complete.

Not if you use a server side templating engine that supports async rendering like MarkoJs [0][1].

[0] - https://marko-progressive-rendering.herokuapp.com/ [1] - https://github.com/marko-js/marko

I'm spoiled by the niceness of JSX. It's a very clean and expressive and easy to read language, because it's only what I already know, Javascript and HTML. There are no APIs to learn (except for some minor cases, like inline comments). This template language looks like it would only have downsides compared to JSX. It's a new syntax to learn, and less expressive. This templating language even adds HTML-like attributes! What a mess.

Also I don't think the templating language has anything to do with the nature of blocking vs non-blocking data fetching.

Also I don't think the templating language has anything to do with the nature of blocking vs non-blocking data fetching.

The previous commenter was specifically talking about the issue where the client side of an isomorphic application can "show the view with a 'loading' indicator", but generally the server is not able to stream out the full HTML until all data has been gathered and processed. The templating engine that I mentioned has a solution to that specific issue.

For example, in the first link, you can see that even though the template is rendered on the server, and has a data source with a 3 second delay, it does not prevent the rest of the template from being rendered and sent to the client, and includes a "loader"-like message (you could easily plop a loading gif in there instead of the textual message in the example).

So it does seem relevant to me.

To clarify, the loading case I mentioned is related to single page apps. The server isn't the one rendering the page when the loading indicator pops up, that's entirely a client side render ("isomorphic" being the ability to fully render on client or server side with the same codebase). The server doesn't need to stream a page with a loading indicator in the HTML. Being able to stream part of the app while data is loading (like the header) does seem like an interesting case, but it would only matter for the initial page load in an isomorphic SPA.

This templating language even adds HTML-like attributes! What a mess.

    <ul>
        <for each="item in items">
            <li>${item}</li>
        </for>
    </ul>

I have no problems with a mess that looks like that. Anyone on my team could pick that up with no problems whatsoever.

it's only what I already know, Javascript and HTML

But it's not. "className", much?

Oh boy, "className" and "labelFor". See, wasn't that hard to learn JSX if you already know HTML.

I think you meant htmlFor, no? But I completely agree with the sentiment that it is nice to stay as close to plain HTML and JS as possible.

Yeah, thanks. I don't actually remember if I've ever used it :D

I'm not saying it's hard. But {?variable} isn't hard either.

http://www.w3schools.com/jsref/prop_html_classname.asp

w3schools might have gotten a bit better lately, but please use MDN as a reference:

https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...

They offer so much more context.

Sure. But that's different than <div className="blah">.

Not much. These are actually the Web API attribute names you should use when accessing these attributes from a non-HTML language (e.g. JavaScript).

The React folks didn't make them up.

Reply on news.ycombinator.com