One of the biggest bombs Benioff dropped (say that 5 time fast!) at Dreamforce 2014 this year was Salesforce1 Lightning:
What the
is Lightning?
Not unlike the announcement of Salesforce1 at last year’s Dreamforce, Lightning has a lot of marketing hype and ambiguity. This is due mostly to the fact it includes a suite of products. However, also like Salesforce1, there is a piece of the offering that stands WAY out as the most important. When all the dust settled around Salesforce1 it was the mobile experience that proved to be the real offering. With Lightning it is going to be the new component framework, essentially the next generation of Visualforce, that is the real crown jewel. The schema builder, process builder, and lightning connect are all awesome, don’t get me wrong, but they have been around in one form or another for awhile, and are just incremental innovation with rebranding. The lightning app builder is also awesome, but it is just a tool for implementing the component framework in a WYSIWYG fashion.
New component framework? What about Visualforce?
Well, what about S-Controls? The one sure thing about technology is it is outdated as soon as it is released. S-Controls made way for Visualforce. Visualforce has had a long run in the life of force.com development, but is really starting to show its age. In recent years ISVs and customers have had to deviate more and more from the strict Visualforce components to meet their requirements. JavaScript frameworks have been creeping into Visualforce pages to the point where Visualforce tags are becoming a minority of the code in a page in many cases. Controller extensions, viewstates, page refreshes and synchronous processing are victims of attrition. They are being turned into museum pieces by more efficient user interfaces using JavaScript remoting, static methods, stateless behaviors, asynchronous processing. Technically this is still a “Visualforce Page”. But the composition of that page looks very different today then it did say 3 years ago.
Ok… So, still why not keep using Visualforce?
In 2 words: Mobile and Wearables. Visualforce was designed for desktop computing with relatively fast, hard-wired network connections, large displays, and a full-fledged human interface devices. Salesforce1 was a huge leap forward in addressing the needs of mobile computing. But it left a gaping hole which developers had to attempt to fill as best they could. Developing Visualforce for Salesfore1 is not an amazing experience. Sure they threw us some bones like sforce.one.navigateToSObject. But the architecture and styling just felt like a square peq in a round hole. It doesn’t have that desktop Visualforce / Apex, Peanut Butter / Jelly meant to go together feeling. Put another way, the Salesforce1 deficiency was the ability to create Salesforce1 mobile experiences in the same way salesforce created them “out of the box” on the Salesforce1 mobile app.
Salesforce1 Lightning to the rescue!
For sure the Visualforce pages of enterprises across the world will continue to be read and write data from and to the salesforce orgs they live in for years to come. But no longer will Salesforce1 mobile app development have to feel like desktop shoehorned into mobile. The beautiful, mobile, standard page layouts of Salesforce1 will flow more gracefully into custom Lightning apps. <ui:button> will magically be the right button for Salesforce1 without needing to disguise <apex:commandButton> for the job. Developers won’t be forced to go to other JavaScript frameworks every time they want to do something on the client side. In a nutshell, Lightning allows us to go back to developing in a more streamlined “Visualforce-esque” manner, while still being able to leverage the latest technologies of the server and perhaps more importantly, the client.
Will the legacy desktop user interface go away?
I don’t know. But there will definitely be new apps created with Lightning in a responsive fashion to work seamlessly across desktop, mobile, and wearable devices. This is at least the start of a shift towards one UI to rule them all. The {!$Browser.formFactor} global variable will let developers slightly customize their apps to work best on different devices. One app customized for all platforms is much easier to maintain than a Visualforce desktop codebase and a Lightning Mobile / Wearable codebase. The trick is doing it in a way where the experience isn’t compromised on any device. This is hopefully where Salesforce will come in and handle the the lightning elements in different fashions depending on whether the Lightning app is run through the Salesforce1 mobile app on a smartphone, or through the desktop. For example, a data grid that is smart enough to render differently for large vs. small screens without the developer having to handle that. This also helps developers to “future proof” their code since salesforce provides an abstraction layer which they maintain so your app always works well on the latest devices.
Advice to other Developers
You need to have at least intermediate level JavaScript experience. If you don’t have it, get it. Read a book, take an online course, or just google your way through some complex JavaScript projects. Don’t focus just on standard JavaScript syntax, but frameworks like jQuery, various patterns, CSS and the DOM as well. JavaScript is going to become a KEY skill for salesforce developers (it already is in many cases). This will not only improve your ability to crank out hybrid Visualforce pages, but it will also make the move to Lightning less of a shock. It will also position you well to be create interesting new projects on Lightning vs. being stuck a role maintaining Visualforce… And we all know building new things is more fun than maintenance. 🙂
MacGyver Force 