Current state of Visualforce

Introduction

I love Salesforce and how fast things are evolving on the platform (from the Marketing Cloud to Force.com) but fact is that not everything is going as fast as some of us may expect it. One of this thing is Visualforce.

Problem

Visualforce has been introduced in 2008 and it has superseded S-Controls only in 2010 for the good reason that Visualforce was a better technology than S-Controls (+Ajax Toolkit). While I won't discuss nor argue on that, it's a fact that the Internet evolves as fast in 1 year than other industries in 100 years. And Visualforce has not changed at all since it has been introduced. Of course, limits are higher than ever while new Visualforce Tags answering the Salesforce evolution (e.g. Chatter) have been regularly added during the 3 yearly Salesforce releases. But if you have ever built Visualforce Pages, you already know that the more complicate your application becomes, the harder it is to fix unexpected issues (usually happening when you start using components with rerender attributes). It becomes even harder to debug when you try to mix Visualforce with some well known JS libraries like jQuery or YUI. And you end up with tons of workarounds that no other developer are able to grasp...

In the meantime

2010 was the end of S-Controls, the real beginning of Visualforce but it was also the time when great JavaScript Frameworks have been created (Angular in 2009, Knockout and Backbone in 2010, Ember in 2011...). These frameworks are a revolution in the way we build web application. The logic (like in Visualforce) is not anymore stored on the Server but is exported to the client app. The application is not anymore half dynamic like Visualforce is (e.g. you click on a button to refresh a result list, you wait a few seconds, the Ajax Callback happens, update the huge viewstate and rerender the UI => ~10 seconds lost). Instead, with a JS Frameworks refresh happen usually within a few milliseconds if data are already loaded on the page, while it may take a few hundreds milliseconds if a server call needs to be performed.

A first answer

While Visualforce now is not (much?) faster nor better than at the beginning, Salesforce has helped developers taking advantages of these JS frameworks by adding JavaScript Remoting, which allows a solid communication between Salesforce and JavaScript (Frameworks). In the meantime, JavaScript frameworks are evolving extremely quickly (some much faster than others) and building a Salesforce application on a JavaScript Framework (you understand and master) is (usually) much faster than building the same with Visualforce. It's usually faster for you as developer to code the application, but it provides especially a much better UX for your users. And I won't even talk about the beauty of the code from a well structured JS Application to a potentially chaotic Visualforce one (statement probably wrong if you use Backbone or similar, but definitely correct if you use Ember or Angular on one side while Visualforce + jQuery on the other).

About Visualforce...

2 way databinding, reactivity, URL Rooting (state based),... are a few barbarian terms (among others) that makes JS Frameworks great while Visualforce don't know any of them. And I don't believe that Visualforce will fill the gap in the upcoming Salesforce releases. Of course, I see some attempts to make Visualforce better (or faster) like a server side viewstate, especially designed for mobile devices but honestly, come on, I don't know much people who are developing mobile application with Visualforce Markup and rerender stuff!.. And that might solve just 1 Problem of 100. Well to be honest, I rather expect that the gap between Visualforce and JS Frameworks is getting bigger and bigger over the years...

What now?

What I would like from Salesforce is less to see Salesforce trying to compete with any of these frameworks by pushing Visualforce further, rather I would like to see Salesforce embracing these new technologies by making them more fun for developers. JS Remoting was surely the most important step for it (in order to be able to simply use them!) but nonetheless lots of things could be easier if things like Widget Components would exist (e.g. chatter widget, live agent widget, knowledge articles widget, ...) with of course a correct API, generic enough to be embedded in any JS Framework (i.e. non opiniated to one special framework, i.e. not like SmartSync with Backbone but that's another story...). Something really cool could look like that:

sforce.Components.CreateChatterFeed({
    elementId: 'divId',
    showPublisher: true,
    width: '100px',
    height: '200px',
    CSSClass: 'yourClass',
    ...
}).then(function(success){
    console.log('success', success);
}, function(error) {
    console.log('error', error);
});

and somewhere in the page

    <div id="divId" />

You get the idea? Not a ugly mix between Visualforce Markup and JS Framework syntax, but something controlled totally by the chosen Framework!
Widget components are one thing, but these "widgets" should be built smart enough, that Developers can customise them as they like it.
Also, a Salesforce theming library would be cool, something like Bootstrap or Foundation, but based on Salesforce CSS. Building a native UI Salesforce application on a JS Framework is right now pretty complicate, if not totally hacky...
Abstracting some common methods for retrieving and upserting records would be good too. I know that in the upcoming spring release (i.e. Spring 14), it will be possible to use Remote Objects ( apex:remoteObjects) for retrieving data, but while I still appreciate it, it's always the same problem with Visualforce: much too verbose:

<apex:remoteObjects>
    <apex:remoteObjectModel name="Account" fields="Name">
        <apex:remoteObjectField name="Type" ></apex:remoteObjectField>
    </apex:remoteObjectModel>
</apex:remoteObjects>

which could have been written simply like that:

<apex:remoteObject queryFields="Name" sObj="Account" whereFields="Type"/>

And actually, it would have been even better if it was possible not to write any <apex:XXXX > at all. Ajax Toolkit could do it 10 years ago, why is it that different!?

And for upserting record, it would be good something like that:

sforce.Upsert({
    sObject: 'Account'
    records: [{Id:'001000000212123', Name: 'Test'}, ....]
}).then(function(success){
    console.log('success', success);
}, function(error) {
    console.log('error', error);
});

Instead of having to write a Server Side method, which has to return a properly formatted success/error message. On this last point, please don't misunderstand me, I'm absolutely not an Ajax Toolkit nostalgic and I know it had different limitations, but it's on the same time sometimes much more logic than right now Visualforce.

And you, what do you think?

comments powered by Disqus