Google's ability to indexing content is only part of the story. Google cant link to your content if its not deep link friendly and will rank it poorly if you content loads slowly. Both of which SPA are often bad at delivering.
I agree. The first release of IE had a user-agent starting with Mozilla and its something all major browsers (Chrome, Safari, IE, Firefox) still prefix their user-agents with.
Mozilla/1.22 (compatible; MSIE 2.0; Windows 3.1)
Still none of that detracts from how broken relying on user-agent to improve user experience is.
Browsers like Chrome seem to handle features like webp support better with the Accept: image/webp header but even that has its limitations if you care about animated webp or not say.
Although Go does not compile via C, occasionally C code does need to
refer to Go identifiers. Since we chose not to restrict the mangled Go
names to the space of valid C names, we must add some mechanism to
refer to Go names from C. That mechanism is:
1. In the assemblers and C compilers, which already accepted all
non-ASCII Unicode code points in identifiers, the Unicode characters ·
and / rewrite to ordinary . and / in the object files.
2. A symbol with a leading . has its import path inserted before the .
when being linked: inside encoding/json.a, a reference to ".Marshal"
is equivalent to "encoding/json.Marshal".
Because of 2, we went a long time without needing a special character
for slash. Recently the introduction of race detection has made it
convenient for package runtime to be able to refer to a few symbols in
runtime/race, hence the new slash lookalike."
Given how big the changes/cuts to OpenSSL so far this seems like a positive step towards making it a future credible alternative.
As for the vitriolic LibreSSL rhetoric. I for one hope that both projects continue to improve and thrive in the same way Chromium has since forking Webkit.
Not least because of the webs increasing dependence on TLS though changes like HTTP2/SPDY.
Single hardware with many cores does not give the same performance as multiple machines. For example, consider disk throughput. If the data is striped across multiple nodes then the read request can be executed in parallel, resulting in linear speed up! In a single machine you have issues of cache misses, inefficient scatter-gather operations in main memory, etc.
And it is much more easier to let the MapReduce framework handle parallelism than writing error prone code with locks/threads/mpi/architecture-dependent parallelism etc.
That sounds more like parallelisation rather than a use case for NoSQL.
Why is that any better than all of your data on one database server, and each cluster node querying for part of the data to process it? Obviously there will be a bottleneck if all nodes try to access the database at the same time, but I see no benefit otherwise, and depending on the data organisation, I don't even see NoSQL solving that problem (you are going to have to separate the data to different servers for the NoSQL solution, why is that any better than cached query from a central server?).
Basically, it's for efficiency reasons. Some of our sites have well over 40 pageviews per second and updating the numbers that frequently would put a huge amount of load on our servers and also crash the browser or make it go incredibly slow.
We also like to use the very same API that's available to our users in the Now and Trends dashboards as it encourages us to ensure response times are quick and that everything we track and display can be used programatically in custom integrations (such as the trending section on http://carthrottle.com).
[1] https://github.com/jadejs/jade/issues/298