Live data from Hacker News

Vanilla JS, fast, lightweight, cross-platform framework

vanilla-js.com

131–134 of 134 posts

Re: Vanilla JS, fast, lightweight, cross-platform framework

#131
post #45

Earlier quoted context omitted.

Also in the native version, you know you're only doing the work required. The jquery one will be doing a lot of extra useless inefficient grunt work to achieve nothing. Making it incredibly slow in comparison.

Premature optimization, and all that. It is trivial to get raw dom nodes out of jQuery, so you can easily use jQuery to begin with and replace any code with the full DOM API calls should it every become a performance issue. This discussion is a bit like how assembly programmers used to defend not moving to a high level language long after the performance benefits were not worth it any more.

> It is trivial to get raw dom nodes out of jQuery, so you can easily use jQuery to begin with and replace any code with the full DOM API calls should it every become a performance issue.

That's still going to be a lot of work if the performance issues turn out to be many separate jQuery calls spread all over your code, which is not unlikely.

Re: Vanilla JS, fast, lightweight, cross-platform framework

#132
post #46
post #27

Earlier quoted context omitted.

Nope: TypeError: document.getElementsByTagName("p").filter is not a function Because you don't get an array, only something array-like.

And this discussion over how to write a trivial loop is why I stay far away from vanilla js unless performance absolutely forces me to optimize.

This is why I program with a code editor / interactive console that tells me these things as I'm typing :-)

Re: Vanilla JS, fast, lightweight, cross-platform framework

#134

Earlier quoted context omitted.

It doesn't take up any more bandwidth if you're properly concatenating your JS.

Uh, no. I think you misunderstand me.

You're right. That was fairly nonsenical. Not sure what I meant, perhaps I read your comment as referring to requests.

Either way, long-term caching of such shims means the bandwidth to load polyfills only has to be expended once per client. And an extra Mb of bandwidth once per year is a pretty reasonable thing to do for particularly older browsers if it makes your development more sane.

Post reply on HN