

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

======
kls
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
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?

~~~
kls
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.

