Only question I really have is can you use say npm and nuget or cargo in the same project? Assuming you're managing client and server resources in a single project root.
The two that got me are 20 and 33. I haven't thought of progressive enhancement separate from rendering, and for progressive rendering, think of images that render with increasing detail... Also, couldn't recall the definition of Ternary.
#38 is frankly more difficult to answer in the context of JS, as it's usually just a partial apply not a true curried function that can have one or more partial applications, usually requiring a library. Often it's more of a fixed `fn = a => (b, c) => result`
In general a really good set of questions overall. I do find the one question that tends to separate more/less experienced developers is "What are the 6 falsy values in JS?" or a variation on that question. More experienced devs can usually guess 3-5 of them. Usually I'll put it in the context of "if (!x) console.print(`${x} is falsy`);" what values for x are falsy?
Unfortunately, most of the comparison points really apply to both. The main difference is the approach of style in terms of development. Vue tends to work better for smaller SPA apps, and React for larger teams, combined with Redux, GraphQL or a full Flux state management.
In the end, try both, build something trivial and decide which approach you like best.
While interesting, the stdlib mentioned is a Function As A Service (FaaS), and does not go very far for the free teir.
Also worth mentioning will be OpenFaaS if you want an alternative that you can self-host wherever you want. Docker Swarm, Kubernetes and OpenStack are all supported. You can spinup a small-ish Kubernetes cluster on Digital Ocean and deploy OpenFaas pretty easily. There's also Kubernetes direct on GCP (Google Cloud) and options on Azure and AWS as well for OpenFass. You can also use either GCP, AWS or Azure for their respective function as a service offerings.
[0] https://www.openfaas.com/
My biggest issue, is that most apps need filesystem and network access these days. And the permissions aren't fine grained enough in terms of how they're limited.
If filesystem access could be limited to constrained directories and files via configuration for read-only and read/write, it would be a better option. Likewise, if network access could be constrained to specific IPs or named addresses with wildcard matching.
With those options to whitelist your resources, anything that tries to do otherwise (rogue modules), then the application can blow up with an error informing as much.
Personally, I've found that to a large extent, if you aren't a content driven site/app that the SEO portion is largely not going to be very useful. Also, Google and Azure are pretty quick to handle JS content changes (usually 2-3 days from past experience). If what you are building is more like an application, and you aren't selling products in a public facing way then you may not want to focus on SEO or server-rendering.
However, if you are largely content driven, or public facing sales driven you should probably go the other direction with pre-rendered content first, then add features as needed. It comes down to what your focus is on.
I've been split about half and half in my career between the two, and it really should inform your approach. The more SEO friendly your content needs to be, the more you should lean into a static first approach. Even if that means running multiple renders a day. If you're dealing with a lot of content, with lots of searchable options, and results that need indexing, you may want a light server to do your basic renders. If you're creating an application experience like chat, games or otherwise heavily interactive content, then don't worry about the server/seo render. Most of the businesses I've worked with rely on other sales channels and SEO has been a reduced influence.