"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.


Reply via email to