Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to avoid common SPA pitfalls when using third-party plugins

blog.isleofcode.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: How to avoid common SPA pitfalls when using third-party plugins

#31

Post by blhack »

samizdatum wrote: post #16
blhack wrote: post #12

Earlier quoted context omitted.

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.

Re: How to avoid common SPA pitfalls when using third-party plugins

#32

Post by samizdatum »

blhack wrote: post #31
samizdatum wrote: post #16

Earlier quoted context omitted.

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!

Re: How to avoid common SPA pitfalls when using third-party plugins

#33

Post by manyxcxi »

unit91 wrote: post #21
jonesb6 wrote: post #5

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…

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

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.

Re: How to avoid common SPA pitfalls when using third-party plugins

#35

Post by Terr_ »

runspired wrote: post #20
Bahamut wrote: post #14

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.

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!"

Re: How to avoid common SPA pitfalls when using third-party plugins

#36

Post by dasil003 »

runspired wrote: post #7
lolc wrote: post #4

Earlier quoted context omitted.

"The real reason to avoid JavaScript" Ooops, wrong decade

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

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.

Re: How to avoid common SPA pitfalls when using third-party plugins

#38

Post by dang »

runspired wrote: post #29
dang wrote: post #25

Earlier quoted context omitted.

It's a bit baity, so we changed it to the subtitle. 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.

Re: How to avoid common SPA pitfalls when using third-party plugins

#39

Post by fweespeech »

samizdatum wrote: post #27
fweespeech wrote: post #24

Earlier quoted context omitted.

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?

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

Re: How to avoid common SPA pitfalls when using third-party plugins

#40

Post by samizdatum »

fweespeech wrote: post #39
samizdatum wrote: post #27

Earlier quoted context omitted.

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?

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

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.
Post reply on HN