Live data from Hacker News

Replacing jQuery (110kb) With UmbrellaJS (8kb)

bennadel.com

21–30 of 55 posts

Re: Replacing jQuery (110kb) With UmbrellaJS (8kb)

#21

Earlier quoted context omitted.

Cash's maintainer here. I don't think this is true actually. Zepto supports some methods that Cash doesn't, but you probably shouldn't use them to begin with, like $.ajax, $.isArray, $.fn.animate etc. In 2022 either better built-in solutions exist or better specialized tiny libraries exist. Everything that is supported by both Zepto and Cash should either work identically or Cash's implementation should be closer to…

Umbrella JS maintainer here (the library this HN thread is supposed to be about). At 2.8kb gzipped UmbrellaJS doesn't support partial builds because that'd be a bit funny. Also, and it seems to be something the author of the article likes a lot, Umbrella JS is closer to Javascript than the libraries you mention (& jQuery). Sure that means you need a bit of editing your code (which is made easy by being able to load b…

> the library this HN thread is supposed to be about

Articles can absolutely just be seeds for discussion, and I think the theme of replacing jQuery is quite relevant across the industry as motivators like "support IE" are increasingly falling away.

Re: Replacing jQuery (110kb) With UmbrellaJS (8kb)

#22
post #15

I generally replace jQuery with something like: $ = (s, p = document) => p.querySelector(s) $$ = (s, p = document) => p.querySelectorAll(s) If I’m feeling arrayish I’ll wrap the latter in [...qSA] so I can use .map and the rest of them, otherwise for/of works just as well. Anyone using $.animate() and $.ajax() this year should probably stop.

For some basic use cases that's probably good enough, but saying that that can replace jQuery is like saying that farts can replace rocket engines. For example I can do the following with jQuery: $(document).on ( 'click.ns', '.button', callback ); How should one do the same with vanilla JS? You'd end up rewriting a (probably buggy) reimplementation of jQuery's $.fn.on method in the end.

You use this library: https://www.npmjs.com/package/delegated-events

Re: Replacing jQuery (110kb) With UmbrellaJS (8kb)

#23
>Yes, "you may not need jQuery"; but, there's a lot of things in life that make life better even if you don't need them. It turns out, high-level, fluent APIs are one of those things.

I'm glad others are finally coming to this conclusion as well. I've been saying this for over a decade: jQuery success was not only cross browser compatibility. There were plenty of competing libraries at the time that offered it. jQuery won because of its powerful, composable and succinct API. Nothing has come close to it still for DOM manipulation.

And also: direct DOM manipulation is not evil, it just needs discipline, but so does programing in general.

Re: Replacing jQuery (110kb) With UmbrellaJS (8kb)

#25
post #6

So my project for this week has been removing jQuery from my app. I have to say it's been surprisingly easy. The only thing that's been annoying is that jQuery ignores the difference between querySelector and querySelectorAll, and just treats any operation done on a jQuery selection as if it were mapping a function to each item in a list. Which makes it super easy to write, but makes it much more difficult to know wh…

The way jQuery queries single or multiple elements was my favourite feature. Find xyz class and do something with it, I don’t care if there’s one instance or one thousand.

Re: Replacing jQuery (110kb) With UmbrellaJS (8kb)

#26
post #5

I prefer `querySelector` and bare ` ` tags for quick and dirty jQuery replacement. If you haven't keeping up with all the new script-tag parameters, I suggest looking at this: https://gist.github.com/jakub-g/385ee6b41085303a53ad92c7c8af... Choosing type=module is usually better choice than classic script tags like in the article. Module tags fetches (if any modules is used) asynchronously, and executes after the pars…

Here you'll want to use the "module/nomodule" trick. (Forgive the formatting / mangled HTML)

script type="module" src="module.js"

script nomodule src="nomodule.js"

Re: Replacing jQuery (110kb) With UmbrellaJS (8kb)

#27
post #25
post #6

So my project for this week has been removing jQuery from my app. I have to say it's been surprisingly easy. The only thing that's been annoying is that jQuery ignores the difference between querySelector and querySelectorAll, and just treats any operation done on a jQuery selection as if it were mapping a function to each item in a list. Which makes it super easy to write, but makes it much more difficult to know wh…

The way jQuery queries single or multiple elements was my favourite feature. Find xyz class and do something with it, I don’t care if there’s one instance or one thousand.

Yeah, the problem is just that later it makes it harder to go back and find code that's no longer working properly, dead code, and unused CSS. The fact that vanilla JS will throw an error when you try to perform an element operation on null is actually quite useful.

Re: Replacing jQuery (110kb) With UmbrellaJS (8kb)

#28
post #5

I prefer `querySelector` and bare ` ` tags for quick and dirty jQuery replacement. If you haven't keeping up with all the new script-tag parameters, I suggest looking at this: https://gist.github.com/jakub-g/385ee6b41085303a53ad92c7c8af... Choosing type=module is usually better choice than classic script tags like in the article. Module tags fetches (if any modules is used) asynchronously, and executes after the pars…

That's what I did! I saw a lot of people recommending doing basically: const $ = sel => [...document.querySelectorAll(sel)]; But then you get to it and are adding a lot of classes, so you might add a couple of helper methods: const addClass = (col, cls) => col.forEach(el => el.classList.add(cls)); const removeClass = (col, cls) => col.forEach(el => el.classList.remove(cls)); addClass($('ul li'), 'list-item'); Oh and…

Behold my jQuery replacement:

    export function each(qs, cb) {
      if (typeof qs === "string") {
        qs = document.querySelectorAll(qs);
      }
      if (!qs) {
        return;
      }
      if (qs.length === undefined) {
        qs = [qs];
      }
      for (var i = 0; i  {
        el.addEventListener(ev, cb);
        cancelFns.push(() => {
          el.removeEventListener(ev, cb);
        });
      });
      return () => {
        cancelFns.forEach((fn) => {
          fn();
        });
      };
    }

Re: Replacing jQuery (110kb) With UmbrellaJS (8kb)

#29
post #5

I prefer `querySelector` and bare ` ` tags for quick and dirty jQuery replacement. If you haven't keeping up with all the new script-tag parameters, I suggest looking at this: https://gist.github.com/jakub-g/385ee6b41085303a53ad92c7c8af... Choosing type=module is usually better choice than classic script tags like in the article. Module tags fetches (if any modules is used) asynchronously, and executes after the pars…

Here you'll want to use the "module/nomodule" trick. (Forgive the formatting / mangled HTML) script type="module" src="module.js" script nomodule src="nomodule.js"

Most people should not use nomodule. If you have code, but you never test it, it is almost certainly broken. If you actually do test your code in IE11, okay great, use nomodule, but what I mostly see are pages that don't actually work in IE11 because the polyfils don't quite add up, but the devs have no idea because it isn't QA tested. It's just a waste of time for everyone.

Re: Replacing jQuery (110kb) With UmbrellaJS (8kb)

#30
post #9
post #5

I prefer `querySelector` and bare ` ` tags for quick and dirty jQuery replacement. If you haven't keeping up with all the new script-tag parameters, I suggest looking at this: https://gist.github.com/jakub-g/385ee6b41085303a53ad92c7c8af... Choosing type=module is usually better choice than classic script tags like in the article. Module tags fetches (if any modules is used) asynchronously, and executes after the pars…

The author mentions that enforces CORS restrictions which would break with their current server settings and CDN, otherwise I think they agree with you.

This aspect of JS makes no sense to me. Why add a CORS restriction to modules mode? It doesn't plausibly address any security hole, since nomodules mode is still around. It's just a big pain in the ass for no particular benefit, AFAICT.
Post reply on HN