The standard set of tooling for the web is HTML, CSS, DOM JavaScript API and HTTP in that order. Everything else is an abstraction over the top.
Drawing an analogy with Android, the web equivalent is the browser (which in my experience was a lot less obvious than it sounds, but it's even money I'm below average). "JavaScipt" has two very different connotations. There's a language with syntax and datatypes. That's what Node runs. And then there's the JavaScript API for all the various flavors of web browser and these are very very different things in practice that get lumped together in Google's search results.
To me, it appears that the Googley black magic that makes Gmail possible is Kubernetes. Which is a round about way of saying that 'single page web app' is really an architectural decision related to the user interface and orthogonal to technology stack and to overall application architecture [by which I mean that a single page web app can be client server like Gmail or stand alone like a simple game].
What I'm saying, in my round about way of saying things, is that the backend should do what it needs to do and the technology stack of the back end should be chosen to do that thing. The good news is that HTTP isolates the technology of the front end from the technology of the backend. The bad news is that that means that the front end has to deal with low level concepts like a communication protocol in addition to the high level abstractions of its business logic.
Circling back, HTML, CSS, DOM JavaScript API and HTTP in that order, is a good stack to start with on the front end. On the back end, nearly all commonly used languages will provide an HTTP server as a one liner.
In terms of research, these are the easiest to find good information. Furthermore, knowledge of them is assumed for most web tools and any higher level language/library/tool starts bouncing off of them pretty quickly.
That was way more than I meant to write.
Good luck.