Live data from Hacker News

CountUp.js

inorganik.github.io

11–19 of 19 posts

Re: CountUp.js

#11
Why would you set `user-scalable=no` but not re-flow for tablets? I really wish Safari would provide an override for these incorrect viewport declarations.

Re: CountUp.js

#12

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

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

Re: CountUp.js

#13

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

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

Re: CountUp.js

#14

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

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

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/

Re: CountUp.js

#15

Earlier quoted context omitted.

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

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 pre…

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

Re: CountUp.js

#16

Earlier quoted context omitted.

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 pre…

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…

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.

Re: CountUp.js

#17
doesn't work at all on browsers without requestAnimationFrame support (e.g. Opera 12). I guess that that's fine, but then better display the final number instead of 0.

Re: CountUp.js

#19
Thanks to the open-source community, a bunch of improvements and fixes have been made on this:

- merged @lifthrasiir's PR. - counts in both directions - easing optional - supports IE8 - optional callback on animation complete - coffeescript and minified versions available

Post reply on HN