A Responsive Blogger Website, That Take my blog to the next level.

I am a Software Developer, Learning and experementing with .Net Technology and try to put my Learning altogether here.

We have all sections related to .Net Technology, like .Net-C#, Asp.Net, MVC, jQuery, AngularJs, Sharepoint. Find out more...

Following are the some of the Advantages of using this Web site :-

  • Get Update about latest in .Net world.
  • Collection of Useful, Frequently used .Net Solutions.
  • It’s beautiful on every screen size (try resizing your browser!)

Which JavaScript framework do I choose !!

Since JavaScript has made a big comeback as one of the most sought after skills in the job market there has been a lot of talk about which frameworks to focus on. Developers have several frameworks to choose from today; Angular, Ember, Knockout, Durandal, React and the list goes on.... Granted some of these are not in direct competition since they serve different purposes, but they all deserve to be on the list of notable frameworks in today's market. In this post I will talk about why I don't think it really matters which one you end up going with.
Not too long ago it used to be the case that developers relied on Jquery to do all the heavy lifting when building client side web applications, but the tight coupling between Jquery and the markup made the code hard to maintain and unit test as applications grew bigger and more complicated. Luckily some people realized this and created the frameworks we now have come to use and love. Common to all these frameworks is that they provide good organization of your JavaScript code and encourage much needed decoupling of javascript code from the html markup. Among other things the majority of the frameworks out there have some concept of a databound template that your decoupled object model gets applied to during rendering.
I can't emphasize enough how important this decoupling is for building maintainable and unit testable web applications. By removing the dependency on the DOM the code immediately goes from being almost untestable to highly unit testable. If your model is written correctly you should be able to realistically simulate all UI interactions just by writing tests against your models and logic. Not to mention, since your code doesn't assume a particular UI, it can be applied to totally different markup scenarios.
The point I am trying to make is that all the frameworks mentioned above are more about an architectural mindset than a specific syntax, so if you get into that mindset, you will succeed with all of them. The transition from one framework to the next will also become relatively painless since you already understand the core idea behind it.
In my opinion it's much more important that a developer is onboard with this mindset than it is to have x number of years of experience with a particular framework.
If you liked this article, share it with your friends !