Thank you, I'm glad you like it! I try to find a good balance between form and function, and create a consistent environment for the customer. The homepage is definitely more "artistic" than the dashboard, for instance, but hopefully they clearly belong to the same brand and give you a similar look and feel.
(For the anecdote and because you mentioned it, it always annoyed me that we had a pretty different visual language at Stripe between the site and the dashboard. I designed Stripe's homepage but not its dashboard, whereas I did both at the same time for Increase. Consistency is really hard to achieve between multiple products as the optimal visual treatment is different for a site and an information-dense UI.)
In terms of performance, it outperforms all the animation libraries I’ve tried ( you can compare the stress test linked at the bottom of the page with this version made with GreenSock: http://animateplus.com/examples/stress-test/gsap/ ). In terms of weight and parse time, it’s also the fastest afaict. That being said, it’s not as powerful as GreenSock for example as it mainly focuses on performance and simplicity.
Spring physics, frame-based callbacks (see the `change()` examples), functions as values for duration, delay and any property you animate, making staggered animations easy to create, etc.
Safari isn't "lagging behind other browsers", it's just implementing different things. In fact, Safari is still the best browser when it comes to everything UI-related (animations, visual effects, …). You might disagree with Apple's priorities, but it doesn't mean other browsers are "better" per se, they're just different.
Safari's release cycle, however, is stupid per se.
It's actually an implementation issue and yes, I agree it's unfortunate. The problem is that the video is rotated in 3D in CSS (so we can reuse the same video without the fancy 3D effect on smaller displays since the page is vertically responsive) and unfortunately, the result varies depending on the browser (it looks much better on Safari, for example).
I find it interesting that, because some design decisions seem odd to you at first sight, you immediately conclude that the reason is a poor understanding of JavaScript. The `toArray` function, for example, is just performance optimization:
http://jsperf.com/toarray-slice-call-vs-loop
It's an IFFE (Immediately-Invoked Function Expression). The goal is to perform the feature test (the availability of Array.from in this case) just once instead of for every function call.
I guess I should clarify this example. I’m mostly fine with a global * { box-sizing: border-box; }, I’m only opposed to changing the box model randomly. The example illustrates a bad usage where changing the box model to get a full-width element is fundamentally wrong (since it’s the default behavior of block elements anyway).
Yup, I guess I should just be a bit less lazy and give a bit more context for each section :)
Some things are just personal preferences and some things are just completely subjective. Overall, though, these advices tend to make front-end code better. The JS part, for example, is largely based on functional programming best practices. Things like immutability, statelessness and the point about JS performance aren't subjective: they'll basically always improve your code's quality.
(For the anecdote and because you mentioned it, it always annoyed me that we had a pretty different visual language at Stripe between the site and the dashboard. I designed Stripe's homepage but not its dashboard, whereas I did both at the same time for Increase. Consistency is really hard to achieve between multiple products as the optimal visual treatment is different for a site and an information-dense UI.)