I don't think it's my place to say what exactly you should use, since I think that more depends on things that I don't have context for; namely, what are you already comfortable with, which tools/technologies are you within one or two steps/layers of comprehending and mastering? If I recommend anything, I would avoid anything with a build step, only because all debugging will happen by you, and that adds a lot of complexity to the feedback loop of troubleshooting and testing.
I think the debate of which language/framework is "best" is silly, because 1) they all start to look the same after awhile, they implement concepts from each other constantly, and whichever you choose can probably already do what you need at a scale that you don't have yet anyways, and 2) the "right" language is more a function of "how many people do you have working on it?", not "what do you need it to do?".
Since you're on your own, odds are that whichever you choose, it can already do what you need. Choose something boring and solid. Choose the one you're more comfortable with. At least get the ball rolling and a foundation in place. If two years go by and you discover you need to alter your path, that wasn't a waste of time, that's you being two years down the road and have momentum in your favor and a launch pad to make the changes you need. Don't get bogged down too much in the nebulous "woulda/coulda/shoulda in two year's time". Build for the needs you have right in front of you; it's too easy to get paralyzed by the endless things that "could" be built at a later date. Solve the known problems now, let the unknown ones come in their due time.
I think the debate of which language/framework is "best" is silly, because 1) they all start to look the same after awhile, they implement concepts from each other constantly, and whichever you choose can probably already do what you need at a scale that you don't have yet anyways, and 2) the "right" language is more a function of "how many people do you have working on it?", not "what do you need it to do?".
Since you're on your own, odds are that whichever you choose, it can already do what you need. Choose something boring and solid. Choose the one you're more comfortable with. At least get the ball rolling and a foundation in place. If two years go by and you discover you need to alter your path, that wasn't a waste of time, that's you being two years down the road and have momentum in your favor and a launch pad to make the changes you need. Don't get bogged down too much in the nebulous "woulda/coulda/shoulda in two year's time". Build for the needs you have right in front of you; it's too easy to get paralyzed by the endless things that "could" be built at a later date. Solve the known problems now, let the unknown ones come in their due time.