I have to admit I was a bit surprised when you asked for “beginning to advanced”. From your other posts I felt that you already had a pretty full plate in front of you. From that I would have expected wanting to learn “just enough JavaScript” to get by with Phoenix channels …
React does have the issue that more recent blog/tutorials (and source code) use “ES Next” very heavily. For example Rest parameter, spread syntax and destructuring assignment are everywhere.
The jQuery temptation is understandable but in my personal experience it’s a trap. Initially it’s very easy to make a static page feel more interactive and embellish it with effects and animations but typically the more code you add the messier it gets unless you are extremely disciplined.
The first issue I ran into was: Where do I put my non-DOM UI state? If I remember correctly jQuery makes it possible to attach an arbitrary JavaScript object to a DOM element. That leads to pieces of UI state being scattered (unconnectedly) all over the page which works as long as that state only has “local” relevance. But eventually you get to a point where some logic needs access to some UI state over here and over there - and that gets messy pretty quickly.
One issue with jQuery is that you are never encouraged to learn enough JavaScript to write standalone JavaScript code. But there comes a point where you need to start writing jQuery independent code to, for example, independently manage your UI-state and only use jQuery to manipulate the DOM - in order to get out and stay out of the mess. And not knowing enough JavaScript makes it extremely difficult to leave jQuery behind and use a different library or framework for whatever you are doing next.
For what you are currently doing I think you should look at something like Unpoly (or Intercooler.js) for your current application. That should put somewhat of a buffer between you and jQuery while giving you access to lots of features that you can use immediately.
Also SPAs aren’t the be-all and end-all. The drive to mobile-first web development could easily start going in a different direction.
Just yesterday I ran into the Push/Render/Pre-cache/Lazy-load (PRPL) pattern which somehow lead me to Hacker News readers as Progressive Web Apps which featured a surprisingly performant viperHTML/hyperHTML example - which isn’t SPA technology nor does it use whole page VDOM.
By the hyperHTML developer:
hyperHTML: A Virtual DOM Alternative
hyperHTML is killing it!
(Whether this particular incarnation is going to catch on is an entirely different question.)
