#3 is not quite correct... all inheritance in JS is prototype based, even if using the class syntax, it's sugar over the prototype model.
Prototype based inheritance in JS is kind of like a search path... is property X on the object, on it's prototype, and so on down the chain. You can also use Object.create({...}, null) to inherit from null instead of Object as a base prototype.
#4 somewhat disagree on the FP cons... even before I understood what FP was, I leaned into that style far more early in my career... prefering utility functions and composition over class methods. I didn't come at this with a formal education, and even then tended towards FP practices.
On the flip side, class syntax/structure is useful when you need to bind state and behavior. This can be useful in certain types of components, though I prefer React + Redux, with other libraries using class syntax is easier to reason with.
#6 I'd add that when using the prototype the properties aren't serialized by default (Object.keys/entries) and this can be beneficial if you want utility properties/methods but don't want them serialized. There are other ways to do this, but the prototype is a relatively clean break for this behavior.
#9 While I appreciate micro-services, the orchestration can often be more work than the application development itself. If you don't have dedicated resources to this operation design and overhead it's usually not a good idea. If you're leaning on a cloud platform and they offer things like lambda (aws) or functions (azure) then it might be worth leveraging these things earlier. Otherwise stick closer to the monolith model and then break off pieces that tend to bottleneck or can be parallelized or separated out via a queue system first.
I'm also in general a fan of a dedicated server api for the ui, even if there's a more formal set of APIs behind it... this can allow more edge-line utility on a server before the internet latency becomes a thing. GraphQL is another similar example of this approach. I find that node/js is a very good fit here as you can leverage the same mindset/language without the disconnect at this level.
#10 kind of a sloppy definition, but mostly correct in the context of node and the browser.
#3 is not quite correct... all inheritance in JS is prototype based, even if using the class syntax, it's sugar over the prototype model. Prototype based inheritance in JS is kind of like a search path... is property X on the object, on it's prototype, and so on down the chain. You can also use Object.create({...}, null) to inherit from null instead of Object as a base prototype. #4 somewhat disagree on the FP cons... even before I understood what FP was, I leaned into that style far more early in my career... prefering utility functions and composition over class methods. I didn't come at this with a formal education, and even then tended towards FP practices. On the flip side, class syntax/structure is useful when you need to bind state and behavior. This can be useful in certain types of components, though I prefer React + Redux, with other libraries using class syntax is easier to reason with. #6 I'd add that when using the prototype the properties aren't serialized by default (Object.keys/entries) and this can be beneficial if you want utility properties/methods but don't want them serialized. There are other ways to do this, but the prototype is a relatively clean break for this behavior. #9 While I appreciate micro-services, the orchestration can often be more work than the application development itself. If you don't have dedicated resources to this operation design and overhead it's usually not a good idea. If you're leaning on a cloud platform and they offer things like lambda (aws) or functions (azure) then it might be worth leveraging these things earlier. Otherwise stick closer to the monolith model and then break off pieces that tend to bottleneck or can be parallelized or separated out via a queue system first. I'm also in general a fan of a dedicated server api for the ui, even if there's a more formal set of APIs behind it... this can allow more edge-line utility on a server before the internet latency becomes a thing. GraphQL is another similar example of this approach. I find that node/js is a very good fit here as you can leverage the same mindset/language without the disconnect at this level. #10 kind of a sloppy definition, but mostly correct in the context of node and the browser.