Warning: this is deliberately not following mainstream convention/fashion. It's hopefully useful, but feel free to ignore if you'd prefer not to explore beyond more conventional options.
First off, a few requirements I inferred from your Q:
1. Performance (response time + concurrency)
2. Simplicity (you're a noob, but it's always a good thing anyway)
3. Stability + ease of maintenance/evolution (you don't state this explicitly - but if you're building on your own, I'd guess you'll have limited time to do this).
Based on those, here's a suggestion.
1. Write you back end in Erlang, using Cowboy or WebMachine to expose RESTful services. Simple, performant, robust, scalable, proven, stable.
2. Start with the premise that simple term/text storage (i.e. no DB) will suffice. Only move from that if you disprove that premise
3. Ask yourself how much of your front end can be handled with straight CSS + HTML. Probably not all, but you'd be surprised how much
4. Instead of a javascript framework, have a look at Elm where you do need client-side behaviour.
I fully accept that neither Erlang nor Elm are mainstream choices. Certainly not for everyone. But they're both well-designed, robust and pretty stable (Erlang more so than Elm on the stability front admittedly - the Elm language is still evolving).
I'll also freely admit that I really dislike the javascript ecosystem. I say "ecosystem" deliberately; I'm not crazy for the language itself, but it's the infuriating instability of packages, frameworks, build tools etc that means I avoid it as far as possible. It seems to take more time just keeping up with with the ecosystem than actually delivering meaningful functionality. I don't find that with Erlang or Elm. Yes, Elm 19 introduced quite a few breaking changes. Though I didn't find porting too painful given the tooling is so good.
YMMV of course.