Brett Slatkin writes about software engineering, web protocols, and functional programming, drawing on work on PubSubHubbub, App Engine, and Camlistore.
Commenters point to his credentials in building web infrastructure when responding to his HTTP and templating posts, and link his WebFist and functional programming posts.
This other "The case for dynamic, functional programming"[0] post may offer hints. So I suppose it will be more like Elixir/BEAM.
> Theoretically, functional programs should: have fewer bugs, be easier to optimize for performance, allow you to add features more quickly, achieve the same outcome with less effort, require less time to get familiarized with a new codebase, etc. With a dynamic, functional language you could enjoy all of this simplicity.
In my experience use of static typing has fewer bugs and better performance than my usages of dynamic languages on all but small or short-lived projects.
I suppose this will round-out Google languages: Go, Dart, and _, until they make their own scripting or an actual systems language.
[0] https://www.onebigfluke.com/2022/11/the-case-for-dynamic-functional.html
The talk that had the most influence on how I write software is Robert 'Uncle Bob' Martin's "Architecture: The Lost Years" [1]. Being a Ruby conference keynote, it helps if you know how Ruby on Rails works, but the lessons apply to all software.
Another one would be "Let It Crash! The Erlang Approach to Building Reliable Services" by Brian Troutwine. [2]
I don't know if you would call it "technical" but Brett Slatkin's talk on Cohort Analysis is something anyone interested in tools to analyze how our users behave should watch. [3]
[1] https://www.youtube.com/watch?v=WpkDN78P884
[2] https://www.infoq.com/presentations/erlang-reliable-services
[3] https://www.onebigfluke.com/2013/05/video-cohort-analysis-talk-at-google.html
The premise that server-side HTML generation is faster than client-side HTML generation is simply false. See here for experimental confirmation: http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-side.html
Why would offloading computation to a heavily-taxed central server speed anything up? It doesn't make much sense. Nor is HTML generation a bottleneck in most realistic applications.
This would break a cool indieweb "hack" with DKIM - webfistbump, which lets folks participate in webfinger even if their email provider doesn't support webfinger, like gmail:
https://www.onebigfluke.com/2013/06/bootstrapping-webfinger-with-webfist.html
(I suppose you could just re-opt into webfistbump every time your email provider is about to publish their DKIM key)
Yes, there is: http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-side.html
The server-side render can't be cached. I guess it is only possible if the component is using the PureRenderMixin (https://facebook.github.io/react/docs/pure-render-mixin.html). Feel free to create a PR/issue about it in the repo !
Reading the earlier post, it seems the extra need is an escape key, which probably wasn't explicitly written since, you know, it's not exactly a differentiator among non-Apple laptops.
http://www.onebigfluke.com/2016/10/lamenting-progress.html