I worked at Khan Academy for two internships and then just under 2 years fulltime, and don't know anyone that has anything less than positive to say about Kamens (nobody called him Ben because there were no less than 5 Bens at Khan Academy when I left).
One of his most memorable habits to me was coming into a meeting room where his words obviously had a lot of sway, then sitting on the ground when we were short on chairs.
He was an inspiration to many, first as an engineer, and later as a manager, and I'm excited to see what he takes on next.
(Author here) I cheated: to prevent that steady state (since it's ugly), I have 3 dye injectors strategically placed, causing certain areas to get redder, greener, and bluer over time.
My luck on HN has been not so great. All in all, I think my posts have reached the front page ~5 times, only 1 of which I submitted. But oh well! Glad they get there somehow and people like them!
Webpack's algorithm for doing this is not black magic -- it has to consciously consider the same tradeoffs as were involved in this post. How many chunks should you have?
We're playing around with inline-styling our components, but pushing the inline-styles into CSS injected into `<style>` tags in the head. It's experimental at the moment, but it's being sent into production shortly: https://github.com/Khan/aphrodite
This is a hard generalization to make, but it's certainly true in the worst network condition case. Even if your client-side rendering happens instantaneously and your JS is (magically) 1kB, it's still 2 round trips before you can render anything instead of 1 (well, 4 instead of 3 for TCP connect, SSL handshake, HTML response). On poor mobile connections, a roundtrip will be 500ms+, so if you can render in less time than that on the server, it'll feel faster.
I've been looking for something like this forever! I loved AutoIt v3 on Windows, and osascript always felt super crippled in comparison (as well as impossible to look up documentation for). I've long since forgotten what I wanted to use this for, but I'll be sure to remember this for later!
It's a lot harder to reason about memory constraints on recursive programs.
The clearness and correctness of the code often ignores the possibility for stack overflow. Most naive implementations of DFS will hit the stack limit given trees that are all one long path from a single root to a single leaf.
We've done similar performance analysis at Khan Academy by using the navigation timing API and throwing the data into graphite. The most interesting part of this post for me is seeing that the numbers (server side times, median client times) are roughly the same as ours (http://i.imgur.com/wKglMTc.png)
One thing that I see in both GitHub's data and our data is this daily-periodic increase in both server and client times. Is that just load? We had theories that the clientside spikes may be caused by users in less CDN covered areas, or an increase in mobile usage, but were never fully satisfied by those explanations.
Can someone explain to me the migration path towards ES6 and syntax like this? This isn't syntactically valid ES5, so is there a reasonable path to making the browsers run ES6 directly?
If I just include it in a <script> tag directly, it'll throw syntax errors in any non-es6 compliant browser. So I'd have the transpile, and send down the es5 version of the code.
But if I'm transpiling, what's the point? I still have a build step, so why use ES6 over another compile-to-js language? The eventual promise, that years and years and years from now, all the non-es6 compliant browser will be dead, so I can send down the es6 code directly?
The difference here is that in Python vs C, you almost _never_ actually need to know what's going on under the hood[1]. Whereas in every framework I've _ever_ used, I eventually need to dig into the guts of them because of some leaky abstraction. For instance, automatic data bindings are great until you want to do animation[2].
I do agree that LOC for a _non trivial_ application is a reasonable measure, though I disagree that Angular:Backbone is Python:C.
[1]: Serious performance optimization is the exception here, but in building CRUD apps, this honestly did come up infrequently, and usually the right thing to do was to improve algorithmic complexity or fix slow DB queries, not fix python constructs that were unexpectedly slow.
[2]: I haven't spent much time with Angular specifically, but definitely remember this being difficult in other automatically bound frameworks, like Meteor in its initial release.
It's definitely totally fine to build these things for fun, but with a landing page like this, it seems like the author built it for some purpose beyond that, otherwise I don't see the point in presenting it in this form.
If the author wanted to learn _and_ get publicity, a blog post or at least including a "why" section that says "just for fun" on the landing page would seem suitable to me.
There probably is some interesting motivation for doing this, it's just not clear what it is.
The biggest value to me is being able to avoid the passing around of callbacks and them relying on varying conventions (some async are function(args, ..., callback(err, data)), some are function(args, ..., callback(data), errback(err)), some are function({success: callback, error: errback})).
Promises solve this problem by not passing around callbacks _at all_. Instead you return the promise and let the consumer attach the callback itself. And once we have promises widely available and part of the standard library, the calling conventions will be standardized too.
EDIT: I agree that as it stands, the lack of standardization of promises (jQuery's are mutable, for instance) is a pain, and that documentation could certainly be better.
I take a bit of offense of not being referred to as the "actual" Jamie Wong. More important in the context of the startup world, more prolific sure, but this seems needlessly dismissive.
1,000,000,000s of tons of CO2/year: how much we need to remove by 2050
We need to double our capacity every 21 months for the next 27 years