JQuery critique (dis)continued

Some time ago I posted a not so nice attack on jQuery, which I removed. Before that I posted a critique of jQuery that I myself find constructive and informative, but was nonetheless a bit random and incomplete. Moreover, it was also a shameless plug for a new technique I created myself: a stack-based, concatenative language that parses to Javascript in the browser. However, I have stopped working on it, as I think that stack-based languages are hard because of the mental bookkeeping you have to do on the stack. Sure, that is a perfect brain trainer, and there are ways to make the exercise less cumbersome, but I don't expect a mere fraction of jQuery users will ever warm up to such a niche technique. To cut it short, this introduction serves as an apology to both the reader and the user of jQuery, for whom it has created huge opportunities. But now to end my critique of the bling chain once and for all.

First of all, I'm no user of jQuery and never have been. The reason for my crusade against it has been the isolation I experienced in relation to the community of fellow web developers that created content based solely on jQuery. It would have been beneficial to my work (and perhaps that of others) if a more open technique would have been embraced. I've never found a community that completely fitted into my personal view, but the overall enthusiasm the past years for jQuery has put me off again and again. I know that at the moment the world of web development is going through a major shift, and my critique has become less relevant. However, I would like to put it out there, to try and prevent developers from making the same mistake in upcoming solutions.

JQuery is a catchall. You can just throw anything into $() and you don't have to care what comes out at the other end of the chain. You use .get() to evaluate the result, which can be anything, from a DOM node to an event handler. I suppose this is simply caused by organic growth of the library: first it was just a uniform way to query and transform DOM, but as the library grew, so did the types of data that were processed in this style. The uniformity obviously served a purpose back when you had so many browser incompatibilities, but it was never a good programming practice to begin with, as type systems have mattered since the dawn of computation. Actually, proper typing and other standards have probably been slow to develop in Javascript because of the popularity of jQuery. I think a lot of people underestimate the damage it has done, because it lacks any formalization, mainly regarding but not limited to the following:
  1. what the input is that $ operates on
  2. what types are allowed in that input
  3. what the types are of the throughput
  4. what the semantics are that operate on the throughput
  5. how to consistently extend those semantics
In short, jQuery lacks what constitutes a proper programming language, while it does insist on a uniformity that diverts from its "host language", Javascript. One might say jQuery is just a pattern, and one that will get the job done quickly, but this pattern comes at a price: it is not compliant with any ECMA standard and cannot be transparently ported to one. Moreover, due to the lack of formalization, it could not and never will become a de facto standard.

Anecdote: I once came across a widget where an XMLHttpRequestUpload instance was thrown into $() just so bind() could be called. Imagine doing that with document.querySelectorAll... The point here is that typing doesn't necessarily has to be enforced, but using a tool that doesn't even adhere to best practices in this regard should not have been allowed to become this successful. It shows what little formal knowledge its large user-base has, and I don't say this to insult anyone. To conclude, I found a video on the internetz from 2012, where a designer makes some valid points about jQuery. Though not from a formal background, the speaker instinctively finds some flaws that I need not repeat here, but in my opinion the community should have taken note of back then.

https://youtu.be/3D1WeSCSkPQ

Comments

Post a Comment

Popular posts from this blog

Abandoning hope... and XForms

Sometimes a decision must be made. I have invested many hours in a standard that is quite complex and tedious to maintain, and that was great fun, but enough is enough. Why did I invest in XForms when it took so much effort and time? Because I believe standards are good and good standards come from the W3C and the XML community. Also, I always had somewhat of an inferiority complex in IT development that I tried to compensate by using techniques supposedly invented for common folk, i.e. non-programmers. Both are bad reasons from where I now stand. I took up XForms because I was infected by the enthusiasm of a friend (who was even quicker to abandon it) about 3 years ago. At first I assumed it just used a model from which to infer a form. It turned out it was like a superset of HTML forms with options for displaying and validating data. This was largely taken up by HTML5, as we all know. The Model remains the core of XForms, but the W3C is slow to respond to innovations and t...
Read more

JS Journey into outer space - Day 5

This article was written as part of a knowledge sharing program I created for front-end developers. It builds up to creating reusable abstractions by studying async transducers. Day 5 It's time to add more operators. We already have map , but what if the mapping function returns another "container" value, like an array or observable? 🦉 In RxJS some operators like switchMap , concatMap , or mergeMap will expect a "project" function that returns an observable (or promise or array), but what happens then? First map is applied with the project function and after that the result is "flattened". In other words: when the returned (inner) observables emit, the mapped (outer) observable emits those values instead. Since RxJs streams have a specific async behaviour the flattening process takes concurrency into account: mergeMap will flatten inner observables whenever they complete, regardless of the order, but concatMap will preserve the order of the ou...
Read more

JS Journey into outer space - Day 4

This article was written as part of a knowledge sharing program I created for front-end developers. It builds up to creating reusable abstractions by studying async transducers. Day 4 Now we have modified transduce to handle async it's time to figure out how it can handle observables. Kickoff 🏈 First we need to pass the onNext function which kicks off the callback chain. In RxJs this is called subscribe instead, so let's rename the parameter and the callbacks to be more in line with RxJs : function transduce ( input , fn , subscribe , onError , onComplete , init ) { subscribe ( input , { next : ( cur ) => { init = fn ( init , cur ) ; } , error : ( err ) => { onError ( init , err ) ; } , complete : ( ) => { onComplete ( init ) ; } } ) ; return init ; } ; 🦉 Observables are considered a push-style of dealing with many values, while generators are pull-based. In...
Read more