benjamindc

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

Thank you, means a lot :)

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.

All the examples use the untranspiled version which is comptabile with the browsers listed here: https://github.com/bendc/animateplus#browser-support

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.

Cfr. https://github.com/bendc/animateplus#browser-support

Yup, you're right!

Glad you noticed the easter-egg on the logo :p

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.

Facebook Pop :)

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've actually created an animation library based on my work for this page: https://github.com/bendc/animateplus

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

You're wrong, the HTML is valid.

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.

https://stripe.com/bitcoin runs actually super smoothly for me on Firefox 35.

Thanks! I might actually write a "behind the scenes" post, assuming I find the motivation to do it :p

Thank you, means a lot :)

I'm just using a tiny lib that makes things easier: https://github.com/bendc/animate Other than that, it's just vanilla js/css.

By computing values I meant defining styles based on runtime variables (browser size, localStorage data, …). CSS pre-processors can't do that.

In case you're interested in learning more about the motivation behind creating uilang, I wrote a little piece on Medium: https://medium.com/@bdc/the-educational-side-of-uilang-92d39...

If these things are easy for you, then you're probably not uilang's target audience ;)

So, the technical part isn’t that crazy tbh — as soon as you respect some pretty straightforward principles you should be fine (animate only transform/opacity, favour requestAnimationFrame over setInterval, transitionend/animationend events over setTimeout, …). The complicated part was mostly the “creative” process, ie. how fast should the animation run (some people read, others don’t), what's the appropriate bezier-curve, how make the play button “engaging” enough so people don’t feel like they’re gonna watch a billion-hour screencast, etc.

The code has been specifically made for that particular animation and, to be fair, it wasn’t even modular enough for my own needs :D Joking aside, I’d love to blog about it and more generally about animations in UIs.

The canvas element is only used on Chrome as it has a hard time rendering animations above a big CSS radial-gradient. The whole animation is just using DOM elements, CSS transitions/animations and requestAnimationFrame. And yes, entirely handmade :)