markuskobler

Its just a more aggressive version of name mangling that Uglify also 'suffers'[1] from. The setting does say advanced with good reason.

[1] https://github.com/jadejs/jade/issues/298

This probably won't help but it makes for a great quote when speaking about around this topic.

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 demoed how big the performance difference can be at Manning's recent powered by JavaScript conference https://speakerdeck.com/markuskobler/react-the-importance-of...

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.

So Russ Cox goes into more detail in this post https://groups.google.com/d/msg/golang-nuts/MdYlJbW4SAo/TrAE...

  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."

I have taken exactly the same stance which has the added benefit you can also drop the vulnerable RC4 cyphers.

https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weakne...

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.

On modern hardware with many cpu cores you can use a similar process of fork and join to maximise throughput of large datasets.

+1 to the request headers and HTTPS support

The redesign looks good. Out of interest why are you not using something like websockets or SSE to push updates to the client?

Are these trivial micro benchmarks, (simply respond with an empty 200) not totally misleading to focus on? Especially when you start to factor in many real workloads that involve disk or network io.