Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I'm still using jQuery

arp242.net

Post reply on HN
Print view View original

131–140 of 246 posts

Re: Why I'm still using jQuery

#131

Post by asark »

EugeneOZ wrote: post #123
asark wrote: post #93

Earlier quoted context omitted.

Been here for just about all of this "web" thing. When I'm pleasantly surprised by how fast & light something is it's almost always server-side rendered or static. Only benefit of SPAs is that at least they're more likely to employ responsive layouts, but then they so often also manage to have bugs that break the page in certain layouts on certain browsers (overlays/modals are a biggie) that it's kinda a wash. And th…

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

Re: Why I'm still using jQuery

#132

Post by ehnto »

arp242 wrote: post #118
ehnto wrote: post #40

The given example of element.nextSibling is a great example of what jQuery gets wrong. In jQuery, that's going to be $(el).next(); On first encountering $(el).next(), you need to answer a bunch of questions. Next what? Why is this a function and not a property of the object? Why not call it getNextSibling? What the hell is $() doing? element.nextSibling is very clear. It's the next sibling of the element. It's idioma…

> element.nextSibling is very clear. It's the next sibling of the element. It's idiomatic javascript, and it follows a good naming convention, which is a skill that is language agnostic. The only catch here is that it will give you the wrong answer, and that you should (almost) never use it since it includes whitespace nodes, which you practically never want. This is why nextElementSibling exists (get the next siblin…

> The only catch here is that it will give you the wrong answer, and that you should (almost) never use it since it includes whitespace nodes

But that's perfect, because it does what it says. If I wanted to get the next element only I would used the correctly named nextElementSibling. How do you get the next text node sibling in jQuery?

> Your assumptions about my knowledge couldn't be more wrong.

My apologies. I was reading between the lines and I guess I got it wrong.

> This is just a variant of the old "kids these days...

Not at all, it's advice for the future of the web which will be more plain javascript based but within frameworks like React and Vue. They're grabbing more and more of the job market share. I am being pragmatic here, knowing jQuery won't help you navigate the world the "kids" are busy building right now with frontend SPA frameworks.

jQuery obviously has it's place, and if you prefer using it then no one can stop you. I just don't agree that it's better, and I don't believe it's as useful to know for new developers with the way the industry is changing.

Re: Why I'm still using jQuery

#133

Post by threatofrain »

arnvald wrote: post #68
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…

> Has it occured to you you might simply not understand the advantages of this approach? I find it pretty rude to use the "you don't like it because you don't understand it" argument. I build SPAs at work, I know their benefits, and I still believe that they're more difficult to develop than adding JS on top of classic HTML (not saying they're worse, but certainly I don't find them easier). > So when the author says…

Even the auto-frameworking approaches are starting to surpass old school web development for "classical" web purposes. I can tell when I'm on a static documentation site and things work almost instantly. JavaScript is both the reason why some websites feel faster and other websites feel slower.

I also think that being nice to mobile (data efficiency) and being fast (UX latency) are starting to show as moderately contradictory values.

Re: Why I'm still using jQuery

#134

Post by h1d »

cptrp2101 wrote: post #47

I think, as with anything else, it's important we understand the tools we are using. I started with jQuery and the problem was (like many others) I learned it before I actually learned javascript. I've since backtracked and dug into vanilla JS so I can have a better understanding of what my code does. Since then, I haven't found a situation where I miss jQuery. However, I don't damn anyone who uses it (beyond jokey a…

You will soon come back to using jQuery again thinking what the point of just saving 30KB by letting your code become longer.

Re: Why I'm still using jQuery

#135

Post by h1d »

masswerk wrote: post #69

Something seldom considered while discussing the use of libraries and frameworks: green computing. Mind that you're multiplying any overhead thousandfold or even millionfold when transferring the overhead to each client connecting to the service (including several instances of network infrastructure). So,"how much effort it can be to use vanilla JS", – it may be well worth the extra effort, once, on a single side of…

Your assumption that everyone can write more efficient code than jQuery isn't making sense.

Re: Why I'm still using jQuery

#136

Post by unfunco »

> Pages like You might not need jQuery try to sell the idea that it’s easy to ditch jQuery, but the very first example is a good reason to use jQuery: one line of trivial jQuery code gets replaced with 10 lines of vanilla JS code!

There's no such thing as one line of jQuery, it's 10K lines before you add your one line to do that one thing that 10 lines of vanilla JS code can do.

Re: Why I'm still using jQuery

#137

Post by ds_ »

saltminer wrote: post #117
sgift wrote: post #33

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

The worst I've seen is where the main content is served (if you curl the website, you can see the text content is there), but it's hidden by a full-page loading animation which is removed by JS.

AMP? (https://amp.dev/documentation/guides-and-tutorials/learn/spe...)

Re: Why I'm still using jQuery

#138

Post by ehnto »

mythrwy wrote: post #119
ehnto wrote: post #40

The given example of element.nextSibling is a great example of what jQuery gets wrong. In jQuery, that's going to be $(el).next(); On first encountering $(el).next(), you need to answer a bunch of questions. Next what? Why is this a function and not a property of the object? Why not call it getNextSibling? What the hell is $() doing? element.nextSibling is very clear. It's the next sibling of the element. It's idioma…

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 DOM API anyway.

So less functionality, less clear syntax, 30kb!

Re: Why I'm still using jQuery

#139

Post by jlg23 »

scrollaway wrote: post #55
sgift wrote: post #33

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

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…

> Has it occured to you you might simply not understand the advantages of this approach?

> Putting aside how useful it is to only have one language to learn in a stack...

Glad we are not talking about this - I'd have to point out that "I do not have to learn/understand" is a bad continuation when one starts with the claim the other was ignorant.

Re: Why I'm still using jQuery

#140

Post by masswerk »

h1d wrote: post #135
masswerk wrote: post #69

Something seldom considered while discussing the use of libraries and frameworks: green computing. Mind that you're multiplying any overhead thousandfold or even millionfold when transferring the overhead to each client connecting to the service (including several instances of network infrastructure). So,"how much effort it can be to use vanilla JS", – it may be well worth the extra effort, once, on a single side of…

Your assumption that everyone can write more efficient code than jQuery isn't making sense.

It's certainly a matter of balance: if you need just a simple functionality or a single effect, loading (and compiling) the entirety of jQuery may not be the wisest. Similarly, I've seen d3.js loaded just to get a canvas element by 4 lines of code, where a single vanilla line would have done.

(Edit: Notably, my argument was about the effort involved.)

Post reply on HN