Native Javascript alternatives to jQuery methods | Hacker News Reader

Native Javascript alternatives to jQuery methods

github.com

146 pointsEGreg68 comments

As the maintainer of cash [0] I wouldn't recommend using these functions for almost anything, they aren't really alternatives for jQuery as they provide a very different API, just to give one example the proposed alternative for `$.fn.css`:

- Doesn't automatically camel-case the property name.

- Doesn't automatically vendor-prefix properties if needed.

- Doesn't support getting/setting CSS variables.

- Doesn't automatically add the `px` suffix to numeric values when appropriate.

- Doesn't fail gracefully when dealing with non-element nodes (`node.nodeType !== 1`).

IMHO there are too many details that you now have to think about when using such "native alternatives" that's not worth it. From my very unbiased opinion I think it makes more sense to just use cash, which only needs ~5kb when minified and gzipped, and can be even partially compiled to remove the stuff you don't need.

[0] https://github.com/kenwheeler/cash

> From my very biased opinion

Fixed that for you. There are better ways to integrate with the DOM than jQuery nowadays. It’s not a good fit unless you’re just trying to tack on a dropdown menu onto a decade old Wordpress theme, IMO.

I'd say it's the opposite. These no-jQuery methods are good if you are "just trying to tack on a dropdown menu onto a decade old Wordpress theme", however if you want to manipulate DOM in a more complex manner and do not wish to pull in an entire frontend rendering library, then jQuery is perfectly fine.

You will have/want to factorise these methods anyways because some of them are just ridiculously long. jQuery has already done that and at least it is very consistent.

Can you please edit snarky swipes out of your comments here? This post would be just fine with just the last two sentences.

https://news.ycombinator.com/newsguidelines.html

I actually meant "very biased", not "very unbiased"! Apologies, obviously I have some strong opinions on this since I maintain cash.

I agree. I glanced through the list and noticed a couple problems myself too. Their `replaceWith` doesn't provide the functionality that jQuery offers -- it doesn't take into account event handlers bound to DOM elements. Also, their `extend` does a shallow merge, not a deep merge.

I don't particularly understand the rush to rip jQuery out of everything. It seems like a lot of people are doing it just because it's the trending thing to do. There are some things that jQuery does very well -- even in today's world where modern web dev is dominated by SPA components.

I'm the maintainer of https://github.com/elliotnb/observable-slim and https://github.com/elliotnb/nimbly -- the latter of which is an SPA component framework whose core requires jQuery. It uses jQuery to update DOM nodes with `replaceWith`, merge deeply nested objects with `extend`, among other things. Nimbly components are not required to use jQuery -- only the framework core uses it. Aside from the eliminating the extra 69KB footprint from adding jQuery 3.1.1 slim min, I don't see any reason to rush to rip jQuery out of the Nimbly core. On the contrary, using jQuery helped us get the framework built faster and helped us keep the code expressive and easy-to-follow.

They’re often not exactly equivalent, but I don’t think that all of your points are reasonable.

• Camel-casing the property name: I can do that myself readily enough; remember this lets you deal in direct property access, so we’re talking things like `styles.backgroundColor` rather than what would otherwise be `.css('backgroundColor')`, where using the kebab-case is nicer. (I would issue one caution: the kebab-case `float` becomes the camel-case `cssFloat` because `float` was a reserved word; this is a little like how for becomes htmlFor and class className.)

• Vendor-prefixing properties: in the library we use for FastMail, we used to have vendor prefixing; but when we dropped support for IE<11 and other ancient browsers recently I steadily whittled that down until there was only one item left, and so I decided to just special-case that one item. Vendor-prefixing is basically a thing of the past; the only one that I found to still be relevant is `user-select`.

• CSS variables: fair, but using `.setProperty('--foo', value)` and `.getPropertyValue('--foo')` is not onerous in those situations where you need to refer to a custom property.

• Adding `px` suffix to numeric values when appropriate: I don’t actually want that. I’d much prefer it to throw an error if I tried to assign a number to something that wants a dimension, but that is unfortunately not possible; yet it’s likely that any incorrect code that I write will not work, and so I’ll notice. If I really am working in pixels, I prefer to do so deliberately.

• Non-element nodes: why on earth would I want it to fail gracefully? I want it to throw an exception, because I evidently did the wrong thing. Also, if using a more strongly typed language such as TypeScript, this pretty much becomes a non-issue.

Things like $.fn.css are completely generic, taking a single object and needing to act on it—and so most of these features make sense there. But in the concrete situations where you use such functions, you can reasonably do things like call different functions, instead of just passing one object; and I think that there, most of them are instead either misfeatures or not of value any more due to better browsers and possibly TypeScript.

I like efficiency, and I like correctness; for that reason, I like the fact that the native methods don’t do most fo these things automatically. I don’t want to inefficiently do most of those things.

> • Camel-casing the property name: I can do that myself readily enough;

Sure, but now you have to think about this, which makes those functions a bit less of a replacement for jQuery.

> • Vendor-prefixing properties: in the library we use for FastMail, we used to have vendor prefixing; but when we dropped support for IE<11

> Vendor-prefixing is basically a thing of the past; the only one that I found to still be relevant is `user-select`.

I think you still have to prefix the appearance [0] property too, I would guess probably a few more as well, as I think browsers sometimes implement a vendor-prefixed property before the implementation is stable enough, so I guess if you want to use something particularly new you might need to vendor-prefix it.

My point is that with jQuery you don't have to think about all this.

> • CSS variables: fair, but using `.setProperty('--foo', value)` and `.getPropertyValue('--foo')` is not onerous in those situations where you need to refer to a custom property.

Right, but now you have to remember to use different functions. If you want to abstract this away in a separate `css` function you'll find yourself basically reimplementing what jQuery or cash does (ensuring it works, it's performant etc.), perhaps it might have been better to spend that time improving your product instead.

> • Adding `px` suffix to numeric values when appropriate: I don’t actually want that.

> • Non-element nodes: why on earth would I want it to fail gracefully? I want it to throw an exception, because I evidently did the wrong thing.

Fair enough, but that's what jQuery does, maybe you want something else, maybe not something I would call a "jQuery alternative" in this context.

> I like efficiency, and I like correctness; for that reason, I like the fact that the native methods don’t do most fo these things automatically. I don’t want to inefficiently do most of those things.

I'm pretty sure the bottleneck of your app will basically never be the check for css variables or something like that. And the time spent to reimplement all/some of these functions might be better spent improving the app instead, to me this argument feels like saying: I like efficiency, I only write my apps in C, you can absolutely do that but by the time you reach a MVP I would have probably made a much better overall and maybe even more performance JS app, since while you'd be thinking about managing memory and all that I would have surely spent more time thinking about algorithmic improvements and performance optimization in general.

[0] https://developer.mozilla.org/en-US/docs/Web/CSS/appearance

I didn’t think about appearance. But I wouldn’t actually count that one specifically, due to major cross-browser inconsistency, and the fact that -webkit-appearance is the form that all the browsers are now implementing—yes, under that name. (And the fancier parts of -moz-appearance are steadily being dismantled.) It’s the sort of thing that you write carefully in static CSS, rather than interacting with it in JavaScript. So to be absolutely clear: I would consider naive auto-prefixing of `appearance` to be very undesirable.

No new properties are being prefixed; that technique is dead, and the only things prefixed are so for historical reasons.

I have to fully agree with chrismorgan here—to echo his breakdown of your points, it mostly comes down to strictness and explicitness.

With the exception of CSS var getters/setters (for which there are distinct getters/setters), all of your points champion things being done "automatically", by "magic", "loosely", rather than being strict.

To reword:

- Doesn't arbitrarily transform property names - Doesn't add extranous properties - Doesn't magically convert integers to strings - Doesn't silently hide logic errors on invalid nodeTypes

This comes down to an essential philosophical difference, whereby the jQuery APIs favours automatic value transformations so devs don't need to understand the specific types of values being passed.

I only made one example, another one might be `classList.add`, jQuery's `$.fn.addClass` accepts a string which may contain multiple space-separated classes, while the "native" version accepts multiple string arguments. That's a very different interface.

> - Doesn't arbitrarily transform property names

Ok, would you then prefer to reimplement the vendor-prefixing logic on your own or just not support browsers that only support the vendor-prefixed version of a property?

I can see your point, and in some ways I agree with that "philosophy", but my point was that I wouldn't personally call these functions "jQuery alternative" in this context, as the 2 are pretty different beasts.

It's worded as "alternatives", not "equivalents", so API parity isn't a requirement.

The fact that `classList.add` has a different interface to `$.fn.addClass` isn't really a big deal—this would be the case with most migrations from one API to another without matching interfaces. The question is of internal functionality—the only thing jQuery "adds" here is being lenient about the param type accepted.

Yep and that 2.1 CSS Get style example is EXACTLY why I use jQuery

https://github.com/nefe/You-Dont-Need-jQuery#2.1

I don't want to have to figure out that there is a "known bug and will return 'auto' if style value is 'auto'". jQuery takes care of that crap for me.

Say what you want about jQuery, but it just works.

Plus it looks cleaner and easier to extend in the future.

I always find it funny that links like “you don’t need jQuery” seem like jQuery advertisement to me.

The jQuery examples are always cleaner, shorter, more intuitive.

And cross-browser.

Yes, they're effectively the same, but one is slightly more ergonomic, and the other saves you 30KB (which isn't much, in my opinion) and the pain of managing yet another dependency.

Its only 30k until your project gets large enough that the jquery terseness makes up the difference.

It's such a weird world. If jQuery was new, people would be all over it for its nice syntax. But since it's old people say we should get rid of it.

I think there’s also a factor of doing so much which has now been standardized in browsers: imagine a hypothetical jQuery 4 which mostly focused on DOM/CSS compatibility and used native ES6 where possible, always using the standard names and signatures for things which are only partially supported. I think that’d help people focus on the more ergonomic parts rather than whether you type each or forEach.

When I look at the examples and seeing how verbose some of the natives examples are I would probably end up writing something similar to jQuery to keep the main code simple. Maybe that's the way to go.

That's what I was thinking — imagine if you started now with things like the ES6 array & NodeList methods, etc. as the model to follow and built the same convenience methods without needing to deal with horrors like the IE6 DOM. $(foo).css("color") would still be useful but you might end up with $(".foo").forEach(…), $(foo).classList.add("foobar") or $.fetch(…) to reduce the number of new nouns and verbs a developer needs to remember.

The world is indeed strange. I remember the dark days of getting a robust client-side UI, complete with AJAX, drag and drop operations, etc. working properly in both IE and Netscape. jQuery seemed too good to be true when it first came out.

I get that I don't need Jquery and that I can do DOM stuff myself. However. JQuery makes DOM stuff a lot easier to remember and perform.

I think I'll always be prototyping in Jquery.

Large stuff we built in React, Redux etc... But if you need a quick tool or prototype, just adding a single <script> tag to get JQuery from a CDN and you're ready to go. Nothing is going to beat that, right?

Also the huge benefit of letting someone maintain the API for whatever browsers support natively today.

For my own projects I’ve actually found it easier to start with Vue immediately, even for a prototype.

If I have to do any DOM manipulation outside of perhaps hiding or showing an element based on a button press, I typically find it far more unwieldy to do all that stuff with jQuery than just scaffolding out a quick Vue component.

Plus, there is a build available with a runtime template compiler, so you can just pull that in via a CDN and prototype without needing a build step.

Obviously, it varies a lot based on the sort of things you build, but I’ve found it to have sped up my prototyping process enormously.

You can still put in a script tag and start using vue.

You can't use components this way though, unfortunately.

I like Vue, never really jumped into react, but I hate using npm and all of the javascript build tools.. I end up fighting with them for a while and decide it's back to jQuery and simplicity. Always works.

For one project I worked on, I used a combination of Jquery and HandleBarsJs. It was a great combination and pretty clean. I attached events to the rendered template items, then changed the datamodel as appropriate and rerendered the template.

I didn’t (and still don’t) know any of the $cool_kids front end frameworks. But it couldn’t have been a SPA anyway. Each of the pages were created by a CMS that ran on the web and in a native mobile app that had to be able to work offline.

I think people mistake this as an attempt to tell people to get rid of jQuery. No, that's not the point of these webpages. jQuery still offers an overall nicer API than native. If you're building an application, and have to make the choice between using jQuery and going native, go pick jQuery.

However if you're writing a 10 line script that does something really small (eg. if you have a static webpage and need to make one button slightly interactive) then these guides tell you how to do it without importing all of jQuery.

Of course you might also be adding that hack to a page that already pulls in jQuery, in which case why avoid it?

The native alternatives all seem longer. I'll keep jQuery, thanks.

(Maybe they should put some of its functionality into the JaveScript standard?)

your choice adds a small convenience for you while increasing the payload size and runtime overhead for how many of your users? as an alternative you could make a very small set of wrapper functions to shorten things without taking on the entire jquery lib.

If you reinvent a wheel you need to maintain that wheel. That is your customer's money. Money which can be put in features instead of striving to technical excellence.

Instead, you now put money and time in building a wheel for very little benefit (if you can feel the performance of jQuery, you're doing to much DOM operations and you probably wouldn't benefit much from stripping it out).

Some projects are not meant to last long-term, and jQuery would work just fine. Even if it is old fashioned.

Regarding the payload size argument: If you’re pulling jQuery in from one of the popular CDNs (which you should be), your clients will almost certainly already have it cached locally anyway.

Can you elaborate on the runtime overhead issue? If you write your own JS functions to replace jQuery, you’re still adding runtime overhead... and jQuery likely wrote a more efficient implementation to begin with; jQuery is battle tested and one of the most widely used pieces of software in history, what makes you think your code will have less runtime overhead?

> If you’re pulling jQuery in from one of the popular CDNs (which you should be), your clients will almost certainly already have it cached locally anyway.

Have you ever measured this on a large scale? I’ve never found it to be true because there are many CDNs, versions, and browser caches are not infinite. If performance is a priority it’s almost always faster to serve it directly to avoid things like the DNS and TLS latency from those CDN connections.

Plus, I don't think a lot of the engineers on HN are actually even working on first page optimizations. If you are building an application that people are logging in to and using on a regular basis, you can afford a little bit of first load overhead which will then most definitely stay cached for the remainder of the session.

All this talk of trying to skim off a few kb of load time only applies to extreme edge cases of landing pages with flighty potential customers.

Yes, it’s an oddly specific focus given how few sites have been optimized to the degree that a single cache-friendly resource matters. Given how many sites I run into where a single failure means that functionality breaks entirely, I really think it should be down the list.

A whole 28KB that's probably cached anyway?

And your suggestion is write your own custom wrappers to avoid overhead? So you or someone else can learn all your custom things.

No to all of that. Get off the "too cool for Dad" train and just use jQuery if you already know it and it fits for what you are doing. If something else is better, (including native), use that.

You will end up re-implementing half of jQuery anyway because DOM APIs are just so bad.

Greenspun's tenth rule for the web?

If 30k is an issue removing your css framework and going barebones might give you more bang for your buck.

Aka, reinvent jQuery probably sub optimally and with less cross browser testing. Use jQuery from a CDN and you should have solved the issue of download size/speed. Also the native versions will be longer so it will increase your code size too.

You don't need a lot of other stuff as well, but it might come in handy. Looking through their examples I'd much prefer someone used jQuery instead of writing a bugged getNextSiblings function themselves.

Also, jQuery is self-contained, doesn't shove numerous other packages into node_modules.

> Also, jQuery is self-contained, doesn't shove numerous other packages into node_modules.

Totally a bonus. Had to deal with npm audit and it warned about breaking changes and security problems. So I did npm audit --force. npm had a "I sure hope you know what you are doing" message. That's not very comforting >___>.

Seems like a great reason from me to keep using jQuery. It's not as if I was eschewing React and such, to write SPAs with jQuery.

jQuery is a utility that abstract/hides away all the hideousness that is JavaScript and its prototypes-based nature. And it does its jobs well, plus it has universal support.

Above all -- "work smarter, not harder".

Replacing jQuery with these methods seems like a great opportunity for learners to improve their understanding of javascript. Also, with ES6 javascript, there seems to be less need for jQuery.

I think this is a good point of view on the topic, and personally resonates with me. I ditched jQuery at the same time I read “JavaScript: The Good Parts” and after that I realized I was never conceptually building systems, only little puddles of functionality, when I used jQuery for FED.

jQuery exists for a reason. It gives you portability across browsers and versions, and is generally quite a convenient library to use. If you're not using it for animation, it's also pretty fast. I personally love it, and don't intend to stop using it any time soon (combined with a bit of lodash)!

Well, these days, native JavaScript is pretty portable, so portability across browsers and versions isn’t really a big selling point for jQuery any more (you’re not support IE 6, are you?), but looking at the samples in the link, the brevity of jQuery is impossible to ignore.

> the brevity of jQuery is impossible to ignore.

Really makes you think the DOM is needlessly complex and verbose.

Why have browser makers not simply begun to include cached versions of popular sites, by their hash? Like a “resource store” similar to an “app store”. They have the mechanism: SRIs. It’s not like we NEED to store cookies on CDNs or whatever.

You get 90% of the benefit with just the browser cache and CDN-hosted copies.

Not unless the CDN is a centralized one for many sites.

Mandatory reference to the April Fools of Vanilla JS, the framework that does it all: http://vanilla-js.com/

I feel like a cargo programmer because I’ve been using jQuery for 8 years, I have learnt the vanilla JS methods, and it seems jQuery is falling out of fashion. Is it a mistake, or is still popular enough that I will be able to use it with every employer?

You are two years ahead of the rise of jquery again. It fits so well with the idea of not writing a custom 6 line function over a simply function chained.

Can't all these fancy Javascript compilers and optimizers just inline and constant-fold these query to their in-browser counterparts?