The problem with completely client-side applications

http://rakeroutes.com/blog/the-problem-with-completely-client-side-applications/

by xyzzyb • 14 years ago

4 3 14 years ago

kls2• 14 years ago

I think you will find that the JavaScript community is much like the Lisp community, in which it is so easy to roll your own that a good deal of people roll their own, it is why you see patterns talked about allot in JavaScript a good deal of people are just implementing the patterns that they need. Where the big patters (AMD=Requires.js, routing=Backbone) get turned into a community supported framework. A big portion of the other issues are dealt with by the particular toolkit you use, for example testing in Dojo is done via DOH. If you are looking for a structure methodology of application development like you get in the Java or .NET worlds, then you need to look to one of the large frameworks like Dojo. The jQuery/Backbone path is intentionally role your own, it is more like the Perl philosophy of grab the pieces you need and build it up from scratch. Where the larger toolkits give you a consistent development pattern.

xyzzyb• 14 years ago

Interesting, it's been a while since I looked at Dojo. I was still (incorrectly!) equating it as an alternative to jQuery, not as a full application framework.

Are there other larger toolkits like Dojo that you could point me to?

kls2• 14 years ago

Dojo is probably the closest thing to a full application framework, give that it utilizes Require.js for AMD, has a test harness a complete object model, and a widget system with a life-cycle. The one thing that it lacks is a router, it has a state management mechanism, but it is no where near as robust as Backbone so I tend to prefer to use Backbone as my macro application router and then Dojo for everything else and mix in jQuery plugins for off the shelf widgets that Dojo does not have. The real power in Dojo is in Dojo.connect, I know jQuery has a plugin to provide this functionality but connect is the heart to Dojo, once you start wiring events and observers up via connects the architecture becomes very easy and straight forward. The thing with JavaScript is you really have to embrace an event based architecture, I know when people first come over they want to write macro controllers that control a view, where JavaScript works much better if you write discreet widgets that emit and respond to events. So you can have events like userInfoUpdated(userInfo) and any widget that needs to respond to that particular data update just connects a listener to the userInfoUpdated function. In jQuery you can use $(object).trigger("userInfoUpdated", [data]) and listen via $.bind. It is similar to connect but it does not give you a function signature on the object and it piggybacks on the event system so you have to be conscientious of bubbling and suppression, as you can bog the browsers event system down in larger apps. Thus I prefer connect as it does not piggyback on the event system.

The problem with completely client-side applications

Related Stories