Hacker News Reader

Comment by dsp1234 | Hacker News Reader

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