> 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…
Why I'm still using jQuery
211–220 of 246 posts
Re: Why I'm still using jQuery
#212Earlier 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.
Re: Why I'm still using jQuery
#213`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
#214Earlier 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?
Re: Why I'm still using jQuery
#215> 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…
Re: Why I'm still using jQuery
#216To 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…
Nothing like jQuery's track record but they don't have the history yet to call on.
Re: Why I'm still using jQuery
#217Earlier 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.
Re: Why I'm still using jQuery
#218> 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…
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> 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…
There’s no other explanation.
Re: Why I'm still using jQuery
#220Earlier 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.