jQuery: does the conversion to the library spell trouble?

[TracyIsland]

As a self-described end user, I cannot speak with any authority about such things as jQuery. All I can do is read and try to understand concepts.

This article caught my eye today:

http://www.sitepoint.com/do-you-really-need-jquery/

jQuery is an Abstraction

If you think web development is tough now, try developing JavaScript code in a browser from five or ten years ago. The typical problems:

1. DOM navigation and manipulation differ. For example, Firefox (correctly) included whitespace in the DOM, IE6 didn’t. Therefore, you couldn’t depend on node.firstChild returning the same thing.
2. Ajax was natively supported in most browsers, but an ActiveX control in IE (even though Microsoft invented XMLHttpRequest).
3. IE had a different event model but even the other browsers had their share of inconsistencies.
4. CSS2.1 support varied immensely.
5. Animation could be difficult especially when coping with box model differences, form controls and iframes (IE6 placed select boxes and iframes above everything else on the page).
6. Developer tools were rudimentary. Prior to Firebug, Firefox’s error console and IE’s clunky modal error box were the only built-in browser tools.

Developers had to write abstraction functions to get around these issues. jQuery, Prototype and MooTools evolved from the primordial chaos; the libraries smoothed over the cracks and provided useful missing features such as DOM selection from CSS selectors.

It’s important to remember that jQuery and the alternatives are written in JavaScript to make writing JavaScript easier. They’re not languages in their own right.

...... read more

What made me start a topic about the subject is the concern that using jQuery used throughout 4.0 might make it more difficult to interact with new, external applications that will be developed in the coming years.

Any thoughts IPS coding team?

[Michael]

The last sentence in your quote should be the important one: jQuery isn't something that limits what IP.Board can do, it facilitates making the things that web applications do nowadays easier. If there is some web application that IP.Board needs to interact with in the future which doesn't play nice with jQuery, the alternative is to simply not use jQuery for that interaction.

[HeadStand]

From a non-developer point of view, the switch to jQuery is mostly irrelevant. The current version of IPB uses other JavaScript libraries, such as Prototype, instead.

I'm not 100% clear on what your concern is with this statement:

What made me start a topic about the subject is the concern that using jQuery used throughout 4.0 might make it more difficult to interact with new, external applications that will be developed in the coming years.

but I don't think changing JavaScript libraries is going to have a negative effect on integration with external applications. (And by "external applications" I'm assuming you mean completely unrelated to IPB, not 3rd-party modifications.) If anything, I would say that jQuery is more widely used than the libraries we are using right now (although I could be wrong).

[TracyIsland]

From a non-developer point of view, the switch to jQuery is mostly irrelevant. The current version of IPB uses other JavaScript libraries, such as Prototype, instead.

I'm not 100% clear on what your concern is with this statement:

but I don't think changing JavaScript libraries is going to have a negative effect on integration with external applications. (And by "external applications" I'm assuming you mean completely unrelated to IPB, not 3rd-party modifications.) If anything, I would say that jQuery is more widely used than the libraries we are using right now (although I could be wrong).

I was thinking of applications like Pinterest that have suddenly come over the horizon like some massive tidal wave and if some similar application in the future was coded using in the manner described in the article:

In 2013, the top five browsers are closer than they’ve ever been. The vendors have adopted standards and while some browsers may be missing certain HTML5 APIs, the core JavaScript tenets of DOM traversal, manipulation, event handling, server communication and CSS effects are well implemented and documented. If something works in IE10 or Firefox 23, you can (almost) guarantee it’ll be fine in Chrome 27 and Opera 12.

So why use a library when the problems it solves no longer exist? Naked JavaScript will always be faster than calling a library which abstracts the native call. In some cases, naked alternatives are also more useful.

Would IPS's 4.0 structure and dependence on jQuery make it more difficult to interact with such an external application?

[Ryan H.]

You have no idea how huge of a benefit jQuery (or, for that matter, prototype) is for anything regarding interfaces and dynamic content. I did a web app in straight-up Javascript back in 2007, before these libraries really took off. Trying to do any sort of effects, AJAX, and a lot of other little silly things in a smooth and browser-compatible way is an incredibly painful process. With a JS library? Often one line.

[Ryan Ashbrook]

I was thinking of applications like Pinterest that have suddenly come over the horizon like some massive tidal wave and if some similar application in the future was coded using in the manner described in the article:

Would IPS's 4.0 structure and dependence on jQuery make it more difficult to interact with such an external application?

Very, very doubtful.

[Rikki]

jQuery is a lot more than just a way of smoothing over browser inconsistencies - it's a tool for writing more elegant, more expressive and more concise javascript. You could absolutely do it all in plain javascript by writing your own functions - but then you'd end up with your own version of jQuery, except not tested by millions of people.

If you're literally just showing and hiding elements, jQuery is probably over the top. But for more extensive DOM manipulation, it'd be silly not to use it (or another good library) IMO.

[Christian M.]

jQuery is a lot more than just a way of smoothing over browser inconsistencies - it's a tool for writing more elegant, more expressive and more concise javascript. You could absolutely do it all in plain javascript by writing your own functions - but then you'd end up with your own version of jQuery, except not tested by millions of people.

If you're literally just showing and hiding elements, jQuery is probably over the top. But for more extensive DOM manipulation, it'd be silly not to use it (or another good library) IMO.

Then eventually jQuery will be overrun by a better DOM manipulation tool that serves more than it needs to.... basically everything is just upgrading to fast to keep up with so everyone tried to compatiblelize as fast as they can by "human demand" standards don't rush on 4.0 guys, keep it steady and less buggy that it normally would be.