If you expect to start from scratch several times, I encourage you to separate your logic from your views. Whatever framework you decide to try, make it as thing a layer as possible, and put as much code and functionality as possible in framework-agnostic, plain JS files.
In this way, adding, removing, or changing your frontend framework becomes much simpler. They had a more straightforward role in your system ("when user interacts with X call module Y.foo") instead of housing most of your code, and potentially losing all that code when you start from scratch or decide to try a different framework.
Secondly, get a better idea of what your needs are. Do you just need a few UI interactions? Is it going to be heavy on state? Do you need to run a lot of AJAX requests and update the UI accordingly? Before you can know which JS framework you need, you need to know what role the JS plays in your system. If you don't do that, every framework is a potential valid answer, since the question is too vaguely defined.
Agreed. When writing my code editor I started off with a lot of UI-related state and logic in the UI (Svelte) components, things like keeping track of what tabs are open and editor state within the tabs.
Quickly realised there was gonna be a lot of grappling with Svelte as the complexity grew: figuring out what component structure to use for passing data around efficiently and ergonomically, passing events between components, using Svelte stores for global state and figuring out how to update and subscribe to them from non-Svelte code, etc.
Now the Svelte code is a thin wrapper and the app can run headless. I feel like it would genuinely be fairly easy to plug a totally different UI onto it.
Each Svelte component basically stores copies of the state it's interested in, subscribes to events from the objects it's interested in, and calls methods on those objects in response to events. This comes with a bit of extra boilerplate vs. more tightly integrating the UI logic with Svelte but the almost complete lack of cognitive overhead in this part of the code is well worth it.
In this way, adding, removing, or changing your frontend framework becomes much simpler. They had a more straightforward role in your system ("when user interacts with X call module Y.foo") instead of housing most of your code, and potentially losing all that code when you start from scratch or decide to try a different framework.
Secondly, get a better idea of what your needs are. Do you just need a few UI interactions? Is it going to be heavy on state? Do you need to run a lot of AJAX requests and update the UI accordingly? Before you can know which JS framework you need, you need to know what role the JS plays in your system. If you don't do that, every framework is a potential valid answer, since the question is too vaguely defined.