How to avoid common SPA pitfalls when using third-party plugins(blog.isleofcode.com)
blog.isleofcode.com
How to avoid common SPA pitfalls when using third-party plugins
https://blog.isleofcode.com/the-real-reason-to-avoid-jquery/
40 comments
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.
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.
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.
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.
[deleted]
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.
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.
> 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.
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.
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.
Yes, some of this is from the misuse of jQuery. But I fix that misuse a lot, so I felt it needed explicitly pointed out.
But many of these complaints have nothing to do with misuse and everything to do with either a lack of awareness about selector consequences, or a decade of built up code debt in the jQuery plugin ecosystem.
All of these examples are true for all JS frameworks, even non-SPA frameworks. Dynamic DOM is a problem for code that wasn't designed to clean up.
There is a real reason to avoid jQuery, that reason is that you want your app to work well. Blindly reaching for a tool from the static age will bite you.
> 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.
Guessing this is yours ;)
But many of these complaints have nothing to do with misuse and everything to do with either a lack of awareness about selector consequences, or a decade of built up code debt in the jQuery plugin ecosystem.
All of these examples are true for all JS frameworks, even non-SPA frameworks. Dynamic DOM is a problem for code that wasn't designed to clean up.
There is a real reason to avoid jQuery, that reason is that you want your app to work well. Blindly reaching for a tool from the static age will bite you.
> 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.
Guessing this is yours ;)
My reply was a little rough. I just get frustrated because I remember when I was 'new' and would've taken articles such as this as sacrosanct.
I just think we have to be careful whenever we say "this is bad, do this instead" because people will often inherently believe you and pass it on.
I just think we have to be careful whenever we say "this is bad, do this instead" because people will often inherently believe you and pass it on.
Most of the advice sound like basic JavaScript - avoid things that prevent the interpreter from garbage collecting.
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.
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.
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).
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).
This is the place to start: https://developer.chrome.com/devtools/docs/javascript-memory...
The problem is partly education, but partly that many companies won't pay for "good"... not compared to "delivered quick", "cheap cost", or "bullet-pointable features".
"Profiling? What are you messing around with those random toys for? We need to make the buttons rounded!"
"Profiling? What are you messing around with those random toys for? We need to make the buttons rounded!"
What was the fake reason to avoid jQuery?
What was the fake reason for not reading-the-freaking-article yourself?
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.
> "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.
"libraries are bad"
“Some people write crappy jQuery code → jQuery is bad for you.” Never gets old :P
I think the title is a bit short. It should have been "The real reason to avoid jQuery with SPA frameworks".
It's a bit baity, so we changed it to the subtitle.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
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.
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.
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.
Learn a lot more about jQuery, if you write complex JS applications (like single-page apps) with the help of jQuery.
<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.
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.
SPAs don't need to have horrendous UX?
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.
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!
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!
SPAs for situations where they are not needed are horrendous UX in and of themselves due to the usability issues for power users that manage JS execution via browser plugins. [e.g. uBlock]
Saying an application has a "horrendous UX" because you refuse to run its code seems strange to me.
You could disable CSS and images and call the result ugly, but I don't think that entitles you to call the website ugly?
You could disable CSS and images and call the result ugly, but I don't think that entitles you to call the website ugly?
> Saying an application has a "horrendous UX" because you refuse to run its code seems strange to me.
https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
If you want to ignore 1% of the internet, you go right ahead.
https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
If you want to ignore 1% of the internet, you go right ahead.
Fair enough, but I think that's a separate issue. If we go down this path, we'd be diluting the term "UX" to homeopathic levels. I wouldn't criticize an iOS-only app for bad UX because it ignores half the market.
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)".
This page should be titled: "Don't forget to delete unused JavaScript things (nodes, events, etc)".
The real reason to avoid single page apps.
"The real reason to avoid JavaScript"
Ooops, wrong decade
Ooops, wrong decade
Honestly, more like "the real reason to avoid programming"
If you are the type of person who likes to paint ideas and approaches in black and white, pointing out only the upsides of the things you like and only the downsides of the things you don't like, then you're going to REALLY hate programming.
If you are the type of person who likes to paint ideas and approaches in black and white, pointing out only the upsides of the things you like and only the downsides of the things you don't like, then you're going to REALLY hate programming.
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, ...).