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

171–180 of 246 posts

Re: Why I'm still using jQuery

#171

Post by mythrwy »

ehnto wrote: post #138
mythrwy wrote: post #119

Earlier quoted context omitted.

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 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 better for casual web dev. Still. In 2019.

But whatever works for you. If you don't like it cool.

Re: Why I'm still using jQuery

#172

Post by Bahamut »

h1d wrote: post #134
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.

Doubtful - 30 kB minified & gzipped is a lot of code, and the fact that jQuery doesn't help with your code organization/keeping code DRY much is a huge negative.

Re: Why I'm still using jQuery

#173

Post by baddox »

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…

Of course I agree that if you’re only showing text with a few interactive enhancements, you can probably get away with jquery. The trouble is that too often a few enhancements turns into a few more enhancements, then a lot of enhancements, and then you end up with a huge mess of jquery spaghetti. It quickly becomes comical to claim that jquery would result in fewer bugs than pretty much any post-backbone UI library or framework you can think of.

Re: Why I'm still using jQuery

#174

Post by baddox »

rbanffy wrote: post #103
Tade0 wrote: post #99

Earlier quoted context omitted.

This is some special kind of madness and I wonder when it will stop. There's light at the end of this tunnel in the form of compilers like Svelte or Stencil.js replacing frameworks. The improvement here is that since there's no special runtime the bundles are very small, so there isn't a lot of JS to parse. Also the code you have to write is much shorter comparing to frameworks.

> There's light at the end of this tunnel in the form of compilers like Svelte or Stencil.js replacing frameworks. I am a bit skeptical that adding more complexity to something that's already much more complex than it should can be a solution.

What are you saying that Svelte or Stencil are adding to? They are both complete toolchains.

Re: Why I'm still using jQuery

#175

Post by baddox »

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…

Do you believe that SPAs are more difficult to build than building the same functionality with server-rendered HTML and jquery on top?

In my experience, that would only be true in the most trivial of SPAs. I’m thinking like a blog with AJAX “like” buttons. A good rule of thumb for me is that as soon as you have some interactive widget that involves adding and removing items from a list where the individual items also change interactively, you’re probably better off ditching jquery because things are about to get messy.

Re: Why I'm still using jQuery

#176

Post by brightball »

candu wrote: post #125
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…

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…

Yep. This is one of the reasons that so many people are excited about Phoenix Live View being released. It bridges that gap much farther and let’s you avoid the SPA until you hit the “is absolutely necessary” point.

Re: Why I'm still using jQuery

#177

Post by 52-6F-62 »

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.

Not for something so simple. It's trivial to abstract small, oft-repeated actions like that to their own function. As I do, regularly. And then I can give it a readable name, like `createElement` or `insertElement` with an interface like:

    insertElement(type: string, text?: string. attributes?: object, parent?: string): void;
I prefer writing something like that with some minor case-handling over pulling in a library every time I meet a repeatable fragment.

If I know I'm going to run into a large host of needs, then it's a different story. But most of the time I find jQuery overkill and somewhat opaque.

Re: Why I'm still using jQuery

#178

Post by scruple »

jabart wrote: post #124
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…

Currently dealing with a situation where a SPA app doesn't work with FB Sharing, because it exepects a set of META/Open Graph tags. So now we are going back to rendering a portion of the HTML on the server to support this. In JIRA, if I hit enter in the wrong field, it does a post out to somewhere and returns me a weird xml page and I lose my work. SPA apps are like building a browser, in a browser, and on the server…

JIRA is a case study in bad UI/UX and web anti-patterns, IMHO. I think my team at work is finally ready to ditch it in favor of basically anything else.

Re: Why I'm still using jQuery

#179

Post by brightball »

Bahamut wrote: post #148
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…

I've seen the flip side of the coin in an app I inherited at work - it turns out server-side rendering can be significantly slower than client side rendering if you're rendering a lot of content, to the point where we hit an automatic timeout. If this app was a fat JS app, we probably wouldn't be trying to decommission it & it probably would load in seconds at worst, but the investment to modernize it/improve perform…

That’s true in a lot of cases mainly because of the approach to rendering. So many languages focus on rendering the entire HTML structure before sending the first byte back, specifically so that the page can be wrapped in a cache. This forces a lot of memory allocation to build up strings and parts of strings that takes time on its own, is often repetitive over the same HTML tags and then all of that has to be garbage collected at the end of the request.

The approach taken by Elixir’s Phoenix framework is so fast because it avoids all of those pitfalls. Most people have to do a double take when they see the speed comparisons.

Here’s a great write up: https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2...

Re: Why I'm still using jQuery

#180

Post by antihero »

andybak wrote: post #149
macNchz wrote: post #129

Earlier quoted context omitted.

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.

> 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 might be the best summary of how I feel about web development that I've read in a fair while.

And this is why I like Parcel. It's by no means perfect but having pretty much zero config and still being able to jump into using pretty much whether system you want with a simple command is nice.

Frankly I thought jQuery was a horrific way of building stuff, and moving to a declarative approach like React is a huge step forward. Most complaints I've seen about it are due to incompetence or misunderstanding.

Post reply on HN