3 ms·

You might also want to look at Odometer: http://github.hubspot.com/odometer/docs/welcome/ http://github.hubspot.com/odometer/docs/welcome/

joliv 13y ago
Definitely a better choice. I've used it for a couple projects now, it's very mature. Not so sure about CountUp.js.
ianstormtaylor 13y ago
Wow, really nicely done on that landing page. Curious, why'd you make the API depend on a class name instead of assuming something more common like: odometer(el, 42);
- zackbloom 13y ago
  We've been having fun building things lately with transparent APIs. e.g. You drop Pace[1] in a page, and it figures out how to create a progress bar from it. Odometer is nifty in this way because you can still just set the value with innerHTML or .html, and it will animate it, so the overhead of adding it becomes just adding the class to whatever elements you'd like. You can actually also manually instantiate one pretty much exactly as you described: new Odometer({el: el, value: 42}); [1] - http://github.hubspot.com/pace/docs/welcome/ http://github.hubspot.com/pace/docs/welcome/
  - ianstormtaylor 13y ago
    Wow, Pace just blew my mind. You guys are releasing some really awesome stuff :) random other thing is would be sweet if these were component[1] friendly. (Dunno if you've already checked out component, but it is insanely good for front-end work.) One pattern I picked up from reading TJ's code is the transparent constructor... odometer(el).value(42); ...which I like using to make things that share a bit of state, but are still one-offs, a bit terser. (Coupled with avoiding options objects in general.) Achieved with the following: function Odometer (el) { if (!(this instanceof Odometer)) return new Odometer(el); ... } [1] https://github.com/component/component https://github.com/component/component
    - zackbloom 13y ago
      We try to include component.json files, but we don't use component, so it's usually left to a benevolent pull-requester. We've been using bower more and more, and liking that a lot, but it's essentially arbitrary. It's a bit annoying that npm, bower and component all require their own files to say essentially the same thing. I agree with wrapping the constructor function. Requiring the consumer to remember new adds one more tripping point for users. In this case, I suppose my thought was that the manual-creation path was such a small percentage of users that it wasn't a huge deal.

joliv 13y ago

Definitely a better choice. I've used it for a couple projects now, it's very mature. Not so sure about CountUp.js.

ianstormtaylor 13y ago

Wow, really nicely done on that landing page. Curious, why'd you make the API depend on a class name instead of assuming something more common like: odometer(el, 42);

zackbloom 13y ago
We've been having fun building things lately with transparent APIs. e.g. You drop Pace[1] in a page, and it figures out how to create a progress bar from it. Odometer is nifty in this way because you can still just set the value with innerHTML or .html, and it will animate it, so the overhead of adding it becomes just adding the class to whatever elements you'd like. You can actually also manually instantiate one pretty much exactly as you described: new Odometer({el: el, value: 42}); [1] - http://github.hubspot.com/pace/docs/welcome/ http://github.hubspot.com/pace/docs/welcome/
- ianstormtaylor 13y ago
  Wow, Pace just blew my mind. You guys are releasing some really awesome stuff :) random other thing is would be sweet if these were component[1] friendly. (Dunno if you've already checked out component, but it is insanely good for front-end work.) One pattern I picked up from reading TJ's code is the transparent constructor... odometer(el).value(42); ...which I like using to make things that share a bit of state, but are still one-offs, a bit terser. (Coupled with avoiding options objects in general.) Achieved with the following: function Odometer (el) { if (!(this instanceof Odometer)) return new Odometer(el); ... } [1] https://github.com/component/component https://github.com/component/component
  - zackbloom 13y ago
    We try to include component.json files, but we don't use component, so it's usually left to a benevolent pull-requester. We've been using bower more and more, and liking that a lot, but it's essentially arbitrary. It's a bit annoying that npm, bower and component all require their own files to say essentially the same thing. I agree with wrapping the constructor function. Requiring the consumer to remember new adds one more tripping point for users. In this case, I suppose my thought was that the manual-creation path was such a small percentage of users that it wasn't a huge deal.