Do yourself a favor and avoid all those three. Starting from the worst:
Template strings will be very messy, you do not get a good IDE support, and you will lack proper interaction (depends on how "static" your page is)
There is no reason to use MongoDB from the start. Fulstop. In general use SQL databases as long as you do not notice performance problems. Then you can either get familiar with scaling SQL or you can look at NoSQL. Transitioning from SQL to NoSQL is a lot easier than the other way round. Having a Schema in your DB helps you a lot in avoiding invalid data due to bugs which are common in the beginning.
Node.js, I always wonder why people choose node for production (!) software. It is slow, most of the trivial bugs you write (e.g. typos) are only detected at runtime (if at all) and Javascript as a language is weak. You basicly trust your business to a glorified text file
There is no "general" future proof stack. Pick the stack that's now the best for the job and not because they have biggest marketing claims (cough MongoDB cough). When I start a new project i basicly follow this plan:
Is it a website or an app (eg blog vs dataviz)
Blog: Static site generator, I like Hakyll a lot
App: continue
Which frontend framework (if app)
No react/redux (not a framework, but also not a simple library, forces you do follow weird OOP approach, in case of redux a lot of boilerplate)
No Angular (Bloated, too much "magic", if something fails, reason is not clear)
I like Cyclejs, but as Co-Maintainer I'm biased. I would recommend Cycle if you want to do a lot of async stuff (e.g. websockets)
API
No Node, see above
I've grown to love Haskell servant, which lets me specify the URL, let me write the handler and does all the plumbing for me. Also the type system saves you a lot from errors
What type of data do you have
Logging data (mostly append): TimescaleDB (Postgres plugin)
If you find that Node is slow, there is something horribly wrong in the way your app is either written or deployed.
Next, every languages represent code as "text files"... compiled or not makes no difference. Code is a human readable set of instructions. The fact that it is not compiled does mean possible runtime uncaught exceptions. This is why we have linting, unit tests and acceptance tests... If, regardless of thise you still get errors, it brings me back to my first point: you're doing something horribly wrong.
An application is, in essence a group of tools, like a db, an http server, some caching, etc. With the language simply acting as a glue between them. I don't beleive that a language can be categoricaly inferior or superior to another one- just that they all have their perks. JS for APIs is a real breeze.
If you need some help setting it up, hit me up, my fees are reasonnable ;)
The glorified text field was refering to no type system that protects you. Unit test are no replacement for a type system.
Node is slow. I did a few benchmarks before choosing my Stack and node was the slowest of them. My Haskell server could handle twice as many clients before maxing out my test rig.
Js is not a breeze, it's horrible. The express API is the worst API i have ever seen. I would never even consider node for anything more than a prototype.
Do yourself a favor and avoid all those three. Starting from the worst:
There is no "general" future proof stack. Pick the stack that's now the best for the job and not because they have biggest marketing claims (cough MongoDB cough). When I start a new project i basicly follow this plan:
Is it a website or an app (eg blog vs dataviz)
Which frontend framework (if app)
API
What type of data do you have
If you find that Node is slow, there is something horribly wrong in the way your app is either written or deployed.
Next, every languages represent code as "text files"... compiled or not makes no difference. Code is a human readable set of instructions. The fact that it is not compiled does mean possible runtime uncaught exceptions. This is why we have linting, unit tests and acceptance tests... If, regardless of thise you still get errors, it brings me back to my first point: you're doing something horribly wrong.
An application is, in essence a group of tools, like a db, an http server, some caching, etc. With the language simply acting as a glue between them. I don't beleive that a language can be categoricaly inferior or superior to another one- just that they all have their perks. JS for APIs is a real breeze.
If you need some help setting it up, hit me up, my fees are reasonnable ;)
The glorified text field was refering to no type system that protects you. Unit test are no replacement for a type system.
Node is slow. I did a few benchmarks before choosing my Stack and node was the slowest of them. My Haskell server could handle twice as many clients before maxing out my test rig.
Js is not a breeze, it's horrible. The express API is the worst API i have ever seen. I would never even consider node for anything more than a prototype.
To each its own, innit?
Nodejs is awesome if you REALLY KNOW nodejs. So is anything else you REALLY KNOW...