@RemoteAction
and apex:actionFunction
are essentially polar opposites in terms of functionality, even though they both offer JavaScript functionality.
@RemoteAction
methods are static, and therefore can't see the current page state directly, while apex:actionFunction
methods are instance methods, and so can see the entire page state.
@RemoteAction
methods require less bandwidth, and server processing time, because only the data you submit is visible and the view state is not transferred, while apex:actionFunction
has to transfer the page view state.
@RemoteAction
methods have to update the DOM manually using explicit JavaScript, while apex:actionFunction
methods automatically update the Visualforce DOM and can refresh part or all of the page, and can provide a standard interface for showing a loading status through apex:actionStatus
.
@RemoteAction
methods can return data directly back to the calling JavaScript, but cannot update the page's view state. apex:actionFunction
methods can update the page's view state and DOM structure, but cannot return data directly back to JavaScript (although you can do this with some extra effort using oncomplete
).
Because of these polar differences, there is almost always "one right answer" for which method should be used in a given situation. An auto-complete-as-you-type feature would benefit from @RemoteAction
, because less data is used, and so it is faster and more responsive; we don't need to modify the view state, so this is a major bonus for the user. Updating the page's view state to show new Visualforce elements, in contrast, would best be served with apex:actionFunction
; using a @RemoteAction
would force the developer to manage the DOM themselves, which can be more burdensome.
Also, you generally can't modify the DOM in native JavaScript if you use apex:actionFunction
, because those changes won't appear in the view state and will be overwritten if the DOM node the changes appeared in is refreshed. This means that JavaScript designed to use @RemoteAction
and update the DOM as a result will generally be incompatible with apex:actionFunction
. There's exceptions to this rule, of course, as long as both uses are isolated from each other or interact only in a carefully designed order of operations.
Generally one is a global variable and another is a merge field.
- The global variable
{!$Label.MyLabel__c }
is a kind of merge field that is a built in feature of salesforce
- A normal merge field
{!Account.Name}
can be defined by user (apex controller,
standard controller, ...)
The !
sign followed by $
is a Global Variable.
Use global variables to reference general information about the
current user and your organization on a page.
That means that you can access some information from some objects on the visualforce page or in a apex code directly without having to query a database (check out a list with all global variables here). Additionally read this useful topic for better understanding what a gloab variable is: "Understanding Global Variables"
The !
sign alone (without $
) is a Merge Field.
For example if your vialforce page use a standard account controller, you can access fields from that object directly using this syntax: {!Account.Name}
Or you can define some variable in APEX controller and reference it on the viasualforce page using this syntax too.
Best Answer
Below I've copy/pasted some of the mot relevant questions from this link: https://developer.salesforce.com/page/Lightning_FAQ
Note the text below is currently missing some hyperlinks - I will update those later.
Q: Will Lightning Components be replacing Visualforce?
A: Nope. See the User Interface Development Considerations unit of the Lightning Experience Development module on Trailhead for an in-depth explanation of this issue.
Q: Visualforce already has components. How are Lightning Component different and why would I want to use them?
A: Visualforce components are page-centric and most of the work is done on the server. Lightning is designed from the component up, rather than having the concept of a page as its fundamental unit. Lightning Components are client-side centric, which makes them more dynamic and mobile friendly.
See the User Interface Development Considerations unit of the Lightning Experience Development module on Trailhead for an in-depth explanation of this issue.
Q: Now that Lightning Components are GA, when would it still be appropriate to use Visualforce?
A: Visualforce provides the facility for delivering template-driven web pages and email messages. In addition, developers wishing to simply utilize a basic container and maintain more control over the lifecycle of the request may choose Visualforce pages. Finally, organizations that can’t use Apex code can’t use Lightning Components, but they can use Visualforce.
See the User Interface Development Considerations unit of the Lightning Experience Development module on Trailhead for an in-depth explanation of this issue.