As discussed, the more you move towards a stateless controller and JavaScript Remoting client architecture, the more you need to invest in providing or obtaining client-side components not presently provided by Salesforce.
Consider this decision carefully on a per-case basis (not all of your application UI has to use the same approach) and make sure that you appreciate the value of the platform features that you are leaving behind. Expect to adjust your expectations around your client developer's velocity to be more in alignment with those on other platform developers.
Libraries such as JQuery provide a great deal of convenience, flexibility, and components available in the community to provide some alternatives and improvements over the Visualforce components, in addition to larger components such as grids and trees. Taking things a step further, larger commercially available libraries such as Sencha ExtJS are also usable from within a Visualforce page, including mobile variants such as JQuery Mobile and Sencha Touch.
Tip
Lightning implements a security layer around your components, known as the Locker Service. This blocks eval, enforces use of strict mode, and restricts access to the DOM outside your components own boundaries. Check that the third-party libraries you intend to use in Lightning Components are compatible with this type of security context.
All of these libraries require a good deal of JavaScript programming knowledge, including its OOP style of programming. Some provide the Model View Controller (MVC) frameworks as well, such as AngularJS. If you search on Google for Salesforce and for example AngularJS, you will find many examples and articles from the community and the Salesforce Developer Evangelists team.
Here are some aspects of developing with such libraries, which you should consider:
- Developer flow: What is the process from storing the client code in source control, pushing it into an org for development, editing code, debugging it, and pushing it back into Source Control? Likewise when it comes to packaging, consider whether you should compress your JavaScript or not. The Developer flow has to be fast; editing JavaScript files, rebuilding zip files, and uploading new static resources is not fast. Consider whether you can support a loose file development flow for client developers, such as using Visualforce components, page, or static resources for each file (MavensMate has good support for this), and then combine these into a single static resource for packaging and deployment.
- Security: Salesforce takes a great deal of care with their Visualforce and Lightning components to ensure that the escape values are displayed by the components to prevent attacks such as HTML injection for example. Check your components' escape values that they inject into the DOM from your database records, or you could find yourself open to attack and delays getting through the Salesforce Security Review.
- Testing frameworks: There are a number of approaches when testing rich clients, ranging from unit testing frameworks that have the developer write a JavaScript code to testing commercial applications that actually drive the web browser and assert the state of the page. Make sure that you invest according to the amount of JavaScript code your application contains.