201–210 of 246 posts
The thing that really got me to start thinking twice about jQuery, much more than the youmightnotneed... website, was this performance test for selectors — https://jsperf.com/getelementbyid-vs-queryselector/25
I didn't know about http://youmightnotneedjquery.com/ , but to me it seems very convincing that I need jQuery :)
Exactly. I know I don't need jQuery, but sometimes it's nice to be able to do stuff like make an ajax request as a one liner vs 10+ lines. Peoples gripes with jQuery come from people importing the entire library to do one thing, like add a class to an element. Sure, in that case it's dumb to load the entire library for that single purpose. But if you're using it for 5 things? 10 things? It quickly becomes worthwhile.
Earlier quoted context omitted.
Whether pagination is saved (like ?p=6 in url) doesn't have anything to do with SPA vs SSR. Just like an SSR /search endpoint that uses POST over GET so you can't just save/share the query. You're blaming SPA but as usual it's just people not caring about polishing application UX.
But in the YouTube case I don't even have pages! But anyways, When not going the SPA route I get all this for free. Navigating the search result pages automatically ends up in the history. 0 lines of Js required. Also since the whole page is generated server side even the scroll position within the result page is restored properly. Again 0 lines of Js. This already worked in the 90s. Today it doesn't, and we call it…
You could build even worse horrors using to update frames/iframes... partial page updates without javascript. This still lives on in some oracle web applications...
Earlier quoted context omitted.
.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);
If anything isn't that code _less_ idiomatic in that it's less specific to JS and more of a generic operation?
When you don't have to support Internet Explorer, using ES6 (fetch) is nice enough. When you need to support IE, it's best to use jQuery.
To give you an idea where I come from... I started doing front end in the late 90s, and for the past 5 or so years I've been mostly doing SPAs with Vue, React, Inferno, and Angular. I'm done with SPAs and the whole modern front end workflow. If there was a solid benefit to a SPA it would make sense to endure all the complex development, ever changing ecosystem, etc, but in the vast majority of cases there is no benef…
Earlier quoted context omitted.
So what was the struggle with vanilla js? I'm just curious :) One of the first things I learned in web development was jquery but right now I never use it. Even if I create a vanilla html/css/js website.
The fetch API is nowhere as convenient as the jQuery one. It requires craft to get addEventListener() on par with on(). jQuery comes with many implicits loops that save you time. fadeIn() is easier to handle than the equivalent css. jQuery supports edge if you target it (things like prepend(), parent() work on it). Error handling is just better. E.G: jQuery().val() will not raise an error if there is no match while d…
The fetch API is more powerful than the Jquery one.
Since forEach is implemented in es6 I just use that.
I see the point that you need it sometimes but still I would prefer some other lighter solutions.
Earlier quoted context omitted.
> It has failed spectacularly at that goal No, it allows apps to don't rerender whole page on every click, so it works just fine.
Yes. That should make it possible for such pages to be faster. In practice, the opposite is usually true.
> 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…
This is the part that often gets forgotten in these discussions: it shouldn't be "SPA for everything" vs. "vanilla HTML / CSS / JS for everything"; rather, we should be using the most appropriate set of tools for the job. I've worked on simple static sites, for which I typically lean more on vanilla HTML / CSS with a sprinkling of JS as recommended here. I've also worked on heavy-lifting applications, for which the l…
Earlier quoted context omitted.
I personally prefer what you just outlined over jQuery. It's more explicit—that will almost always win with me.
Browsers are an interesting place since the language we compile to there is generally human readable when compared to assembly lang/machine code but that "more explicit" is something that we've come to reject in general development so I'm curious why it's persisted in the browser world. People[1] don't reject C/C++ because they're putting two much distance between you and the bare metal assembly statements, instead t…
Explicit [within the context of the language]. And by that I did mean human readable.
const divElement = document.createElement("div");
divElement.textContent = "Hello world";
document.appendChild(divElement);
$(document).append("div").text("Hello, world");
function createTextElement(type: string, text: string): void {
const element = document.createElement(type);
element.textContent = text;
document.appendChild(element);
}
createTextElement("div", "Hello world");
Maybe it's just me, but I prefer the English, descriptive version and I prefer working with code formatted the same way. The language (JS) has plenty of quirks as it is.
Comparing C/Assembly I don't think is a 1:1 fair comparison, though. Unless you're including TypeScript—which is how I tend to write JS anyway (whenever possible).