In the spirit of your general enquiries …
In my experience
- JavaScript avoidance strategies do not work - they simply leave you weak in an area where having strong skills (really) is a requirement. Once you have strong JS skills it can make sense to look into a transpiled language to make your life more pleasant or better yet, to add sound static typing (I personally don’t count TypeScript). In some ways the trick is to also program outside of JavaScript.
- When learning a client side web framework/library you are just learning that - you don’t magically by osmosis somehow learn how to build good web app frontends - ultimately that still requires a solid understanding of HTML/CSS/JS (and how the web works in general). Also web frameworks/libraries come and go - for the time being JavaScript is still here to stay - WebAssembly notwithstanding.
Designing for mobile can be done with “mobile first CSS” - Example: sidecar.us (github) by Keith J. Grant (author of CSS in Depth).
Now I understand that HTML/CSS are utterly boring (and at times incomprehensible) from a programming point of view but them’s the breaks.
The complexity of client side rendering (SPA) only really starts to pay off when you need highly interactive features or when you are moving into a space where processing is done on the client side (e.g. serverless). There are plenty of testimonials that SPA technology will slow down the development process (and will make it more (and sometimes unnecessarily) complex).
The Mozilla Developer Network has some guides to fill in any HTML/CSS/JS gaps that you may have.
In terms of JavaScript You don’t know JS is often recommended but it is largely ES5 based and it is becoming increasing important to be able to understand ES2015 and beyond - which is why I’m mentioning Practical Modern JavaScript/Mastering Modular JavaScript (online) here (http://javascript.info/ also recently appeared).
In reference to the frameworks mentioned (my “exposure”)
- Elm (2012) - now at 0.18 (no 1.0 yet)
- React (2013) borrows Elm’s ideas back into the JavaScript space. Now v16.2 - note that in 2016 v15.0 followed version 0.14.
- Vue.js (1.0 October 2015; 2.0 September 2016; 2.5 October 2017) now at 2.5.16
Vue.js is easy enough to get started in but ultimately the way it’s reactivity system embraced mutability didn’t sit well with me (though that could simply be a matter of personal taste). Also unless you give the documentation a good deep dive you may end up being surprised by what and when things become reactive (or not).
I only ended up back at React because of ReasonML but in order to use ReasonReact previous React knowledge is assumed - knowledge that is usually documented in the JavaScript space. In my opinion lots entry level React material takes an oversimplified approach that overemphasizes components while not highlighting design for composability. And then there are a number of JavaScript React practices that don’t translate to ReasonReact, creating a strange “React the good parts/React the bad parts” kind of situation.
In the end there isn’t a “perfect” (framework/library) solution, something designed for complicated implementations is just going to weigh you down for simple solutions, something designed for simple cases will likely turn into a hairball if your solution has complex needs.
