Products

Solutions

Resources

Partners

Community

About

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.


Goodbye jQuery - you were awesome!

It's time to let go, and letting go can be a bit tough on the soul. I remember when I started using jQuery I thought this is the best thing that happened since sliced bread - it was fun, it worked very often (as opposed to plain JavaScript in those days) and it worked cross browser: AWESOME! 

Time to say goodbye

But now it's time to say goodbye. If you've been in the Microsoft web-ecosystem for a long time you will be very surprised to hear this - so please let me explain. 

  1. jQuery basically builds on the premise that you create an HTML setup - like a few div, span and button tags - and then "inject" both events and changes from "outside" - usually after the DOM has been fully setup. So the kickoff is usually a $(function() {…}) which ensures than this kind of binding happens once the DOM is here.
  2. Then within our jQuery code we usually use special selectors like ".rotator" to find all the tags we're about to modify, apply some changes, and then wait for the next event. 
  3. Once an event kicks in - say a click - we again will use selectors to navigate the DOM, apply some changes (like toggle show/hide, start an animation, etc.) often by adding / removing CSS-Classes, and waiting again. 
  4. And when all is said and done, jQuery has a great simple ajax-helper to get things done. 
  5. jQuery also has loads of plugins… 
  6. …and themes 
  7. …and UI widgets 
  8. …and handles cross-browser stuff 
  9. ...and much more

Awesome, right? 

Here's the catch: the basic development model works great for controlled environments and simple functionality. 

When we go any further, things begin to get difficult. If you take a step back and analyze the situation, and remember all the times you cursed when a selector or a change had unexpected side-effects, you'll have to admit the programming model is rather hacky. 

The core problems: no clear model/view binding and hacky outside control 

All the binding and changing strongly relies on "outside control" of your DOM which is not fully reliable and can easily affect other items as well. In addition to the side-effect which can be worked around with enough time, there is also the lifecycle of the application: when you create a real tool (like a UI for a data-system) which does not reload for a long time, things get hairy - because it's very easy to make DOM-changes (adding classes etc.) which cause problems later on because the application didn't expect it. Since there is no real model/view binding a lot can get out of sync with time if you're not extremely disciplined. 

This all didn't matter much when the page reloaded every few seconds, but now that an AJAX-style app can stay on screen for hours, it matters a lot. It also was ok with simple in-page image-rotators, but breaks down as your system scales into complexity. You can of course compensate a lot of this with brains - but it's an expensive price to pay. 

The future is moving away from jQuery 

If you've been looking in to the open-source JS-world, you'll notice that many plugins are proud to offer a version which works without jQuery. Be it JSPlumb, angular-toastr and more. 

So let's do another quick review - looking at the situation from 2015. 

  1. Performance jQuery has a real performance penalty, both in page-load-time as well as execution time, since it's usually in charge of the entire DOM. So even if you "only need a small part" of the DOM, jQuery still has to navigate everything. This is especially true for larger pages - like portal-style DNNs or single-pagers which are so popular now. You can optimize around this, but it's hard work. Leaving jQuery out can easily multiply perceived user performance. A common example of this performance hit is a dnn-page in edit-mode with a lot of modules. 
  2. Cross-browser 
    1. not very important any more as most browsers are sticking to the same standards 
    2. AJAX - not a big issue any more 
    3. DOM selectors not very important any more as most browsers support much of this + it's actually one of the core problems - if you have view/data binding, you don't really need selectors 
  3. Themes - never really caught on, and most of us use bootstrap anyhow 
  4. UI-Widgets - many alternatives available, and these usually require Themes 
  5. View/Data-Binding - almost all alternatives are better - knockoutJS for getting started, AngularJS once knockout gets too small/slow for your needs (or if you want to skip the knockout-phase) 

Summary and Future 

Basically the necessity for jQuery has dropped dramatically, as has its value, while the "cost" of using it is rising as JS-Apps become more complex and stay alive much longer. We from 2sic are moving out of it as fast as we can - and we believe so should you.


Daniel Mettler grew up in the jungles of Indonesia and is founder and CEO of 2sic internet solutions in Switzerland and Liechtenstein, an 20-head web specialist with over 800 DNN projects since 1999. He is also chief architect of 2sxc (see forge), an open source module for creating attractive content and DNN Apps.



Read more posts by Daniel Mettler

Comments

Tony Henrich
Use the right tool for the right job. I haven't seen good non jQuery based alternatives for the thousands of good jQuery plugins. jQuery is usually cached in the browser and it doesn't need to be reloaded when visiting sites which use it. jQuery's size is a lot smaller than Angular and Angular itself uses a stripped down version of jQuery. I think most sites fall under 3 categories, content only for reading only which probably don't need any JS framework. Sites heavy in animations and visual effects that where jQuery can shine unless developer prefers to use pure HTML5 and CSS3. Sites which have many form elements, content from databases and need interactions with user, that's where probably data binding JS frameworks (use your preferred framework) are handy.
Tony Henrich Wednesday, October 21, 2015 1:32 PM (link)

Comment Form

Only registered users may post comments.

NewsArchives


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Daniels (3)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (37)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (213)
Chris Paterra (55)
Clint Patterson (108)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (181)
Daniel Valadas (48)
Dave Buckner (2)
David Poindexter (12)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (80)
Francisco Perez Andres (17)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (4)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (2)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (40)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Patricio F. Salinas (1)
Patrick Ryan (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott Schlesier (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Tony Henrich (3)
Torsten Weggen (3)
Tycho de Waard (4)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (180)
William Severance (5)
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out