Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You might not need jQuery

youmightnotneedjquery.com

Post reply on HN
Print view View original

261–270 of 360 posts

Re: You might not need jQuery

#261

Post by TheZenPsycho »

Iftheshoefits wrote: post #241
leeoniya wrote: post #239

Earlier quoted context omitted.

> I strongly believe jQuery has created a generation of developers who know the library but not the language i think you mean "know the library but not the DOM and additional HTML5 APIs" - they are after all just native libraries. ES5/6 would be the "language"

JavaScript is a dynamic language, and it is arguably the case that many of the frameworks that exist for it hide or transform enough of the "native" implementation details as to be different languages. Or supersets of it, if you like. I don't think it's at all unreasonable to suggest that a developer who uses jQuery (or any other framework) doesn't have to have more than a vague, fleeting understanding of the "native…

Such a viewpoint would be ignorant of the distinction between a language and an API.

Re: You might not need jQuery

#265

Post by deevus »

I'm simplifying a bit here: but if we all used the same cdn's client machines would all have popular scripts like jQuery cached and we wouldn't even need to discuss this.

Re: You might not need jQuery

#266

Post by hrktb »

sinkasapa wrote: post #258
hrktb wrote: post #196

Earlier quoted context omitted.

You wont have $.contains, instead $(el).children(child) returns a chainable filtered list of the first level of child nodes, or $(el).find(child) will go down recursively. jQuery rarely dumbly duplicates some native functionnality, as for the example above, most of the time it will diverge in meaningful ways.

These two new functions you mentioned are both in the article linked to above. 'el.children' and 'el.querySelectorAll(selector)' are given as alternates. It is true they aren't 100% the same but JQuery isn't different enough in my opinion for there to be any clear reason to use it instead of what is already available. As a side note, I know this is totally a matter of taste but "chainable" in the JQuery sense reads t…

> As a side note, I know this is totally a matter of taste but "chainable" in the JQuery sense reads to me as "spaghetti generator".

I think this is more important than a side note. The reason jQuery's 'children' or 'find' is way better in my eyes is because of the support for arrays as target and argument, and the possibility to pass the resulting collection to the next command as is.

Going the native route, filtering the children will need an extra loop, doing so on an array of parent elements will also bring an other loop. And we'd have to deal with a Nodelist instead of an array. A 2 command jQuery line would be 5 to 10 lines in native code, every time there is some node tree to filter.

Manipulating collections of DOM elements is such a common case that having to deal with loops every time is just tiring, less readable and more prone to basic errors.

In a way I see it as an anti-spaghetti feature. Less boilerplate, shorter, more concise code with clearer intents.

My side note would be that el.querySelectorAll(selector) is versatile, but not as much as the jQuery find. Telling which cases for which browsers would not work with the native function could be some interview question, but that's not the kind of thing I'd like to remember.

Re: You might not need jQuery

#268

Post by padseeker »

ubernostrum wrote: post #225
padseeker wrote: post #134

I use jQuery because the DOM API for javascript sucks, and writing jQuery is fun. You're average web app perhaps doesn't need the latest Ruby/Python/PHP framework, or perhaps it you can write it without the framework. Or perhaps you can a compiled as opposed to interpreted language because that would be faster. OR maybe you can use something that is even faster, like perhaps Assembler! Fuck it write machine code if s…

I use jQuery because the DOM API for javascript sucks, and writing jQuery is fun. How many lines of code are actually needed to give you selectors and the most common DOM manipulations? How many lines of code are in jQuery? Is there anything which would not be in selectors + common manipulations that you need, and which only jQuery can provide?

DOM selectors and events are critical, maybe ajax. Perhaps you could pare it down a bit - I don't need the animation stuff. I have no idea what the size using only what I might need when I needed it.

But then that becomes a whole another endeavor - how much load time will be saved by only using the parts you need, and how long will it take to figure out what you need and what you dont? It's all about return on investment. What do I need now, what won't I ever use, and what might I use later. It becomes more work to save, what, 1/4 second? Maybe a bit more on mobile. It isn't worth the trouble.

The whole obsession over the load time of jquery feels like an exercise in OCD.

Re: You might not need jQuery

#269

Post by Yaggo »

In my personal projects (and clients' too unless paid extra), I target for modern browsers + IE10 and haven't used jQuery for long time. Native APIs are good enough once you get used to them. Actually jQuery starts to feel cumbersome (this binding in .each() etc).

Re: You might not need jQuery

#270

Post by btd »

nostrademons wrote: post #219
voltagex_ wrote: post #214

Earlier quoted context omitted.

For IE9, don't you need IE-specific code for cross domain requests?

Yeah, you need XDomainRequest for CORS requests in IE8 and 9. IE10 is fully standards-compliant. http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdoma...

It is very castrated, better to use hidden iframe + window.postMessage for cors in ie8 and ie9.
Post reply on HN