
How to avoid common SPA pitfalls when using third-party plugins - gandalfar
https://blog.isleofcode.com/the-real-reason-to-avoid-jquery/
======
unit91
I liked his examples, though I disagree with his conclusion (don't use
jQuery). It seems like the real conclusions are:

1\. understand the language you're using (this would solve the `bind`
examples); and

2\. learn how to use your libraries properly.

Otherwise, the "don't use $TOOL, because misuse can cause $BAD_THINGS" line of
thinking is nearly limitless in its application (jQuery, cars, circular saws,
...).

~~~
runspired
Author here:

I whole heartedly agree, which is why with each point I made I did more than
just list what was bad, but how to do better, even with jQuery. The real
reason not to use jQuery isn't because jQuery is bad, it is because as a tool
it / it's ecosystem is poorly prepared for dynamic html, so if you are going
to use it, you need to know the limitations and challenges it brings.

~~~
dsp1234
It's certainly nice to see the rationale behind your decisions. However, most
of them just turn out to be something along the lines of "understand
javascript and the DOM", and not really about jquery at all.

For example:

 _" To be fair, this is no different than cacheing an element or array of
elements on your own, and forgetting to de-reference it later when you are
done"_

or the examples about attaching/detaching event listeners where the
hypothetical developer is gathering elements by the equivalent of
document.getElementsByClassName. If a developer is going to make that kind of
mistake, then that's an error that's going to occur regardless of the
framework.

There are certainly reasons to not use jquery in some cases, but this article
seems a bit too much like "Do good development, don't do bad development".
Drop jquery from the body of the content and the title, and the lesson will
still be the same.

------
jonesb6
Most of OP's complaints come from the misuse of JQuery, including compounded
performance issues when paired with a SPA framework (in this case Ember, which
IIRC has a dependency on JQuery either way). Slow + Slow = More slow.

Honestly it's a library. Use it, don't use it, replace it, it honestly isn't
worth a million identical arguments. People like to use JQuery as a microcosm
for bad javascript practices but guess what JQuery didn't make you do it! It's
just a library.

There is no real reason to avoid JQuery. Sure you should, as a good developer,
explore alternative solutions for different problem sets. Maybe those
alternatives become the standard for your team, maybe they don't. But unless
you made a meaningful discovery that can add to the conversation, you don't
need to make another blog post about it. Ugh.

~~~
unit91
> But unless you made a meaningful discovery that can add to the
> conversation...

I don't think this applies here. Personally, I learned something from two of
his examples, bookmarked the page, and will refactor accordingly. I'll hazard
a guess that a few others are in the same boat -- by that standard, the
article seems pretty meaningful to me.

~~~
manyxcxi
Totally agree. I get people love to bash on whatever, but the author actually
taught me a few things I didn't know. Well written, good examples of bad and
better ways of doing things, I think this provided meaningful information.

------
Bahamut
Most of the advice sound like basic JavaScript - avoid things that prevent the
interpreter from garbage collecting.

~~~
runspired
A lot of it is, but I spend so much time teaching people how to CPU Profile,
take heap snapshots, diagnose leaks..

Things that _ought_ to be fundamental, but which were left unlearned while the
web was allowed to be lazy. With static pages, GC concerns weren't very large,
because soon enough the user is going to click ahead to a new page and wipe
the slate anyway.

~~~
sotojuan
I'm coming up on a year of knowing JS and none of the recommended beginner
resources or books ever mention performance or profiling. It seems to just not
be taught. On /r/javascript and other forums I do not see it mentioned often
as it's assumed the library or framework takes care of it.

I'll take the opportunity now and ask for good resources on JS performance,
garbage collection, and profiling. I realize I know the syntax and semantics
well (and a framework or two), but not enough about optimization and related
stuff (like ServiceWorker).

~~~
runspired
This is the place to start:
[https://developer.chrome.com/devtools/docs/javascript-
memory...](https://developer.chrome.com/devtools/docs/javascript-memory-
profiling)

------
GavinMcG
What was the fake reason to avoid jQuery?

~~~
wernercd
What was the fake reason for not reading-the-freaking-article yourself?

~~~
GavinMcG
I did. The only hints were in the opening paragraphs, and they were just
hints:

> "I've read countless blog posts, twitter rants and medium exposés detailing
> how jQuery isn't necessary, and why you should just write with "native"
> JavaScript."

Not reasons.

> "There is, however, a very major reason to avoid jQuery, and it has very
> little to do with features or file-size."

File-size? Ok. But "features" isn't a reason, without fleshing out.

------
SimeVidas
“ _Some people_ write crappy jQuery code → jQuery is bad for _you_.” Never
gets old :P

------
EugeneOZ
jQuery is not jQuery plugins. It's ... not smart to write about them like it
is one monolith thing.

~~~
runspired
... this is about both. And for most devs, they are the same thing. The
difference is poorly understood.

------
frandroid
I think the title is a bit short. It should have been "The real reason to
avoid jQuery with SPA frameworks".

~~~
dang
It's a bit baity, so we changed it to the subtitle.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

~~~
runspired
I wasn't expecting this to be a "thing", I wrote it for people I help out in
the Ember community that struggle because of their jQuery background. I may
update the title now that this is more widespread.

~~~
dang
It's common for something that works well in its original context to turn into
something unintended under the pressure of the HN firehose. Sort of a tragedy-
of-the-commons variation.

------
WA
tl;dr: Use jQuery + plugins, if you want to do some small UI improvements in
JavaScript and don't make it too complicated.

Learn a lot more about jQuery, if you write complex JS applications (like
single-page apps) with the help of jQuery.

~~~
blhack
<offtopic>

I feel like SPAs are one of the most abused concepts on the internet right
now.

A cloud-based 3D modeling software? Yeah, that _definitely_ needs to be some
form of SPA.

Your twitter clone, blogging engine, etc. not only doesn't have to be an SPA,
but _shouldn 't_ be one because it creates horrendous UX.

~~~
samizdatum
SPAs don't need to have horrendous UX?

~~~
blhack
Sure they don't, but saying that you are going to force logically separate
pages onto a _single_ page is starting from a point of bad UX and trying to
dig yourself out of it.

~~~
samizdatum
In theory, the only irreducible UX distinction surrounding logically separate
pages in a traditional website vs a SPA is that the SPA doesn't do the full
postback, which is arguably a better UX.

Sure, in practice many SPAs might be subpar, but then the debate shifts to
"are SPAs are difficult to implement correctly," rather than "SPAs for
blogging engines (necessarily) creates horrendous UX". There are existence
proofs of well-designed SPAs with logically separate pages and excellent UX.

As an aside, someone who pattern matches on "SPA = horrendous UX" might not
even notice a well-designed SPA, further entrenching their belief that SPAs
are a Bad Idea from a UX perspective!

------
ars
None of this is about jQuery - you can have the exact same problems in native
JavaScript.

This page should be titled: "Don't forget to delete unused JavaScript things
(nodes, events, etc)".

------
Khao
The real reason to avoid single page apps.

~~~
lolc
"The real reason to avoid JavaScript"

Ooops, wrong decade

~~~
runspired
Using static pages just so you can avoid writing good code seems smart..

~~~
dasil003
Running code is very powerful, but the real power over the long haul is
running the least amount of code necessary to get the job done.

