I think you need to say a little more. Do you mean classes that are loosely coupled, but have core dependencies that are always present? This is a way in which a lot of libraries and site architectures work. It very seriously depends on what it is that you're doing. It sounds from your use of the words "Publish" and "Subscribe" that you have\-}+-09sa=\-]=0-p943 a lot of JavaScript that operates dependent upon some flags that your user presents you, is that correct? If not, I'm kind of at a loss for what you mean.
On Mon, Jul 11, 2011 at 11:39 PM, dtang85 <dtan...@gmail.com> wrote: > Over the past year I've been focussing on JS and one thing that I > haven't seen too much about is how developers architect their JS for > small and large sites/applications. I've been primarily using the > Publish/Subscribe pattern based on my own custom implementation of the > pattern, but I'm starting to think that it may get harder to maintain > my site/application as I write more JS, as my code will consist of > several publications and several subscriptions. How do you architect > your JavaScript in a site/application, and how do you effectively > incorporate a library into your architecture? > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/jsmentors@jsmentors.com/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/jsmentors@googlegroups.com/ > > To unsubscribe from this group, send email to > jsmentors+unsubscr...@googlegroups.com > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
