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

Re:How to avoid common SPA pitfalls when using third-party p... by runspired on Tuesday January 26, 2016 @05:40PM (#10976802)

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.

[ Parent | on HN ]

Re:How to avoid common SPA pitfalls when using third-party p... by sotojuan on Tuesday January 26, 2016 @05:45PM (#10976842)

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

[ Parent | on HN ]

Re:How to avoid common SPA pitfalls when using third-party p... by runspired on Tuesday January 26, 2016 @06:17PM (#10977009)

This is the place to start: https://developer.chrome.com/devtools/docs/javascript-memory...

[ Parent | on HN ]

Re:How to avoid common SPA pitfalls when using third-party p... by Terr_ on Wednesday January 27, 2016 @12:52AM (#10978483)

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

[ Parent | on HN ]