I would really appreciate it if you'd share the application structure you use when building a client side MVC with vanilla JS/Jquery.

I know there wouldn't be a single structure to rule them all, but I think if developers start sharing structures that work regardless of frameworks used, it would be much better than sharing frameworks that are very complex and get replaced every year.

Views are very simple. There is generally a class instance which is using a DOM element somewhere. So I store a reference to that element on the instance. Then I have a simple object containing references to all of the important elements within it. I have a function which generates the element if it hasn't been created yet and adds it to the page. Now I can change whatever I want to about the element or any important elements within it. I use classes like "is-hidden."

Sometimes I'll decouple the UI from it's functionality. In which case I usually implement a simple eventer system on the underlying code which the UI connects to for status updates.

Bingo bango. I haven't run into a circumstance yet where any one file was longer than maybe 200-300 lines total. It's simple to read, it does anything I want.

I have never needed to construct anything client side that warranted laying it out like a server implementation. But maybe that's my issue, I'm thinking too small and other people have a better idea of what the future of the web looks like than me.

I still prefer having control.

I started web development in the 90s where small size and high speed were key. I try to do the same now. I'll only use jQuery where possible, but if I do use a framework/library it will be to prototype something or to get something completed as I am under time constraints. If I get a chance I'll port it all over to plain JavaScript.

Modern webpages are just too big.

Wouldn't it be easier to draft a set of design principles for the project? What I mean is if you really need a single page application, and usually you don't, that can be accomplished easily with turbolinks. If you really need to build DOM elements on the fly, that can be done really easily with raw JavaScript, which is fairly powerful on its own these days.

I just don't see it.

  > Wouldn't it be easier to draft a set of design principles for the project?

I'm not really advocating for or against, since I've never used a large framework like this in a team environment, but there must be benefits. Lots of smart people aren't using it because they are dummies that can't do better.

I think the companies that are doing it are fighting over the space the same way operating systems do. Android, iOS, Windows. Potentially apps could start being developed for Angular and React and so on, in the future which are tied to licensing contracts for users.

All the smaller frameworks are people trying out a few things, none of them corporate or free are really necessary.

I'm not a front-end developer either (so my JavaScript experience is a bit limited), but with the back-end code that I work on with my team, enforcing policies can be a bit tricky. It's pretty easy for things to slip through in a pull request that are against policy, and it's kind of hard to automatically check for policy violations. When forcing someone to use an API, at least you can somewhat guarantee that the API follows the policy.

[1]: http://jlongster.com/Removing-User-Interface-Complexity,-or-...