Two great articles I reference in this tutorial:
Anyone else has done good benchmarks on real world single-page-apps which do a lot of back-n-forth communication with the server with http2?
I don't expect things to get suddenly extremely better (specially since resource fetching is only one of the bottlenecks), but maybe it could bring a mid-way between the server vs client side rendering war.
For reference: https://blog.alexmaccaw.com/time-to-first-tweet
If performance and time-to-click was your concern.
Disclaimer: i'm the author.
From what i gather, React Native is good enough for simple things and is iOS-first, but quickly fails to live up to the hype for anything moderately complicated and is actually slower than apps that are native from the get-go. I'm not sure if this is still the case, but aiming for the lowest common denominator seems like a lot to give up.
I would be interested to see a React Native app that truly benefits from being native, aside from the app store and distribution aspect.
1) First there were the "hashbang" URLs, that Google said they'd crawl fine, but that did affect Gawker's SEO: http://www.webmonkey.com/2011/02/gawker-learns-the-hard-way-...
2) And instagram uses server rendering for SEO: https://twitter.com/cpojer/status/711729444323332096 (via http://jamesknelson.com/universal-react-youre-doing-it-wrong...)
why not use the RFC terms? https://tools.ietf.org/html/rfc3986#section-3 "url fragment"
Also, it won't help you on server side rendering since the server will never even see it on the request.
Because it's specifically different, on purpose. The RFC doesn't cover the "bang" part....the "!".
>>the server will never even see it on the request
Explained on the (now deprecated) page from Google on this "hashbang" approach:
*"The answer is the URL that is requested by the crawler: the crawler will modify each AJAX URL such as www.example.com/ajax.html#!key=value
to temporarily become www.example.com/ajax.html?_escaped_fragment_=key=value"
It will when Googlebot sees the link and rewrites the URL.
Also, interestingly, this is a new way Google could push Angular: just make sure Angular powered websites don't suffer from this...
Google and other search engines have brilliant people working for them who can create systems which can guess what I want to search before I have entered the entire query, and you are telling me these same people can't do something about pages using the latest technology. Sigh.
But I think, while we're making assumptions about the kind of technology good engineers should create, let's also ask Google-led Angular and Facebook-led React (and similar projects): if your library can manipulate HTML and the browser DOM, even while using async network requests to load data, why can't it take that same data and code to provide an HTML string upfront, as a "First Render"? This should be the standard way to do it. If React can re-render an input box every time I type a character, and not just generate HTML but also directly manipulate the DOM to reflect it, surely it can generate HTML for the input box upfront. (I don't know enough about the internals of these libraries, but maybe the fact that React is declarative makes this easier than it is for other libs.)
I don't think Bing and Yandex are supporting this yet though.
I don't think anyone disagrees with this, but production sites would then have an incentive to wait until search engines have figured it out. Or otherwise suffer the traffic loss.
# "With Love" uses an external API server; how would I handle API requests on the same server?
# There's no real demonstration of how to do routing beyond a single route.
# "With Love" is unfinished, with no live updates etc.
# How to integrate even simplistic file-based persistence?
The Facebook tutorial had all that, but I wasn't sure how to integrate those features into a server-side-rendered framework. So essentially my next step would have been to figure out how to do what you just did here. The extra work of making the application functional (beyond just showing the pre-rendered screen) is icing on the cake.
Ouch, any chance that these examples could be dual-lincenced under cc0/public domain (where applicable) and something like MIT/BSD/APL in jurisdictions without public domain?
Because, frankly examples that are: "The examples provided by Facebook are for non-commercial testing and evaluation
purposes only. Facebook reserves all rights not expressly granted." are worse than useless. If you end up using anything from the examples in production, you're in breach of copyright!?
Edit: yes, I understand that rendering means generating HTML, but sometimes the HTML depends on display size.
the irony indeed.
But in my particular case the websites need to be server-side for SEO, so it's mostly just that I want to use React for reusability and because I prefer it over wordpress theming with php tags.
Furthermore, I can now use React and still deploy the site on a typical LAMP-stack cheap hosting!