A salute to a job well done
At the risk of being burnt-at-the-stake for heresy: for some time now I have found JQuery to be more of a hindrance than a help, but perhaps my perspective is unusual.
As for cross-browser compatibility, it depends on your perspective regarding legacy web browsers. If, like many, you are of the opinion that only ‘evergreen’ / modern browsers should be supported now that IE6 has formally (if not completely) dropped out of the picture; the need to support code across different browsers has reduced significantly since the bad old Netscape/IE days. If your requirement is to support all (or the large majority of) web browsers then there are techniques such as Progressive Enhancement to consider and Feature Detection tools like Modernizr (https://modernizr.com/) that do a very effective job of supporting is issue.
When I was at school, pocket calculators were rare. The education system was in turmoil over the rights and wrongs of allowing such devices into classrooms and exam halls. Very few of us can calculate square-roots with pencil and paper but imagine if we taught our children how to perform addition and multiplication only by means of pressing buttons. Nevermind learning to spell – that’s what a spell-checker is for, write? I am not suggesting we should never use such tools (god forbid) but I am suggesting we need to understand they are not the only tools at our disposal and having a foundation knowledge is critical. Most people do not need a calculator to multiply 10 x 10, because they learned their times tables at school.
So, I stated my perspective may be unusual to most – why? My involvement in web technologies started around the year 2000, when I co-designed an application for a large UK police force.
We decided to employ the MS IE 5.5 web browser to deliver the User Interface. Our application made use of the Microsoft.XMLHTTP ActiveX control to exchange XML documents between the client and server. This enabled us to perform more of the business functionality (data validation) on the client-side (in the web browser) and greatly reduced out network traffic demands.
This was more than 4 years before this technology was given the moniker “Ajax” by Jesse James Garrett, in his February 2005 article “Ajax: A New Approach to Web Applications“. It was 5 years before the standardisation of XMLHttpRequest (XHR) by W3C and its integration into web browsers as a standard feature (MS IE 7+).
Same solutions, different problems
Our perspective, from the Software Development industry rather than the (relatively new) Web Development industry, views the User Interface as a component of the application with no higher significance than the database or interfaces with external systems. In our world “Content is (not) King” (burn the heretic) but “functionality is foremost”. Our attention is not on what the visitor needs to see, but how we can best support the end-user in his/her daily business.
Many projects I work on are for large corporate organisations with very controlled environments and strict IT strategies. I regularly encounter clients who (for whatever reason) do not permit open-source software/libraries on their systems. Some clients have a protracted processes for reviewing external products that means the approved version’s are often well out of date.
God forbid we find an error in one of these external libraries or get some form of conflict between two frameworks. Good luck on sorting those out.
Spreading the love
JQuery is not alone; I have similar contempt for other libraries such as Bootstrap, which serves designers very well to demonstrate how a screen needs to degrade gracefully with reduced screen space. But it is as if media-queries are the preserve of black wizards. We bolt in these frameworks, warts and all, bloat-out our own software rather than invest some time and effort in learning how to master the standardised technology ourselves.
There is a similar issue in the CSS technology with their use of vender prefixing (vp). For those unfamiliarly with the practice: before a CSS feature is fully recommended by the W3C the specification will have been circulating browser venders for months. Without a clear and authorised specification for a feature’s development, or its interface, manufacturers will offer developers their best guess. In order to minimise the impact of web presentations, the manufactures mark their (non-standard best-guess) implementation by prefixing a code such as -moz- (Mozilla – Firefox), -ms- (Microsoft – IE/Edge), -o- (Opera) and -webkit- (Chrome).
By itself this is fine and it provided designers/developers with early visibility of up-coming features. The majority of the time the interfaces and behaviours of these nascent features are very similar across all the vendors. The problem is not that their may be differences, that is what vp is intending to avoid by establishing a virtual namespace for their versions. The issue, I have, is what happens to the vp features outside of the design community. Remember, these features are immature, so when instructed to implement them, developers will often safeguard their code by declaring as many variations of the feature, of which they are aware, followed by the recommended version once approved.
/* Cross-browser css3 linear-gradient */
/* Gecko browser (Firefox) */
background-image: –moz–linear–gradient(top, #D7D 0%, #068 100%);
/* Opera */
background-image: –o–linear–gradient(top, #D7D 0%, #068 100%);
/* older Webkit syntax */
background-image: –webkit–gradient(linear, left top, left bottom,
color–stop(0, #D7D), color–stop(1, #068));
/* Webkit (Safari, Chrome, iOS, Android) */
background-image: –webkit–linear–gradient(top, #D7D 0%, #068 100%);
/* W3C */
background-image: linear–gradient(to bottom, #D7D 0%, #068 100%);
The problem arises once the recommended version becomes mainstream and the vp versions are dropped. This will not impact the effect but leaves debris in the code base. millions of now obsolete vp-features being sent over the network only to be ignored.
My advice, keep the vp editions in the design box labelled “aspirational”, never release them into the wilds of the WWW, never to be recaptured.