jQuery is Dead - Long Live JavaScript!

  • 39
  • 1
  • Question
  • Updated 4 months ago
  • Doesn't Need an Answer
  • (Edited)
jQuery is Dead - Long Live JavaScript!

It might come as a surprise to you - especially if you are recently learning to use script with QuickBase - but jQuery is considered dead by many developers and have been so for many years now. Born in August 2006, jQuery was hugely successful in abstracting away differences in browser's DOM behavior and offering a rich and comprehensive set of features for DOM manipulation, AJAX and animation. During the last decade, most of the features of jQuery have been added to the browser's JavaScript engines and core set of APIs. Additionally, frameworks such as React, Angular, Ember and Vue have created whole ecosystems of libraries and tooling that each surpass jQuery's capabilities. However, jQuery is not going to disappear from QuickBase anytime soon but there are three things you should know to make your usage of jQuery with QuickBase more successful and help pave the way for seamless adoption of the new technologies that are are available now or are landing in the near future.

(1) Old Version of jQuery Being Used
QuickBase is using version 1.7.2 ( console.log($().jquery) ) while the current version of jQuery is 3.2.1. The has a large number of ramifications when consulting documentation and debugging scripts that are too numerous to enumerate here but should be kept in mind. However, there is one issue that deals with chaining AJAX calls that should be mentioned as it can be difficult to debug and can show up unexpectedly. We can examine this issue in the context of a recent demo: 

https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=dr&rid=615

Consider this fragment of code which has a couple of console.log() statements added:
  $.get(dbidTable, {
    act: "API_DoQuery",
    qid: "1",
    slist: "3",
    options: `num-${n}.sortorder-D`,
    includeRids: "1"
  }).then(function(xml) {
    console.log(xml);
    var rids = $("record", xml).map(function() {
      return $(this).attr("rid");
    }).get();
    var query = "{3.XEX." + rids.join("}AND{3.XEX.") + "}";
    $.post(dbidTable, {
      act: "API_PurgeRecords",
      query: query
    }).then(function(xml) {
      console.log(xml);
      document.location.href = `${dbidTable}?a=q&qid=1`;
    });
  });

You may wonder why the $.post() call is made nested in the first then () rather than being chained together with an additonal then() method like so:
  $.get(dbidTable, {
    act: "API_DoQuery",
    qid: "1",
    options: `num-${n}`,
    includeRids: "1"
  }).then(function(xml) {
    console.log(xml);
    var rids = $("record", xml).map(function() {
      return $(this).attr("rid");
    }).get();
    var query = "{3.XEX." + rids.join("}AND{3.XEX.") + "}";
    return $.post(dbidTable, {
      act: "API_PurgeRecords",
      query: query
    });
  }).then(function(xml) {
    console.log(xml);
    document.location.href = `${dbidTable}?a=q&qid=1`;
  });
In this particualr situation the second block of code will acheive the same result as the first block of code. However, the two console.log(xml) statemetns in the seccond block of code will log the same XML response - that of the first $.get() call. This is because there is a bug in jQuery version 1.7.2 which QuickBase uses.

Now there is a fix to this situation which is to use $().pipe() instead of $().then() as follows:
  $.get(dbidTable, {
    act: "API_DoQuery",
    qid: "1",
    options: `num-${n}`,
    includeRids: "1"
  }).pipe(function(xml) {
    console.log(xml);
    var rids = $("record", xml).map(function() {
      return $(this).attr("rid");
    }).get();
    var query = "{3.XEX." + rids.join("}AND{3.XEX.") + "}";
    return $.post(dbidTable, {
      act: "API_PurgeRecords",
      query: query
    });
  }).pipe(function(xml) {
    console.log(xml);
    document.location.href = `${dbidTable}?a=q&qid=1`;
  });
The reason I choose not to promote this idiom is because $().pipe() has been deprecated since jQuery version 1.8 when the above problem with 1.72 was fixed. So in my opinion while using jQuery with QuickBase it is a better temporary opption to start nesting AJAX calls rather than chaing them together with $().pipe().


(2) Native Promises
The second piece of advice for using jQuery with QuickBase is to learn how to convert a jQuery promise to a native JavaScript promise. In a nutshell, promises were added to JavaScript in a manner inconsistent (but better) than how they were implemented in jQuery. 

Luckily you can convert a jQuery promise into a native JavaScript promise by simply wrapping the jQuery promise in a native Promise.resolve():

var nativePromise = Promise.resolve(
  $.get(...)
}

(3) We are constrained to use the existing jQuery version 1.7.2 when injecting code into QuickBasse pages. However, if you are creating a solution that uses a standalone code page you can and should use a more recent version of jQuery or perhaps rely on native promises or a modern framework of your choosing.
Photo of Ⲇanom the ultimate (Dan Diebolt)

Ⲇanom the ultimate (Dan Diebolt), Champion

  • 28,304 Points 20k badge 2x thumb

Posted 12 months ago

  • 39
  • 1
Photo of Michael Curtis

Michael Curtis

  • 596 Points 500 badge 2x thumb
document.querySelector() FTW
Photo of Joshua Tate

Joshua Tate

  • 1,016 Points 1k badge 2x thumb
lol or just period dont use jquery there is no need, Jquery is a waste of time......

Wolf: little developer let me in.
Me: not through the parser in my little dom tree.
Wolf: well i'll huff and i'll puff and inject an unexpected token,
Me: you can try hard as you might but i have have immunity and improved functionality over your antiquated ways, disappear now and allow W3C/ECMA to pave the way.

A) Use fetch or xhttp - preference on fetch, while i know Dan has identified what some may perceive a few draw backs, i personally dont mind that i need handle a a bit more "annnndddd theeennnn" see below. 



B) native promises are far superior to any jquery/bluebird/early days polyfill approach, check out async functions for the mother of all promise chaining, get your nice anndddd theeennnnn chain underway.

C) Dont touch frameworks, there a waste of time. Library extensions are ok but likely better to identify the functions you actually require, take inspiration then rewrite what you need into your generator function.

D) Learn to build Generators, love them, adore them, improve them and keep them vanilla JS to saver them for life. 
Photo of Joshua Tate

Joshua Tate

  • 1,016 Points 1k badge 2x thumb
great source dan, for everyone else, ES2017 introduced Async Await which i use in my generators - yield to the power of the force - enough said haha: https://medium.com/front-end-hacking/modern-javascript-and-asynchronous-programming-generators-yield...   
Photo of Ⲇanom the ultimate (Dan Diebolt)

Ⲇanom the ultimate (Dan Diebolt), Champion

  • 28,304 Points 20k badge 2x thumb
That's what I love about these "no code" platforms - you get to use a lot of advanced coding features to solve problems.

ES2019 is going to give us dynamic import (already in Chrome):

http://2ality.com/2018/02/ecmascript-2019.html#candidate-features-stage-3
Photo of Joshua Tate

Joshua Tate

  • 1,016 Points 1k badge 2x thumb
Hadn't read about that yet! going to give it a good go through now cheers. I'm at the point where the benefits of low code are undone by the inflexibility of me introducing my own themes/bootstrap (not hacked in), lack of on premises hosting and flexibility etc etc, I'm well underway on building my own CRUD on Nodejs mapped to MS SQL with PHP front end with Bootstrap for one of the apps we use QB for as longer term reliance without the things i mentioned above means we cant set and forget with support handed over to our infra team. 
Photo of Joshua Tate

Joshua Tate

  • 1,016 Points 1k badge 2x thumb
of course my favorite meme to go with the above