A solute of recognition
The web development world is a fast moving beastie with new techniques, standards and technologies released almost daily. Keeping abreast of every new big thing is almost impossible, especially if web development is not your entire 9-to-5. The same thing applies to the growing selection of CSS frameworks and third-party development tools.
The most important pulses to keep a finger on are the web standards (W3 & ECMA recommendations) and the browser implementations there of, as everything hinges on them. May be I am just getting too old for this game; or may be I have a life!
“What? I am not allowed to use jQuery!”
I was recently on a project for a large (global) automobile manufacture, designing a web application that
I have employed a little figurative licence in the above text but it is based on an actual incident. The crux of the abstract is that jQuery (and other frameworks) has become so much part of the web development landscape that some developer’s cannot recall a time before it existed. After all, it has been around since 2006 and is every growing in popularity and consequently in dependency. Some developer’s are so dependent on their favourite framework, they cannot develop client-side script without it.
- Better support of functionality between browsers
- Simplification of:
- AJAX functionality
- DOM (Document Object Model) manipulation
- Page loading sequence control
- Theme Styling
- Custom Widgets
- Animation and other “helper” functions
- Implementing the Class-based (C++, Java style) form of Object Orientation using the Prototype-based approach.
- Support for Application design patterns such as (for more info on MVC please read my article):
- MVC: Model-View-Controller
- MVVM: Model-View-ViewModel
- MVP: Model-View-Presenter
All the above are noble aims but suffer from 1 or both of the following:
- As techniques become standardised and simplified the need for “helper functions” is removed.
- As browsers become more compliant with the standards the need for cross-browser support is also reduced.
As the need for frameworks to supply such functionality reduces they leave in their wake a mass of obsolete code in web sites across the globe. An amount of back-ward compatibility will continue to be required for legacy browsers; the last two editions in the case of Google Chrome and Mozilla FireFox. Since the retirement on 8th April 2014 of MS Windows XP, which served us so well for 12 years, the worse offender (Microsoft Internet Explorer 6) is in effect dead; as should be IE 7. This still leaves the last 4 editions (8, 9 10 & 11) of IE to support but they are far less reliant on frameworks.
The rise of HTML5 and CSS3, and their support in the latest web browsers also dilutes the role of frameworks in modern web sites; but I fear the dye is cast. Too many developers include the script tag to jQuery (et al) as a matter of course. I wonder if they know how to call on the functionality (which is in the browser not the framework) without them.
I also wonder if they ever consider the performance overhead. Agreed the hosting of frameworks in Content Delivery Network (CDN) facilities greatly reduces the network latency and caching helps limit the number of refreshes but that is not the biggest hit on performance – that is within the web engine.
Have you ever tried to obtain the latest book on jQuery or DOJO – don’t bother. I would not hold much stock in the on-line documentation either. The velocity of change in the code-base is far higher than the printing press and many of the coders are not gifted when it comes to documenting (within and without) their code. This has been the source of considerable frustration for me and many of my colleges; I can still hear the snigger of laughter from the Java developers.
Another issue is, what could be described as the “shoulder-pad effect” when the build up of shoulder-pads result in the distortion of outer garments. The proliferation of frameworks like jQuery makes for a dependency by later frameworks. Considering the case described earlier when jQuery was excluded from an Enterprise Strategy, which would effectively disqualify other components with a dependency on jQuery. It is one thing to “stand on the shoulder of giants” but shoulder-pads on shoulder-pad become most unsightly and potentially limiting.
Don’t take my word for it.
- Here is an article by James Jackson and Addy Osmani, with comments from Chris CoyierChris Ferdinandi
- Another by Chris Ferdinandi on “Ditching jQuery for vanilla JS”