Why I'm still using jQuery • Hacker News Board

Re: Why I'm still using jQuery

#181

Post by baddox » Mon, May 27, 2019, 5:13 PM UTC

macNchz wrote: post #129

iforgotpassword wrote: post #107

Earlier quoted context omitted.

> You're right, I should have been clearer. Emphasis on develop and maintain. Did you ever think that you might want to put the user experience first? Look at YouTube with their great SPA. If I'm on mobile and not using a flagship phone with 3gb of ram, it's just great: I scroll through my search results which are these idiotic incrementally loading page, then I select a video, watch it and want to go back. Surprise!…

This kind of terrible state management is super widespread and really annoying. I agree that lots of folks seem to have have spent the last few years thinking more about their build chain and tooling than about basic UX.

This specific example really just applies to all naive implementations of AJAX infinite scroll, which far predates the rise in popularity of SPAs.

Discourse, a forum written as a SPA in Ember, changes your URL as you scroll to each post. Even if you scroll down and let javascript load in more pages of content, the URL will reflect the post you’ve scrolled to, and will jump right to it if you go somewhere else then click Back, or just load the link:

https://discuss.emberjs.com/t/services-a-rumination-on-intro...

Re: Why I'm still using jQuery

#182

Post by munk-a » Mon, May 27, 2019, 5:13 PM UTC

52-6F-62 wrote: post #153

dmitriid wrote: post #89

Earlier 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.

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 the tradeoff of readability and expressiveness is accepted as correct code is always better than fast code - so why in the browser do we still demand the bare metal option?

[1] Okay, there are some people, they're rare and generally regarded as weird.

Re: Why I'm still using jQuery

#183

Post by raydev » Mon, May 27, 2019, 5:14 PM UTC

dmitriid wrote: post #158

52-6F-62 wrote: post #153

Earlier quoted context omitted.

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.

The reusable functions you need from jQuery likely don't justify jQuery's size. It's better to write or copy/paste wrappers for everything you need.

Re: Why I'm still using jQuery

#184

Post by baddox » Mon, May 27, 2019, 5:16 PM UTC

Carpetsmoker wrote: post #76

scrollaway wrote: post #55

Earlier quoted context omitted.

Has it occured to you you might simply not understand the advantages of this approach? There's a lot of crazy things in the world. Talk to a child about the economy or country borders and you'll realize how some things are just not straightforward to explain the advantages of. Serverside rendering in JS is no different to SSR in classic frameworks. You generate HTML serverside. Except in this case, you do it using Ja…

> So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. If it were, developers would not be flocking en masse towards SPAs and the like. Those are gaining traction because they are easier to develop and easier to maintain. Monumentally so. Let me put it this way, both as a developer and user of SPAs, I have long since observed that SPAs, on average, tend to be much more r…

Do you have an example of a “template app” that has anything even close to the actual feature complexity of an average SPA? Unless you control for that, I’d be willing to guess that the difference in bugginess is simply due to SPAs having a more complex set of features.

Re: Why I'm still using jQuery

#185

Post by austincheney » Mon, May 27, 2019, 5:19 PM UTC

losvedir wrote: post #150

austincheney wrote: post #70

Earlier quoted context omitted.

There are a lot of answers to that question, but they all summarize down to: you are the developer not the user . * Perhaps those 10 lines execute faster * Perhaps those 10 lines are exactly 10 lines, where jQuery is 2 lines plus a 65k library * Perhaps those 10 lines work equally in multiple environments (node, deno, electron, browser) where jQuery does not. * Perhaps those 10 lines sit behind a custom abstraction t…

> * Perhaps those 10 lines work equally in multiple environments (node, deno, electron, browser) where jQuery does not. Heh, and here we come full circle. I remember back when the whole point of jQuery was to handle the different underlying JS implementations for you.

Yeah, that always passed me off. I had little trouble writing cross browser code, but to be helpful jQuery would add code especially for IE that always got in the way when debugging cross browser compatibility problems.

Re: Why I'm still using jQuery

#186

Post by dentemple » Mon, May 27, 2019, 5:33 PM UTC

ape4 wrote: post #130

lewiscollard wrote: post #79

Earlier quoted context omitted.

It is a trick to coerce it to an integer. >> new Date() Date 2019-05-27T12:52:41.932Z >> +new Date() 1558961556913 >> +"4" // works on anything else :) 4

+ can concatenate strings. So I guess there is an implied: 0 + in there to make it in integer mode.

There's no implication involved. It's the unary operator, and it performs the type conversion exactly as specced.

Re: Why I'm still using jQuery

#187

Post by ehnto » Mon, May 27, 2019, 5:35 PM UTC

dmitriid wrote: post #157

ehnto wrote: post #113

Earlier quoted context omitted.

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 evangel…

> That's the end goal of jQuery: to become the disappearing library.

I guess my argument is simply that for the most part it's already happened, there is nothing particular scary about "jQuery style" general usage of the platform APIs.

Anything more complicated and I would prefer to enlist libraries other than jQuery. Drag and Drop, animation, AJAX, UI, all have libraries I would prefer. For anything less complicated I can just use what's currently in the platforms. For animation, CSS and class toggles are usually enough. Anything more complicated and there are better libraries for that.

> Even the staunchest evangelists of the "use the platform" movement run head over heels to anything that frees them from DOM API

Tongue in cheek but, that might make me the staunchest then, because I developed a workflow for using Web Components that uses only the spec, includes templating, data binding and is very simple. Shame it only works in firefox!

> There's nothing wrong with learning jQuery first

Practically speaking probably not, and you could make it through your entire career jumping from jQuery to React or Vue or whatever is next and never learn the platform APIs. I don't think there's anything wrong with that either. But if it's a hobby or your passion for web technology exists outside of work, I really do think you would be doing yourself a disservice not to thoroughly learn the platform.

Re: Why I'm still using jQuery

#188

Post by skizm » Mon, May 27, 2019, 5:40 PM UTC

austincheney wrote: post #70

skizm wrote: post #52

Earlier quoted context omitted.

Not really a struggle, but why would you want to type ten lines when two will do?

There are a lot of answers to that question, but they all summarize down to: you are the developer not the user . * Perhaps those 10 lines execute faster * Perhaps those 10 lines are exactly 10 lines, where jQuery is 2 lines plus a 65k library * Perhaps those 10 lines work equally in multiple environments (node, deno, electron, browser) where jQuery does not. * Perhaps those 10 lines sit behind a custom abstraction t…

I'm the user of the language, and JS is a bad user experience.

Re: Why I'm still using jQuery

#189

Post by umanage » Mon, May 27, 2019, 5:41 PM UTC

This is pretty much the reason I still use jQuery too. Although JavaScript now offers much of the jQuery functionality as built-ins, the very concise syntax that jQuery offers is more convenient to use.

Re: Why I'm still using jQuery

#190

Post by ehnto » Mon, May 27, 2019, 5:41 PM UTC

mythrwy wrote: post #171

ehnto wrote: post #138

Earlier quoted context omitted.

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…

element.querySelector('span') would work from parent but not sibling as $(element).next('span') does. You could certainly use that if you selected the parent, then did querySelector from parent (which for all I know is how $(el).next('span') works). So not equivalent, it's an extra step. And that's kind of the point I think. Instead of writing this stuff (with much longer syntax) over and over again, jQuery might be…

Yeah in JS that would be element.parentNode.querySelector('span').

I guess to me, that's not a bad thing. Verbosity is good, it's clear what's happening which leads to fewer unexpected outcomes.

What I have learned from this thread is that people don't really like the native versions of these kinds of things, whereas I think the above is much cleaner. It's not my place to say one is correct and one is false, and the popularity of jQuery speaks for itself. I am just one point of view.