Someone should make a youmightnotneedspringboot.com
Well sure, you could do so much better with a small library like Vert.x (which I love). But getting an entire app framework with config/routing/db connectivity/etc is just so easy with Spring Boot. Plus, you get a vast ecosystem. Now the memory usage and compile times? Yeah, youmightnotneedspringsmemoryoverhead.
You might not need jQuery (2014)
41–50 of 241 posts
Re: You might not need jQuery (2014)
#42Earlier 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.
Dealing with those versions was where jQuery really earned its spot in the JS universe. It was a lot to remember where all the quirks were and the incantations to work around them.
Re: You might not need jQuery (2014)
#43Earlier 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.
In the real world, it turns out that code you didn't write can also have bugs or not behave as you expect it to, so the less of that there is, the better. 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.
Does jQuery (est. 2006) have more bugs in it than your code?
Re: You might not need jQuery (2014)
#44It'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.
For reference:
// JSON
const data = await (await fetch('/my-url')).json();
// Post
await fetch('/my-url', { method: 'POST', body: data });
// Request
try {
const resp = await fetch('/my-url');
// ...
} catch (e) {
// ...
}
// Fade In
el.animate({ opacity: 1 }, 400);
// Fade Out
el.animate({ opacity: 0 }, 400);
// Hide
el.hidden = true;
// Show
el.hidden = false;
// After
target.after(el);
// Append
target.append(el);
// Before
target.before(el);
// Each
for (const el of document.querySelectorAll(selector)) {
// ...
}
// Empty
el.replaceChildren(); // or el.textContent = '', depending on which you find clearer
// Filter
[...document.querySelectorAll(selector)].filter(filterFn);
// Get Height
el.clientHeight;
// Get Width
el.clientWidth;
// Matches
el.matches('.my-class');
// Remove
el.remove();
// Delegate
document.addEventListener(eventName, e => {
const match = e.target.closest(elementSelector);
if (match) {
handler.call(match, e);
}
});
// Trigger Custom
el.dispatchEvent(new CustomEvent('my-event', { detail: { some: 'data' } }));
// Trigger Native
el.dispatchEvent(new Event('change'));
// Extend
Object.assign({}, objA, objB);
// Parse HTML
(new DOMParser()).parseFromString(htmlString);
// Type
obj[Symbol.toStringTag];Re: You might not need jQuery (2014)
#45It'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.
This is all very old javascript to be fair, the modern equivalents are as terse as jquery these days.
Even the old jQuery seems easier to read than the modern ES6 equivalent (IMO).
jQuery:
$(".classname").addClass("darktheme")
ES6: document.querySelector(".classname").classList.add("darktheme")Re: You might not need jQuery (2014)
#46Earlier 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.
In the real world, it turns out that code you didn't write can also have bugs or not behave as you expect it to, so the less of that there is, the better. 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.
Re: You might not need jQuery (2014)
#47Earlier quoted context omitted.
I thought a big part of the initial sales pitch was not having to deal with cross-browser compatibility issues.
document.querySelector was not available in IE 6 and 7. Dealing with those versions was where jQuery really earned its spot in the JS universe. It was a lot to remember where all the quirks were and the incantations to work around them.
Re: You might not need jQuery (2014)
#48It'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.
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.
Yes, absolutely. That's a total no-brainer.
> Hidden complexity you don't control is the most expensive kind I think.
There's oodles of hidden complexity you don't control in any modern CPU, but most developers (rightly!) don't care. Complexity you have to fix bugs in is the expensive type, but IME you're far more likely to hit bugs in your custom implementation of whatever it was than in jQuery.
Re: You might not need jQuery (2014)
#49It'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.