Hacker News Reader

Comment by TheRealPomax | Hacker News Reader

The first example is already bizarre: use CSS and a transition listener on the JS side, why would you still implement it with a 1998 onclick, and a setTimeout? This isn't modern "vanilla JS", this is "ancient nonsense" =/

Add a CSS class "hide-animated" tied to your transition, add a transition end listener on the document (not once, perpemtual), with evt => evt.target.remove()

(That's right, ".remove()", not "element.parentNode.removeChild(element)". Actually looking up modern JS is a good idea if you're going to knock it).

And then the only other JS thing you need for your element is a click listener that adds "classList.add(`hide-animated`)".

Is "addEventListener(`click`, evt => evt.target.remove())" overly verbose and cumbersome? Sure is, I have no love for it, but if you want to show that your library is better than vanilla JS, show vanilla JS, not code from 20 years ago.

View on HN

I would love a pull request with improvements.

I'd like to be as fair as possible in these comparisons.

Wait, you're looking for people to do the work you claim you did?

For htmx I have to stay in es5 to preserve IE11 compatibility, so there are modern features in the language I don't use on a regular basis. I appreciate any help from people who are better at the language, but of course understand if people aren't interested.

Thanks for commenting! I just did a pass over the vanilla JS examples addressing some of these issues.

Wrt. transitions:

> use CSS and a transition listener on the JS side

Now you need to have 3 files open in your editor simply to be able to say "this button fades away in half a second when clicked". The onclick is used to somewhat alleviate this (See "Locality of Behavior" [1]).

Separation of concerns is important, but different applications have different definitions of what constitutes a "concern". If one expects that the hiding animation will be changed by designers, one would likely use CSS as you suggested. The nice thing about `settle` in hyperscript (as opposed to just listening for a transitionend) is that you can switch from a transition to a keyframe animation and it will still work with no changes.

> add a transition end listener on the document

Wouldn't this also detect non-disappearing transitions (say, an element expanding or changing color)?

[1]: https://htmx.org/essays/locality-of-behaviour/

> Now you need to have 3 files open in your editor

Are you saying that isn't already the case? Do you inline all your CSS and JS directly? Because that'd be super weird.

> Wouldn't this also detect non-disappearing transitions (say, an element expanding or changing color)?

The event comes with information about which class the transition was for. So: sure, but if you have lots of different transitions we're no longer dealing with simple code that we can write simple "vanilla vs. jquery vs. your lib" code for?

Do you push arrow functions to production? IE still accounts for 2.5% [0] of browser share and has no support [1] for them.

My guess is that most of us have Babel in the mix of a production deployment, in which case I think the “20 year old code isn’t vanilla” loses some of it’s effect.

0: https://www.statista.com/statistics/272697/market-share-desk...

1: https://www.caniuse.com/arrow-functions

I don't think that 2.5% number is true. I can't click thru that paywall without signing up, but for example you rown caniuse link suggests 0.99% and this [0] suggests 0.73%

[0]: https://gs.statcounter.com/browser-market-share

Whether you use babel or not is irrelevant: you'll be running it at the end of your build chain, while writing modern JS.

But yeah, I absolutely push modern JS out to prod, because our demongraphic is very much nowhere near 2.5% - our actual number for IE users is 0.4%, for all versions of IE combined (just IE11 would be 0.2%). Even Samsung's browser ("Samsung has a browser?") drives four times as much traffic as all version of IE combined.

IE use has properly died down ever since Microsoft themselves started making sure folks weren't using it anymore. And they really don't want you to use internet explorer: Windows hasn't had IE set as default browser for years now. It comes bundled with Windows 10, sure, and IE11's EOL is contractually tied to the Windows 10 EOL, sure, but Microsoft is working damn hard to make sure you're on Edge instead.

If you have to support IE, because you have a target demographic that for whatever reason is forced into IE use, then sure: roll whatever code you need. But if you're developing for the current web landscape: no, IE is not your concern anymore.

Reply on news.ycombinator.com