Without looking at the code, I thought the same thing until I read this comment for sure, and I'm not stupid all of the time.
Perhaps the library would benefit from not describing itself as 'smooth scrolling', which many of us might associate with 'hijacking the scroll wheel/trackpad'.
I got the point but planning logic about for these 50 lines of code takes much more time than just import this kind of small packages. For example redux-thunk is also about 10 lines but all redux community uses it when needed.
Is there a way to remove this library (like de-register its event handlers etc) once it has been activated somewhere on the page?
The reason I'm asking is that I've often ran into problems with similar no-dependency libraries in highly dynamic environment, that they often leave dangling event handlers on elements, that have been since removed from the page. That leads to various memory leaks and weird bugs.
Unfortunately not available for the moment. It just registers click event if It has a trigger. Yes you are right, It should be destructible. I will do that in a couple of days.
Please note that as pointed out in the Microsoft article fron a few days ago, any JS-based scrolling is subject to main-thread jank. Instead, you should try to use the scroll-behavior CSS property [1] or scrollToOptions [2] in browsers where it is available, and only fall back to JS if it is not.
Any scrolling on the main thread (i.e. driven by JS) is subject to jank, not just user-input scrolling. CSS-based smooth scrolling of anchor links can be offloaded to the compositor because the browser knows ahead of time what is going to happen, and in those cases the smooth scroll animation can run smoothly even if the main thread is bogged down.
It is a scroll hijacking library, it's just not as wretched as most. It's not animating the links but rather animating scrolling to the links by slowing the scrolling.
May I please take this opportunity to ask everyone to never ever consider forcing smooth scrolling upon the visitors of their websites.
Smooth scrolling is enabled by default in browsers and as a user I've therefor actively opted out of that behaviour because I genuinely dislike it and feel that it destroys my user experience. By forcing that experience on me I will have the same feelings towards your website.
On linux (Xubuntu 16.04/ATI card) smooth scrolling in both Firefox and Chrome causes horrible tearing even with sync to vblank on, The first thing I do on both is disable it and then increase the number of lines scrolled in FF, it's a much better experience then.
mousewheel.min_line_scroll_amount set to 30 (you might need to play with it)
If you use Chrome with the open ATI driver if you go in chrome:/flags you can force it to enable hardware acceleration via "
Override software rendering list" even if it's not on the (very cautious) whitelist.
To even get to chrome://flags I have to (on first run) do google-chrome --disable-gpu then change the flag then restart.
After that everything works flawlessly, it took me a while to track that one down!.
This has nothing to do with that though. This is "smooth scrolling" as in animating the transition to the anchor point, compared to just jumping straight to it.
What sucks is that every smooth-scroll implementation is just another copy of "the most popular one" - a simple S-curve, where it accelerates up to a point and then begins to slow down at the midpoint. If they were implemented with a 1/x curve, you'd get the immediate response from input, without that "slow and drunk" feel typical smooth scrolling delivers, in addition to a smooth animation.
Could someone explain why, you would choose to use something like this on your site? Every time I have experienced a site messing scroll presentation it has left me very frustrated.
Like in the demo, as long as you don't hijack native scrolling and just use it to do smooth jumps to anchors then it's fine. This library is a nice tool for anyone who doesn't want jQuery bloat on their site, but like animated transitions. Of course, there are plenty of designers who think it's a good idea to hijack scrolling...
1) It's intrusive and destroys the user experience which ironically is what it pretends to enhance.
2) Even if it feels right on the designer's machine, we never know what scrolling implementations there may be in the future that will certainly break such gimmicks.
very nice also the "scroll up" looks to be more resiliant to "mouse scroll wheel" interference while auto-scrolling, while "scroll up" behave a little differently at least on edge, i dont know why, anyway it is very beauty
Seriously though, the fact that this breaks the standard behavior of the anchor point becoming part of the URL bothers me more than the animation. When I hover over a link and see a URL, I'd really like clicking it to take me to that URL.
37 comments
[ 4.6 ms ] story [ 29.1 ms ] threadEDIT: I'm stupid this is isn't related to user input scroll, but anchor like scroll just smooth
edit: link to demo https://hsnaydd.github.io/moveTo/demo/ solid work imho
Perhaps the library would benefit from not describing itself as 'smooth scrolling', which many of us might associate with 'hijacking the scroll wheel/trackpad'.
This is basically a wrapper for the `move` function that is defined in 50 lines of code.
As a developer, I gain more by understanding those 50 lines of code than understanding how to import and call this.
The reason I'm asking is that I've often ran into problems with similar no-dependency libraries in highly dynamic environment, that they often leave dangling event handlers on elements, that have been since removed from the page. That leads to various memory leaks and weird bugs.
[1] https://developer.mozilla.org/en/docs/Web/CSS/scroll-behavio... [2] https://developer.mozilla.org/en-US/docs/Web/API/Element/scr...
Sigh.
Support[1] is still limited, but you can (and should) polyfill[2] it.
[0]: https://drafts.csswg.org/cssom-view/
[1]: http://caniuse.com/#feat=css-scroll-behavior
[2]: https://github.com/iamdustan/smoothscroll
Smooth scrolling is enabled by default in browsers and as a user I've therefor actively opted out of that behaviour because I genuinely dislike it and feel that it destroys my user experience. By forcing that experience on me I will have the same feelings towards your website.
To even get to chrome://flags I have to (on first run) do google-chrome --disable-gpu then change the flag then restart.
After that everything works flawlessly, it took me a while to track that one down!.
Most of the comments are -ve because they think it's about scroll jacking.
"A lightweight smooth scrolling javascript library ..."
to
"A lightweight scroll animation JS library ..."
1) It's intrusive and destroys the user experience which ironically is what it pretends to enhance.
2) Even if it feels right on the designer's machine, we never know what scrolling implementations there may be in the future that will certainly break such gimmicks.
Seriously though, the fact that this breaks the standard behavior of the anchor point becoming part of the URL bothers me more than the animation. When I hover over a link and see a URL, I'd really like clicking it to take me to that URL.