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

111–120 of 246 posts

Re: Why I'm still using jQuery

#111

Post by scrollaway »

iforgotpassword wrote: post #107
scrollaway wrote: post #83

Earlier quoted context omitted.

> 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). You're right, I should have been clearer. Emphasis on develop and maintain . If you're just building a near-static site with, say, some slideshow that needs basic JS then I'd use jQuery too. I'm sure there's a bazillion plugins that already do what I want a…

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

> Did you ever think that you might want to put the user experience first?

As I've repeatedly explained in the comments, I'm not arguing that you should use an SPA, and I'm not arguing that SPAs have necessarily better UX. You still have to be a good dev.

SPAs are not footgun-protections and the issues you're listing are fairly easily solved. Maybe they're not natively solved by SPAs, but other approaches also have their natively-unsolved problems, so this is moot.

> But I guess once we kill Firefox this will become much better since Google will just do whatever the duck they want with the web.

I don't even know what you're on about or how it relates to this discussion. Did you mean to post this on a different article?

Re: Why I'm still using jQuery

#112

Post by madeofpalk »

iforgotpassword wrote: post #107
scrollaway wrote: post #83

Earlier quoted context omitted.

> 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). You're right, I should have been clearer. Emphasis on develop and maintain . If you're just building a near-static site with, say, some slideshow that needs basic JS then I'd use jQuery too. I'm sure there's a bazillion plugins that already do what I want a…

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

> Did you ever think that you might want to put the user experience first?

I like react for SPA because it means It makes it easy to build a pretty solid user experience. The best example I had was when I was building the login + info portal for inflight wifi. We used server-side rendered React to give them an operational page without JS, and then enhanced it when the JS loaded in, and then precached additional content to make the pages load instantly.

The react + webpack ecosystem made this _really_ easy. Inlining the critical css for the base type + login form was stupid simple.

At the end of the day, there are lots of tools and its up to developers to find the best tools for the job. Sometimes, developers make the right choice. Other times, developers make the wrong choice. If you have a dysfunctional team/org, you're probably not going to build much great regardless of the tools you choose.

Re: Why I'm still using jQuery

#113

Post by ehnto »

dmitriid wrote: post #92
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…

> 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 will likely be a DOM API as long as there are HTML based browsers.

Re: Why I'm still using jQuery

#114

Post by arp242 »

indocomsoft wrote: post #85
JaTochNietDan wrote: post #12

I'm heavily inclined to agree with this. In fact, only this weekend I was working on a very simple one page tool and from the get-go I decided to adopt this "vanilla" only approach, i.e no JS libraries really at all. Pretty quickly I found myself wishing I had just used jQuery or at least some other library to make stuff easier and get things done faster. When I finally got it completed in the end I wasn't sure why I…

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.

Re: Why I'm still using jQuery

#115

Post by diffeomorphism »

asadkn wrote: post #65
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…

> If it were, developers would not be flocking en masse towards SPAs and the like. Argumentum ad populum. That's not an indicator of something being better. I do like using the modern SPA frameworks for well, (web)apps but I strongly disagree with using them in every case.

> Argumentum ad populum. That's not an indicator of something being better.

And that was not claimed. The point made was that they are _popular_ because they are "easy"; no comment on being "better".

Re: Why I'm still using jQuery

#116

Post by kangoo1707 »

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…

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 when the HTML strings get sent to browser, you lose the array !!! It's gone. The client never receives an actual array, just DOM nodes.

In Front-end framework SSR (NextJS or NuxtJS), what you work with is a component. A component can have data (an array), and the data is pushed (serialize) as-is to browsers. On the browser, you won't ever have to work with low level DOM nodes. You continue to see the component and data in its original form. This is the biggest win of SSR that is easily overlooked.

Re: Why I'm still using jQuery

#117

Post by saltminer »

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.

Re: Why I'm still using jQuery

#118

Post by arp242 »

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 sibling that is an element).

As for the naming: this is an old old discussion we will never agree on, but I think that in the context of a DOM traversal library "next" is pretty clear.

> The author is also conflating their time learning as a pro for jQuery. Had they learned vanilla javascript first, their point about not knowing which nextSibling to use would be moot.

Your assumptions about my knowledge couldn't be more wrong. I spent years writing plain JavaScript. I even wrote a jQuery alternative back in the day as I didn't like various aspects of it (I think I was the only user), before giving in and "just using jQuery". I still don't like those same aspects, but it's not bad enough to use something else.

I have also, recently, tried very hard to use plain JS, and this post is the result.

> if you are a new developer do yourself a favor and learn the foundation it's built on first.

This is just a variant of the old "kids these days, they just learn Python instead of REAL development with C, they don't even know the difference between the stack and heap!!" Okay, shrug. In the meanwhile, those "kids" are solving real problems, so well... Programming isn't some kind of intellectual exercise, it's a tool to solve problems.

Re: Why I'm still using jQuery

#119

Post by mythrwy »

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?

Re: Why I'm still using jQuery

#120

Post by iforgotpassword »

scrollaway wrote: post #111
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!…

> Did you ever think that you might want to put the user experience first? As I've repeatedly explained in the comments, I'm not arguing that you should use an SPA, and I'm not arguing that SPAs have necessarily better UX. You still have to be a good dev. SPAs are not footgun-protections and the issues you're listing are fairly easily solved. Maybe they're not natively solved by SPAs, but other approaches also have t…

> I don't even know what you're on about or how it relates to this discussion. Did you mean to post this on a different article?

Nope, that was just a small addendum in relation to my example since experience has shown that often times the back button is broken in different ways depending on browser. Having just one engine left would at least mean some more consistency here, but that's about the only advantage I can see in that.

Post reply on HN