You're probably best off jumping on the train with Andrew, as he's been working with the Breeze folks to make everything work well with SharePoint.
My biggest recommendation about building anything client side with SharePoint is to try to think like a Web developer first and a SharePoint developer second. By that, I mean that the patterns that are considered "best practice" on the client side have usually been solved outside the SharePoint realm.
With SPServices, I was lucky in a sense that there wasn't anything already there from Microsoft for patterns. It was the SharePoint 2007 timeframe, so CSOM didn't exist yet.
I looked at other jQuery libraries and plugins that had nothing to do with SharePoint to determine the best way to build SPServices. I'd change a few things if I could, but generally I built something that makes sense to Web developers. This means that to many people, SPServices feels easier to use than CSOM, which was written with the .NET developer in mind. In a sense, my own ignorance of .NET development served me well.
M.
My biggest recommendation about building anything client side with SharePoint is to try to think like a Web developer first and a SharePoint developer second. By that, I mean that the patterns that are considered "best practice" on the client side have usually been solved outside the SharePoint realm.
With SPServices, I was lucky in a sense that there wasn't anything already there from Microsoft for patterns. It was the SharePoint 2007 timeframe, so CSOM didn't exist yet.
I looked at other jQuery libraries and plugins that had nothing to do with SharePoint to determine the best way to build SPServices. I'd change a few things if I could, but generally I built something that makes sense to Web developers. This means that to many people, SPServices feels easier to use than CSOM, which was written with the .NET developer in mind. In a sense, my own ignorance of .NET development served me well.
M.