Skip to main content

JQuery

The jQuery Crisis​

The old model for connecting the display (the UI, meaning, effectively the DOM in the web browser context) to JavaScript values finally broke down under the sheer weight of the problem. Nothing is more basic to any interactive application than that the screen reflect the current values held in program variables — a counter, the current logged-in username, etc. etc. etc. JavaScript itself offered a very clumsy API to address this, which explained the incredible success of jQuery, which also addressed some other important weaknesses in official JavaScript — most importantly AJAX/XHR transactions with the server. But with increasingly complex client-side apps, even jQuery had ceased to make sense with its approach to using CSS selectors to “select” DOM elements as JS variables for the constant reassignment of current values from variables in the business logic. It became routine to speak of “spaghetti code” in this regard — hard to reason about and read and debug and maintain.

The answer had long been recognized to be possible through libraries that effectively “bound” an identified HTML element to some named JavaScript variable. This is readable, permanent and reflects the intention that the content of the HTML element in the DOM is to always reflect the current value of the indicated variable. The success of the original Angular (meaning 1.x, currently called AngularJS), dating back already many years, was almost entirely due to this solution.

By 2014 and 2015, it was obvious to everyone that the jQuery revolution that had seen universal adoption had run its course and that it was time to move to a new model. Facebook went open source with its React solution, which was simple, and offered a super-clear intellectual approach to UI data binding using JavaScript to specify the desired HTML. The uptake was incredible, and by 2016, the pressure to adopt this framework became overwhelming, even over the long-approved Angular approach for reasons we cannot fully explain here (related to problems with “two way” data binding in Angular that favored a shift to “one-way” binding).

But by this time a completely new Angular was already in the pipeline, heading through long alpha and beta stages of development. With the new Angular (initially called Angular 2, but now called just Angular in contrast to the original, now called AngularJS) — Google chose to go much farther than to merely replace “two-way” binding with “one-way” bindings, but rather to rethink web development on a colossal and comprehensive scale, with a componentized approach to UI that was effectively embraced in React as well.

The SPA (Single Page Application) Revolution​

The jQuery approach to UI would have been replaced with the React/Angular “bindings and components” approach no matter what. But the process got a blast of rocket power from a related revolution. The needs of mobile, above all, drove a new vision in which not just the UI, but also the application business logic, should move from the server to a JavaScript application running in the browser. Both the JS language and its runtime environment in the browser had rapidly been improving to where this was becoming feasible. The new model is that of a front end application that loads only one HTML file over the course of its life — the Single Page Application. But that initial download now includes templates or other means to generate all possible HTML views and the business logic to generate them as needed. In the SPA, after the original download, the JS app goes back to the server only to request raw data in JSON format, as required. This kind of efficiency makes real sense in a mobile context.

React by itself provides only the UI portion of this solution, thus it is proper to speak of the React ecosystem of packages that, when combined as a developer may choose, provides a complete SPA solution. The current Angular provides the complete solution all by itself and is thus much more complex and difficult to learn than the React library alone. Angular is therefore more appropriately called a “platform” than a “framework,” but this is quibbling.

2016 — Year of Confusion​

Last year, with React already rocketing and Angular finally getting into final release state for serious introduction, the landscape was further confused by the presence of Ember (a well-loved alternative already in strong shape) and the appearance of Vue (having the affection more of the creative individual developer than of “enterprise”). Thus the 2016 landscape/mindscape was just about as confusing as possible, especially as so many people were unable to understand the larger dynamics that are so much more evident even only a year later. And there was terrible fear — much it is highly justified — that the intellectual demands of SPAs and the new frameworks (especially the new Angular) would overwhelm the average “web developer” who had mastered jQuery and felt inadequate in true application programming at the level that was rapidly emerging. So fear blended with confusion, and confusion with ignorance, and ignorance with noise. 2016 was a bitch, filled with a lot of argument and frustration.

The confusion, and the panic it was generating, was reflected in widespread exhaustion as everyone grasped to hold on to something “solid” during the earthquake. It became popular and even accurate to speak of “fatigue” at the effort of trying to keep up with, or catch onto, a speeding train of seemingly daily new developments and standards competing for support and critical mass.

But the smoke is definitely clearing. The SPA is real and cannot be evaded. That means that the new front-end frameworks/platforms/ecosystems cannot be evaded — especially the need to choose between React and Angular (as the two backed by the big tech players), a decision much too important and complex to address here.

And it also means that the need for the front-end developer to embrace the reality and standards of unqualified application development (not merely what used to pass for old-fashioned “web development) cannot be evaded.

selectors​

\$("selector")

  • '#'
  • '.'
  • document.getElementById("datepicker");
  • document.getElementsByTagName("input");
  • document.getElementsByClassName("date");
  • document.querySelectorAll("div.date");
  • document.querySelector("access");

same thing as jQuery("selectorExpression")

  • $("*");
  • $("elementName");
  • $("#elementId");
  • $(".class");
  • returns a jQuery object,
  • $('.importantText')
  • find a collection of DOM Elements with the DOM ID (should be unique) $('#id')
  • Wrapped Set
  • $("selector")[int]
  • $("selector").get(int)
("p").html(yea yea yea)
("p").text(yo yo yo)
\$("content").appendTo(" selector ");
\$("content").prependTo(" selector ");
\$("selector").append("<li> this is an alternate syntax </li>");
\$("selector").prepend("<li> alternate syntax </li>");

$("selector1, selector2, selectorN")​

  • Multiple Selectors

Chaining $("selector").method()​

returns an array​

Hierarchy Selector​

  • $("ancestor descendant");
  • $("parent elem > child elem");
  • $("prev elem + next elem");
  • $("prev sibling next sibling");

Positional​

  • $("element:first");
  • $("element:last");

JQuery Filters​

  • select by type of element
  • $(":button");
  • $(":checkbox");
  • $(":password");
  • $(":submit");
  • $(":text");
  • $(":file");
  • "Write less, do more" javascript library
  • its versions into the 1.x line, which supports IE 6 and later, and the 2.x line, which supports "modern" browsers like IE 9 and later

https://oscarotero.com/jquery/

Document Ready​

  • prepare for jQuery functions
  • document.ready() is all of the elements inside the document object model

All three of the following syntaxes are equivalent:

  • \$( document ).ready( handler )
  • \$().ready( handler ) (this is not recommended)
  • \$( handler ) 
JQuery(document).ready(function() {
      //code
});

OR​

\$(document).ready(function() {
      //code
});