"Eh, I don't see much of a need for a client side framework" That may be, but others do. It depends on the needs of a project. You may find you can benefit from such thing at some point, when an appropriately fitting project presents itself to you. It is an matter of managing complexity. For projects that don't require a grate degree of complexity, well, you might be right - those projects don't need a client-side framework. It is also a matter of culture and expectations - Do you want a full single-page-application? If so, then 9 out of 10 times you are dealing with a state-full-scenario. The client-side code needs more then just the ability to render templates and talk to the server asynchronously - it also needs *structure* - and more often than not, that means some kind of a state-machine, at least conceptually. If there are multiple pages, and sub-pages, you also need some kind of routing-mechanism on the client (again, when aiming for a SAP). So, you need to manage the hierarchy and flow of the *screens *that exist in your application, and have that linked to a changing URL and a working client-side-history (the back/forward buttons on the browser). Then there is the whole story of how do you manage the data in the client, being synchronized with the server, so you need some kind of an ORM on the client, at the very least. Then there's the whole issue of "having a single source of truth" for the UI and the client-side data, and this means "getting the truth out of the DOM" - this requires a javascript-object-model holding the data (which would be the ORM), and so you need to deal with synchronizing that object-model with the UI, so now you need to write tons of event-handlers, and manually move data back and forth from the UI to your data-model, and refreshing the UI - this is where data-binding libraries come in - you declaratively define the relationships between a UI-segment and a data-model (usually within a template), and the library takes care of the rest for you. Then there's the whole issue of reusing components - being "DRY" (don't-repeat-yourself) - this requires some kind of an object/class-inheritance story - preferably with all relevant capabilities encapsulated. All this is "structure", and lots of code, so some kind of convention for where do you place your files, or how to separate concerns between them - some kind of way to reason about all these architectural-components. You can use disparate libraries on a need-basis, but you often don't anticipate correctly what capabilities would be required in the future. Additionally, you would rather not have to deal with library-incompatibilities, and have a holistic perspective of the entire architecture - you may not need all components at first, but it is ready for you, if and when the need arises - and is guaranteed to work well with whatever you already have. In some frameworks (like YUI), you can pick and choose architectural components in advance, and have a loader that compiles just the parts you need - and in future scenarios, it would be only a matter of re-configuring the loader. Also, preferably, your application architecture should be modular, so it is easy to maintain, reason about, and most importantly "test". And all this without even going into cross-platform and cross-browser issues...
These are all very common problems, that many people have to deal with every day, and they are all solving the same problems, and that is a duplication-of-efforts - so a community-based library/framework makes sense - few people solve a given recurring problem, and all the rest benefit from not having to re-inventing the wheel - like it is in web2py for the server. And so you have to write less code - that makes your application more scaleable, as you can make bigger projects with less code to maintain. Here is another good lecture about some of the aspects: http://www.youtube.com/watch?v=hod-KX81i7s -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
