31–40 of 241 posts
Earlier quoted context omitted.
> Hidden complexity you don't control is the most expensive kind I think. That's called encapsulation. :) Seriously, encapsulating complexity is the foundation of most programming paradigms.
Actually, it's called abstraction, as a technical point.
https://en.wikipedia.org/wiki/Encapsulation_(computer_progra...
Earlier quoted context omitted.
Worth noting is that at least in the animation case, the non-jQuery (CSS) version should perform better than the jQuery version
Are you sure? AFAIR, jQuery has used native (hardware-accelerated) CSS transforms since 2014.
https://api.jquery.com/fadeOut/
Edit: I just realized you said "transforms". Transforms are a separate question from transitions. CSS transforms are concerned with giving an element a different size, rotation, and/or position. Transitions are concerned with changing any given CSS property gradually over time (including potentially transforms). I think you're right that jQuery started using CSS transforms, but it does not appear to use CSS transitions.
It's ironic that there's probably no bigger sales pitch for jQuery than this site. In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. (and the jQ version seems significantly easier on the eyes as well.) Also, jQuery supports promises and has for quite a while. This page hasn't aged well. I've come full circle and am now using jQuery again.
On the web, user experience should really be a higher priority than developer experience.
Earlier quoted context omitted.
Are you sure? AFAIR, jQuery has used native (hardware-accelerated) CSS transforms since 2014.
At least in the example on this page, it performs .fadeOut() by changing the opacity via JavaScript instead of using the CSS transition property. You can verify by inspecting the DOM https://api.jquery.com/fadeOut/ Edit: I just realized you said "transforms". Transforms are a separate question from transitions . CSS transforms are concerned with giving an element a different size, rotation, and/or position. Transitio…
It's ironic that there's probably no bigger sales pitch for jQuery than this site. In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. (and the jQ version seems significantly easier on the eyes as well.) Also, jQuery supports promises and has for quite a while. This page hasn't aged well. I've come full circle and am now using jQuery again.
I think a lot of the initial appeal around jQuery was that it made querying and manipulating the DOM simple. Much of its features have been replaced by broadly-available APIs like Document.querySelector and Element.classList. Loading the entirety of jQuery just to access some of the remaining features just means you're loading JavaScript that you aren't going to use. I miss relying on jQuery because it's familiar and…
Browsers got to this point because jquery pushed for it.
Oh wait...
Now only if someone could combine the snippets on the right hand side in an easy-to-use library. Oh wait...
If we're really clever we can probably get it up to several megabytes, require three languages and have it run from an embedded C compiler written in Webassembly.
Of course, it will only work in Chrome but really who wants to waste time testing in browsers nobody even uses amirite?
Earlier quoted context omitted.
I think a lot of the initial appeal around jQuery was that it made querying and manipulating the DOM simple. Much of its features have been replaced by broadly-available APIs like Document.querySelector and Element.classList. Loading the entirety of jQuery just to access some of the remaining features just means you're loading JavaScript that you aren't going to use. I miss relying on jQuery because it's familiar and…
I thought a big part of the initial sales pitch was not having to deal with cross-browser compatibility issues.
Earlier quoted context omitted.
This comment is a great example of what I call "lines of code mindset" which is form of tip of the iceberg mentality, where programmers optimize for simplicity only the code they see. Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? Hidden complexity you don't control is the most expensive kind I think.
> Hidden complexity you don't control is the most expensive kind I think. That's called encapsulation. :) Seriously, encapsulating complexity is the foundation of most programming paradigms.
Encapsulation/abstraction should really be a tool of last resort. From experience, it doesn't actually help reduce complexity if overused, but just makes it hidden and more likely to surprise you when you're debugging.
It's ironic that there's probably no bigger sales pitch for jQuery than this site. In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. (and the jQ version seems significantly easier on the eyes as well.) Also, jQuery supports promises and has for quite a while. This page hasn't aged well. I've come full circle and am now using jQuery again.