I'm one of the original creators of You Might Not Need jQuery. Most of the examples still date back to 2014, with modern JS they get much simpler and shorter (the fetch API and async/await help tremendously in the first example cited).
Why I'm still using jQuery
151–160 of 246 posts
Re: Why I'm still using jQuery
#152Great reminder that old does not equal bad!
Re: Why I'm still using jQuery
#153Earlier quoted context omitted.
Isn't that different reduced a lot with ES6+? By adding jQuery load time increase by almost a second or two
> Isn't that different reduced a lot with ES6+? ES6+ does not replace browser APIs. There's no ES6+ way around this: const el = document.createElement(...) el.setAttribute(...) el.classList.toggle(...) const parent = document.getElementById(...) parent.appendChild(el) You either do that in one line of jQuery, or end up writing your own wrappers if you need to do this more than once.
I personally prefer what you just outlined over jQuery.
It's more explicit—that will almost always win with me.
Re: Why I'm still using jQuery
#154I've seen a few apps that began as vanilla JS or jQuery updated to use react as the requirements grew and the "simple" JS started crumbling under its own weight. So I'm sympathetic to the idea of just starting with a framework from the get-go.
That's why I'm excited to see how Phoenix's LiveView turns out. It gives the "server side rendered, sprinkling of JS" approach more room to go in. It won't replace something like Google Maps, but there's a whole class of applications that would previously be on the border of the decision between react and server side that can be pushed into server side.
Re: Why I'm still using jQuery
#155Earlier quoted context omitted.
You have some pretty unidiomatic JS in there. For example: Array.prototype.filter.call(document.querySelectorAll(selector), filterFn); What's more idiomatic is document.querySelectorAll(selector).filter(filterFn) The same holds for forEach. I suggest you look into how javascript prototype based OOP works
.filter() is not a method on the NodeList though, it only has forEach(), and even that is quite recent. This is why people convert it to an array, and one of many reasons the standard JS API (and the DOM one in particular) are annoying to work with.
There are still more idiomatic methods you can use, ie:
[...document.querySelectorAll(selector)].filter(filterFn);Re: Why I'm still using jQuery
#156> In my experience server-side generated templates lightly sprinkled with “progressive enhancement”-style JavaScript are still the best way to do that. Those apps are easier to develop, tend to be faster, tend to have fewer bugs, and your laptop’s fan won’t wake the neighbours. Thanks for that part. Really. A heartfelt thank you. Every time I see another "hey, I only want to show you text, but for some reason I thoug…
Server-side rendering is the best front-end architecture at the moment. Superior first content paint and is better at SEO than SPA, and have a better architect than MVC. So in what way does if differ from traditional MVC? In MVC, the final output is HTML strings. Easy example: supposed you have an array of Posts in your controller, and a HTML template. The final result will be the combination of both of them. But whe…
If you need that array you could just embed a script tag in your html template.
Re: Why I'm still using jQuery
#157Earlier quoted context omitted.
> Had they learned vanilla javascript first Vanilla Javascript has nothing to do with DOM APIs. DOM APIs is just another interface/library/abstraction that you need to learn after you've learned JS. > If you learn jQuery today, you're not learning core JavaScript DOM APIs are not core Javascript.
You are right, but it's kind of beside the point given the context is web libraries. jQuery is built on top of the DOM API, so it's a library on top of an abstraction. It is just as simple to learn, so why not learn the core abstraction, with which all other DOM based abstractions are built from? jQuery will eventually go away while the DOM API is part of the web's core stack. Maybe it changes over time, but there wi…
> You are right, but it's kind of beside the point given the context is web libraries.
I don't think it is.
> so it's a library on top of an abstraction. It is just as simple to learn, so why not learn the core abstraction, with which all other DOM based abstractions are built from?
DOM APIs are not as easy to learn. They are verbose, cumbersome, inconsistent in behaviour and capabilities. Even the staunchest evangelists of the "use the platform" movement run head over heels to anything that frees them from DOM APIs [1].
There's nothing wrong with learning jQuery (or any of the other libraries or frameworks) first, and then learn the core APIs to see how stuff works (and run away in horror). However, they are not a prerequisite for "vanilla js" or "core JavaScript".
> jQuery will eventually go away while the DOM API is part of the web's core stack.
That's the end goal of jQuery: to become the disappearing library. That is, to become irrelevant when the capabilities it offers appear in the browsers themselves. However, this will never happen as long as w3c goes out of its way not to offer any APIs with a sensible developer experience.
----
[1] You can see it in Web Components where "use the platform" is immediately abandoned the moment lit-html hits the scene or Template Instantiation is proposed.
Re: Why I'm still using jQuery
#158Earlier quoted context omitted.
> Isn't that different reduced a lot with ES6+? ES6+ does not replace browser APIs. There's no ES6+ way around this: const el = document.createElement(...) el.setAttribute(...) el.classList.toggle(...) const parent = document.getElementById(...) parent.appendChild(el) You either do that in one line of jQuery, or end up writing your own wrappers if you need to do this more than once.
I personally prefer what you just outlined over jQuery. It's more explicit—that will almost always win with me.
That was simplified code to create just one element and add it to the DOM.
Once you write it not once, but twice, or five times, you will either switch to a lib/framework, or to jQuery, or will write your own wrapper not that different from jQuery.
Re: Why I'm still using jQuery
#159As someone who does application security assessments for a living, the biggest problem with jQuery is the lingering, outdated, vulnerable versions that are pervasive (1.x and 2.x in particular) in so many applications. I don't care if you decide to use jQuery or not, just have a plan to maintain it and be able to update it without breaking everything, should the need arise. /preaching
I'm curious - what are the types of vulnerabilities that lie in the client-side jQuery?
If you allow unchecked data to be stored & retrieved there are some XSS vulns in older versions. Ideally this would be prevented in a sane environment.
Re: Why I'm still using jQuery
#160Earlier quoted context omitted.
With $(el).next() you _can_ specify the next "what" if you chose, i.e $(el).next('span'). Otherwise it's next sibling, sort of how it appears. `Why is this a function and not a property of the object?` 1)Who cares? 2)Possibly because it's more than just getNextSibling as example above shows. So shorter syntax, more functionality, what's the fuss? 30kb?
element.querySelector('span') is the equivalent. Just as elegant, one fewer function call. 1) People like me care obviously. It's all bike-shedding anyway, so it's just a point of discussion. 2) nextSibling and nextElementSibling are two different properties, and you can't do the former in jQuery at all. In a typical usage you would need to do $('.my-class')[0].nextSibling, or in other words, dig down to the native D…
1. Significantly more functionality than a few edge cases you can no doubt come up with
2. Significantly improved developer experience. 10x reduction in boilerplate === less bugs.
3. Why not improve DX in the platform APIs?