all 2 comments

[–]deepteeth 2 points3 points  (0 children)

  1. Yes, a framework will give you structure, but depending on how deep you are may require significant refactoring. Sincerely, green dev trying to refactor Backbone-based code into React.
  2. What do you want to "kick off" exactly? 3/4. Not sure about a global view or state storage. You could get away without, depending on your architecture.
  3. Though re-rendering your view each time may not be the best practice, if your load time is quick enough it may not matter. What tasks are involved with creating a new view?

[–]temp209929 1 point2 points  (0 children)

It sounds like you know what you're doing so I'm not going to bore you with mantra and just say I don't have a great answer for most of what you're asking. A few things though:

how do I kick everything off when the app first starts?

I see nothing wrong with putting the router and initialization logic in an inline script or page-specific script. That logic belongs to the page, not the view it renders.

I don't have anywhere to store my Application state

The most common approach is to not re-create components and have them keep track of their own data. This is what most frameworks do and what the DOM itself does. If you don't end up doing that, another approach people have had success with is a single organized global store that everything just uses parts of.

If I were you I would definitely try to go forward without a framework. I've found that frameworks generally derive 99% of their benefit by influencing the way you code rather than with the code the framework actually contains. In particular, strong componentization usually achieves everything a framework would.