Hacker News Reader

Comment by lacosaes0 | Hacker News Reader

If you're not targeting old browsers there's no reason to use JQuery. Plain JavaScript offers you the same features.

Sure, if you want to build it all yourself in JavaScript, but that's the point of a library isn't it?

And as far as "not targeting old browsers" there are plenty of places where modern browsers differ and jQuery normalizes their behavior. Chrome doesn't support mouseenter, Firefox doesn't support focusin, Safari's String.trim() doesn't trim zero-width spaces, their CSS uses prefixed properties, etc.

Also, talking about jQuery in isolation is like talking about C++ without its runtime library. One of the strengths of jQuery is its ecosystem such as plugins.

I'm certainly not a jQuery fanboy, but jQuery's DOM-manipulation functions are certainly more concise and abstract away some of the funky internals (NodeLists, etc.).

That said, I've always found jQuery's function naming to be particularly ambiguous. There's no indication that "find" searches an element's descendants for a matching CSS selector based on its name. On the other hand, vanilla JS's element.getElementsByTagName is so much more verbose. Back in the day I found PrototypeJS [0] to be much better organized and offer the same feature set, but it's largely fallen out of use since Rails dropped it. mootools is nice but the docs, while comprehensive, are arranged in no logical order. Every time I try to pick up mootools I end up running around the docs in circles.

tl;dr jQuery is overblown but I think there's room for improvement over vanilla JS.

Plus there's always the (literally) hundreds of plugins for every possible application of jQuery.

[0] http://prototypejs.org

I actually like long verbose names. Unfortunately, plain JS names are often long, verbose and unclear, so that's not a win. (e.g. document.querySelectorAll - that should have made some reference to css; and "all" should be implicit as it is the norm in CSS).

I'd love to see a JS library that doesn't try to add a lot of functionality, but only decruftify the browser API.

The right aim would be to end up with a complete API that might actually replace the normal JS api (DOM+otherwise) in actual browsers.

What do you think of Zepto?

It's not necessarily a bad thing that DOM-manipulation functions are a bit annoying to type. Verbose names means that you are more likely to do:

    var elem = document.getElementsByClassName('foo')[0];
    elem.fooBar();
    elem.foo = 'bar';

rather than

    $('.foo').fooBar();
    $('.foo').foo = 'bar';

even if you don't know anything about writing optimized JavaScript code.

But sadly, beginners these days learn "jQuery" before they learn JavaScript.

This is a little bit silly. I agree if you're not beholden to support old versions of IE then there may be some overhead in full jQuery, so it's worth pointing out there some lightweight alternatives that have a similar API, e.g.

* http://zeptojs.com/

* https://github.com/mythz/jquip

Zepto doesn’t support any version of IE.

If by "features" you mean the ability to achieve the same result... Well, obviously.

However, jQuery's main feature is having a nice interface that is much more consistent and usable than many of the native APIs. The "fluent interface" or "method chaining" style is especially nice.

Sometimes the API is more convenient. Also, it's so widely used that it's often easier to find samples and documentation on how to do something with jquery than it is without using jquery, even where the plain javascript solution isn't really that much more complex.

A modern, more minimalist alternative would be a nice thing, but at the moment I think jQuery is probably still a good bet for simple cases.

If you think you can write a better wrapper than jQuery, you are most likely wrong.

I'm still finding that JQuery makes for much more concise and readable code, especially for chaining operations on groups of elements or xhr.

Technically, even if you are targeting old browsers, you don't need jQuery; it's written in Javascript, after all. There's nothing they do that you can't do with vanilla JS.

You can also mow your lawn with a pair of scissors, which is about like doing anything non-trivial in the browser without jQuery.

Sort of agree but instead of "old browsers" I'd say "multiple browsers" which is ...actually that's a big difference. For me, the moment I have to look at anything more than one browser on one platform, then jQuery becomes a valid choice. Which is pretty much all the time lately.

Even if DOM normalization isn't needed, the method chaining and implicit iteration jQuery/other frameworks provide sure makes working with the DOM a lot nicer.

I've recently been experimenting with some HTML5 mobile app programming, and since that saves you from the problem of IE8 I've been doing it without jQuery. So far I've found I don't miss it at all, to my own surprise. I wrote a few short convenience functions for XHR etc but it's nothing at all like mowing a lawn with scissors.

This is true for a lot of apps and functionality, but you’re ignoring the large library of jQuery plugins out there. Just as a basic example I needed a slider on a recent app I built. Sure, there’s <input type="range"> but if you want it to work in IE or Firefox you’re better off dropping in a jQuery UI Slider.

The beauty is that <input type="range"> works in any browser. Some just render it as text input.

A fair point for a standard form, but try telling Firefox and IE users that they have to type in their audio volume manually on the jukebox I built.

Are you aware of a good jQuery -> Javascript guide? I learnt jQuery years ago, as I was advised to avoid the mess which is browser configurations, in particular there was problems attaching triggers. Given I would count IE9 as a "new" browser...

Maybe if you're only building a simple app, but I suspect most people at some point need other components like date pickers, format masks, form validation, table filtering/sorting etc. of which many require jQuery anyway.

Reply on news.ycombinator.com