Live data from Hacker News

Why I'm still using jQuery

arp242.net

211–220 of 246 posts

Re: Why I'm still using jQuery

#211
post #125
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…

I've made quite complex web apps with pure CDN-imported (i.e. no Webpack/NPM) Vue as a starting point. They work well, are easier to debug, and get the job done faster. Of course, it's a good idea to take that monolithic JS file and split it up into components for easier future work, but I've found that working like this leads to fewer "tooling hell" headaches.

Re: Why I'm still using jQuery

#212
post #130

Earlier quoted context omitted.

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

TIL, https://scotch.io/tutorials/javascript-unary-operators-simpl...

Re: Why I'm still using jQuery

#213
Hardest part to get rid of jQuery was the $.ajax function. Happily now, we can all use the fetch API with some extra polyfills, but pretty much that's it.

`el.insertAdjacentElement`, really? Yeah if you carry jQuery thinking with you, you will probably want to translate the code literally and find substitute for everything. No... You can just use to recreate the part of the DOM that needs to be updated and replace it. It's faster to write and easier to read.

Anyway most of the arguments are not considering, vanilla JS + webpack / babel es6 + npm packages. In a world where side-effects are not well accepted anymore using jQuery is nightmare to maintain.

What's this fuzz about btw, I thought this argument was over?

Re: Why I'm still using jQuery

#214
post #204

Earlier quoted context omitted.

There are still more idiomatic methods you can use, ie: [...document.querySelectorAll(selector)].filter(filterFn);

That's a significantly newer syntax, so I wouldn't say it's "more idiomatic" than explicitly referencing the original function on the prototype (which is idiomatic to JS) and was the way to do it until the spread proposal, Array.from, and similar additions, what, ~5 years ago? If anything isn't that code _less_ idiomatic in that it's less specific to JS and more of a generic operation?

In this instance I understood it to be idiomatic as it calls a JS Array constructor and iterates on the passed parameter to create it. It's been more common than the call/apply methods for years—at least as far as I've seen. The use of the array literal is always preferred, AFAIU.

Re: Why I'm still using jQuery

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

Elixir/Phoenix’s new LiveView seems to really hit this sweet spot

Re: Why I'm still using jQuery

#216
post #143

To give you an idea where I come from... I started doing front end in the late 90s, and for the past 5 or so years I've been mostly doing SPAs with Vue, React, Inferno, and Angular. I'm done with SPAs and the whole modern front end workflow. If there was a solid benefit to a SPA it would make sense to endure all the complex development, ever changing ecosystem, etc, but in the vast majority of cases there is no benef…

Vue gets that part pretty right at least, they work hard not to break things unnecessarily across versions and never in version (in my experience).

Nothing like jQuery's track record but they don't have the history yet to call on.

Re: Why I'm still using jQuery

#217
post #188

Earlier quoted context omitted.

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

So you are the primary end user of everything you write in JavaScript? I think you are deliberately being hyperbolic to justify ignoring micro improvements to end user concerns for a self-serving convenience.

I realize you're just being argumentative, but whatever. As a programmer you should definitely be avoiding micro improvements until you absolutely need them. Premature optimization is the root of all evil. No sense in wasting development time with something that is currently not a problem.

Re: Why I'm still using jQuery

#218
post #125
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…

AT&T’s website account pages only serve static html. But they are rendered by js and I have to wait looking at a loader after every click.

Why is that?

Why do so many static websites and blogs use SPA technology for all their pages?

It can’t be that it’s just to make me mad (although it works). Are people insane? How does spending 10x the $ and effort for a worse result make sense?

Re: Why I'm still using jQuery

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

If all the cool kids are doing a thing, you have to do that thing else you’re not a cool kid.

There’s no other explanation.

Re: Why I'm still using jQuery

#220
post #217

Earlier quoted context omitted.

So you are the primary end user of everything you write in JavaScript? I think you are deliberately being hyperbolic to justify ignoring micro improvements to end user concerns for a self-serving convenience.

I realize you're just being argumentative, but whatever. As a programmer you should definitely be avoiding micro improvements until you absolutely need them. Premature optimization is the root of all evil. No sense in wasting development time with something that is currently not a problem.

I was not being just argumentative and I absolutely disagree about product improvement. Product improvement is refinement which is absolutely not premature optimization. I honestly believe you are fishing for excuses to qualify mediocrity whether for laziness or fear of the code.
Post reply on HN