5 ms·
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
by dsp1234 11y ago
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/ https://marko-progressive-rendering.herokuapp.com/
[1] - https://github.com/marko-js/marko https://github.com/marko-js/marko
- stevebmark 11y agoI'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.
- marcusarmstrong 11y agoit's only what I already know, Javascript and HTML But it's not. "className", much?
- Nogs 11y agohttp://www.w3schools.com/jsref/prop_html_classname.asp http://www.w3schools.com/jsref/prop_html_classname.asp
- marcusarmstrong 11y agoSure. But that's different than <div className="blah">.
- smhg 11y agoNot 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.
- smhg 11y agow3schools might have gotten a bit better lately, but please use MDN as a reference: https://developer.mozilla.org/en-US/docs/Web/API/Element/className https://developer.mozilla.org/en-US/docs/Web/API/Element/cla... They offer so much more context.
- deleted 11y ago[deleted]
- petrbela 11y agoOh boy, "className" and "labelFor". See, wasn't that hard to learn JSX if you already know HTML.
- marcusarmstrong 11y agoI'm not saying it's hard. But {?variable} isn't hard either.
- smhg 11y agoI 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.
- petrbela 11y agoYeah, thanks. I don't actually remember if I've ever used it :D
- dsp1234 11y agoAlso 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.
- stevebmark 11y agoTo 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.
- dsp1234 11y agoThis 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.