This is what I picked up in todays great session on client code;
Migration of code will require start using the Client API objects instead of the current API we all know in the server, but most objects are similar to help us update our code easily.
So - SPWeb will be web, SPList will be list etc...
Event SPContext exists as ClientContext!
the only difference is, that you run all your code on the clientContext object in the client side, and once you have a set of operations you wish to submit to the server you can do that by calling "clientcontext.ExecuteQuery()" or "clientcontext.ExecuteQueryAsync()" if you want the UI not to wait for the result.
If you wish to retrieve data form server to your client you can use the “Load” or “LoadQuery” methods. LoadQuery will return a result collection and will use method syntax or linq query syntax. It will build you XML query and will send them to the server next time you call “ExecuteQuery”.
Using the "Execute" or "Load" methods actually help reduce the number of trips done from the client to the server to reduce server load, bandwidth and improve responsiveness.
Nothing new, except you don't have to build your own wrapper and web services if you want to run some code on your SharePoint from the client. Basically this will communicate with client by dropping JSON code from the server to the client, the client will use the JSON to work with and send queries to the server in XML format.
I guess this will help us do less post back, as this will not be supported in wiki pages (no post back support).
A new cool thing is the SP.CamlQuery.CreateAllItemsQuery() method that renders a CAML that returns all items for a list. This will surly get you started with CAML query – the last stand of CAML in 2010 since views and forms are now defined by XSL.
More news from the SPC2009 will follow!