Remote Objects respects your organization’s field level security settings. Keep this in mind when you create pages that use Remote Objects. Fields that aren’t accessible to the person viewing the page appear blank. Actions that modify field data (create(), update(), and upsert()) fail with an error if they include inaccessible fields in the request.
Remote Objects removes control of transaction boundaries from your code. Each Remote Objects operation (create(), update(), and so on) is a separate transaction. Each operation succeeds or fails on its own, which can be a problem when you need to create or modify multiple related objects as part of a business process. For example, if you create an invoice record and related line-item records, each record is saved in a separate transaction. If some Remote Objects operations fail and some succeed, your data can be left in an inconsistent state. Note that this issue isn’t related to service reliability. In this example, if some of the line items fail a validation rule, they won’t be created, which leaves an incomplete invoice. Your code must clean up and try again.
In contrast, JavaScript remoting transaction boundaries are on the Apex @RemoteAction method. It’s easy to create the invoice and related line-item records inside one method, where automatic Apex transactions ensure that all records are created together or not at all.
Consider carefully where you’re putting your application’s business logic, especially when it’s complex. When you are creating straightforward pages that enable creation, editing, and deletion of individual objects, as in An Example of Using Remote Objects with jQuery Mobile, the business logic is minimal. Putting this business logic on the client side, in Remote Objects and JavaScript, can be entirely appropriate. When you have more complex business rules and processes, though, it might be more effective to remove that logic from the client layer and build it on the server side.
Applications need to manage complexity carefully. Simple contact manager or store locator pages don’t have much complexity to manage, but many business processes do. Remote Objects pairs well with JavaScript frameworks such as jQuery and AngularJS, and those can help with the complexity of your application’s user interface. Always consider separating the concerns of your application into multiple layers and keeping them as discrete as possible. This is called “separation of concerns,” and it’s a classic software pattern and best practice.
Consider placing your data integrity rules in triggers and validation rules. Also consider encapsulating your business process rules in Apex code that you make accessible via @RemoteAction methods that you can use with JavaScript remoting or with SOAP or REST services that you can use from anywhere.
Think carefully about what your page or application needs to do, and then choose the right tool for the job. Sometimes that tool is Remote Objects, and sometimes it’s something else.