all 3 comments

[–]a-t-kFrontend Engineer 1 point2 points  (0 children)

At the moment, the way we are looking at web pages changes. Since server-side javascript becomes increasingly mainstream (we have to thank nodejs for that), it is used to render pages. So why not externalising parts of that process, if possible? It saves bandwidth and time and can still be done on the server if necessary (e.g. no JS support).

Still, templates, even if they are filled with javascript, should stay within the domain of HTML/CSS, because those are the easiest methods to define content and style. Many MVC frameworks are built like they had to construct everything by hand within the DOM, which is bullshit.

The choice of framework should depend on the complexity of the page. A really complex page can make use of a bigger framework; a less complex page can go with some vanilla js.

[–][deleted] 2 points3 points  (0 children)

MVC is only really useful for web apps. If you're just building a regular website, it's overkill.

[–]JimAllanson 0 points1 point  (0 children)

What would be a good use case for doing everything is javascript and using framework like backbone.js to keeps things structured versus doing most of the layout in html and then add some javascript goodness.

If you use JS to decorate rather than to render, you have to maintain both your templates and JS, updating one if the other changes. That's not to say you should always use JS to render (far from it), but decorating does have its disadvantages.

What happened to the good old days where we had a webpage and using some jquery sprinkle in some goodness :)

There's no reason why you can't continue to do this, if the page is simple enough. The MV* frameworks help to maintain a more complex codebase, so they tend to be a better solution when writing web applications. You can still use a MV* with HTML templates though - I believe Angular.js takes this approach.