Search code examples
javascriptjavascriptmvc

Why do we need javascript mvc?

  1. When would one go for using Javascript MVC ? I mean why there was a need for JS-MVC ?
  2. Is it only because this design pattern was famous in other languages, for code maintenance,readability and many web apps are shipping client side ?
  3. How does it helps a developer, tester and end-user easing their tasks ?
  4. Any use-case where JS-MVC is suited best and any case where it is not at all required ?
Solution

  • Question 1,2,4

    My view is that you should apply any kind of design pattern only and only if you really need it. Simply because design patterns aren't easy after all. They will add complexity to your solution, but they'll also provide you the benefit of (normally) being established and working solutions for specific kind of problems.

    Whether to use or not use them really depends on what you are going to construct and how complex it is. That said, I'm probably not going to structure my 200 lines jQuery plugin using the MVC pattern, maybe...

    But at work we create single page applications where we have 2-5 devs working on a project the same time, projects of the amount of 500 days. In such environments things can get complex very quickly and if you don't follow any kind of proper structuring you're lost.

    I hope that should answer your question 1 and 2.

    For question 3:

    The end-user hopefully gets a better quality app with less bugs, but usually he shouldn't even notice (nor does he care) about the underlying architecture of an app.

    MVC helps the developer

    • as an orientation when navigating in the app's source code. Consider an app of 3000 lines of code in a single source file and then when having 4 devs working on it at the same time. A mess, right? When having an MVC app which normally also use routings etc...you normally already know by looking at the route in the url where the corresponding controller lies in the source code and where you should put your hands on
    • for easier testing. Separation of concerns is always beneficial when applying unit testing practices because you can much easier test your controller because it isn't directly couple to data or presentational stuff (like HTML code etc). And just as a side note, you should definitely unit-test your JavaScript code, definitely!!
    • maintenance: which is the result of the previous points somehow

    I'm not sure which kind of figure you intend by "tester". If he writes automated tests at the unit or acceptance level, then the benefits from before pretty much hold as well. If he's testing the app as a whole in the sense of navigating around, taking the app as a black box by testing its reaction to different kind of inputs, then MVC doesn't really play a big role for him. It's like for the end-user.

    So I hope I was able to clarify some things for you. But as said, never just follow a pattern because people follow it but only 'cause it gives you any kind of benefits.