Live data from Hacker News

Why I'm still using jQuery

arp242.net

81–90 of 246 posts

Re: Why I'm still using jQuery

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

We have multiple languages in the first place because each language is good at some specific thing.

Sure, for lightweight development it’s not bad. But, that stack is highly optimized for a specific kind of problem and is extremely limiting.

Re: Why I'm still using jQuery

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

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

Bandwagon fallacy. In all fairness popularity is never a qualified descriptor of competence or performance.

Re: Why I'm still using jQuery

#83
post #68

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…

> 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 and it'll be done in 5 minutes.

But if you're building something that will scale beyond the current page, that will need more features in the future, etc then it's not a viable approach. And I'm not saying SPAs are necessarily the best choice/tool available, but they're definitely going to be easier to work with than HTML+jQuery, unless the requirements are ridiculously basic.

> I'd say that we, developers, often move to overcomplicated and difficult tools/approaches. Or we move to tools that are simple only to see them grow in size and complexity. The fact that something becomes popular doesn't mean that it's necessarily better or easier to maintain.

Lots of devs adopt technologies for fun; because the approach is interesting; because they want to learn; because they're bored with their current stack.

But this is different. This is a huge movement within the ecosystem moving towards a very specific model. The model is not necessarily the best in every situation, but the pros that come with it are significant.

And honestly, nowadays in modern browser JS, if an app is simple enough to build with jQuery, it's simple enough to build without any third party lib.

Re: Why I'm still using jQuery

#84

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…

I have no claims that SPAs are better end-user experiences out of the box. Your quote is about how easy it is to develop and maintain an SPA, not how good users have it after the fact (which entirely depends on how good your team is at building the app).

I'm starting to think I need to clarify that paragraph :/

Re: Why I'm still using jQuery

#85

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

Re: Why I'm still using jQuery

#86
post #65

Earlier quoted context omitted.

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

This has nothing to do with an "Argumentum ad populum". I'm saying devs are flocking towards it because it's a lot easier to work with and maintain. There's a lot of reasons why this is true. One is using a single programming language. Another is having the server app be aware of the entire app rendering rather than just templating-in bits and pieces. I could go on but that's not the point I'm trying to make.

> I'm saying devs are flocking towards it because it's a lot easier to work with and maintain.

Two things: first, my experience (and perhaps definition) of "easy" is different. I wrote an entire different post about that[1], but the tl;dr is that SPA may be easy to make things with, but it's hard to debug things, which is a more important measure of "easy" IMHO.

Another example would be accessibility (screen readers, etc.) Last time I tried, it was much harder to get that right with SPAs (not impossible, just hard).

Second point is that there are many other factors than "easy to work with and maintain". I already mentioned some of that in my other reply.

[1]: https://arp242.net/easy.html

Re: Why I'm still using jQuery

#87

Earlier quoted context omitted.

SPA is by million times better than "classic template-driven" trash. I don't just "think" so, I have 7 years of experience with "classic templates" and 8 years with SPA.

Anyone can throw out a better-because-of-experience answer, and in fact I’ll do so now: I also have 15 years of experience in front-end dev and I disagree with your premise. It completely depends on what you’re trying to build, and SPAs are too heavily used at the light-interactivity end of the scale. We’re failing our users with brittle solutions that make us feel cleverer as developers.

Well, literally not anyone can "throw" such argument, only those who actually has an experience :) How many years of these 15 you are building SPApps?

It's ok to disagree. I'm in a camp "API + SPA" after my experience. I know as fact that you can greatly increase UI performance this way and build multiple apps (desktop, mobile, web) using single API.

So argument "I just think so" is totally not an argument for me.

Re: Why I'm still using jQuery

#88
post #48

Earlier quoted context omitted.

SPA is by million times better than "classic template-driven" trash. I don't just "think" so, I have 7 years of experience with "classic templates" and 8 years with SPA.

Oh great Eugene, do humble us with your knowledge. What makes an SPA a great choice?

You forgot "your grace".

Re: Why I'm still using jQuery

#89
post #52

Earlier quoted context omitted.

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

Isn't that different reduced a lot with ES6+? By adding jQuery load time increase by almost a second or two

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

Re: Why I'm still using jQuery

#90

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

I didn't make the site, it's a fork of the original website by Hubspot.
Post reply on HN