When is ExtJS really right for Salesforce Apps?

I recently got chance to work on Ext JS 4+ MVC. This post tries to state some experiences, so that it can help other companies and developers making wise decisions about opting Ext JS for a business requirement. We will explore Ext 4 MVC in general and salesforce point of view in the points below:

 

#1 Javascript heavy object oriented approach to create RIA

Ext JS is highly object oriented and disciplined approach to program almost everything in Javascript i.e. very less CSS and HTML code to write usually.

Benefits

Its quite easy to go wrong and unmanaged in Javascript when working on huge projects. Ext MVC sets good guidelines to organise your code well, and keep “M”, “V” and “C” separate.

So, even if multiple developers are programming in EXT MVC style, it would be easier for one developer to understand what other guy has done.

Issues

Huge learning curve is involved, even if you consider yourself ninja in HTML or Javascript skills. This is because learning Ext is almost like learning new language for generating same HTML/Javascript screens. So it means leaving almost all of your Javascript and HTML skills behind and start learning a new language built in Javascript.

This becomes bigger challenge when one tries to start with latest Ext 4.1 MVC. As, most of the examples on Sencha portal are non-mvc based, and their are very limited tutorials and help available online.

For me it was little bit comfortable because of past Flex and Swing experience, and close similarities between Ext and these technologies. But as both Flex/Swing are out dated now, I doubt others will get this comfort.

Finding right talent is very hard for Ext JS, I feel in general and in my professional circle jQuery + jQuery mobile is extremely popular. If I raise voice for any assistance in jQuery flood of help will come, but extreme reverse happened at least for me when I worked in Ext. I was working on Ext JS 4.1 MVC, help was required on MVC part, best I could find is few guys with some experience in Ext 3, and those are not motivated to learn Ext 4.1 MVC. So this makes it not only hard, but costly to find a correct resource for Ext JS, as this seems to be a rare skill for me.

 

#2 Ext gives Rich Container/Layouts

Flex or Java swing style layout model with plenty of good layouts like Border, Card, Table, HBox etc.

Benefits

These layouts are tested across all A-Grade browsers and take off complexity of arranging UI elements.

Issues

These layout is again something out of the world for some one coming with good HTML/Javascript experience.

Assuring good performance with such rich layout system is a challenge since flex/swing days. This is because to keep things in place and updated as per changes, it involves lots of client side javascript calculations, as developer doesn’t need to bother about it.  I haven’t tested this on really complex screens in Ext, but this might hurt if client’s machine is having less computing power i.e. Tablets, Netbooks etc

 

#3 Ext gives rich component library

Rich library components are available for everything ranging for Tabs, Grids, Buttons etc.

Benefits

Again, as with layouts these components give rich and stable interface, with cross browser stability and ease to developer.

Issues

None if you’re not in salesforce ecosystem. In Salesforce, its a dramatic UI change. A salesforce customer will feel like in different world if he stumbles upon an Ext JS screen.

 

#4 Ext gives rich variety of Proxies

Proxies are used by EXT for performing CRUD operations on Model, they usually tie up with store to provide the DAO layer. Variety of proxies to handle various forms of communication are available ranging from server side ones like Ajax, REST, Direct and client side like Memory, LocalStorage. For more details please check http://docs.sencha.com/ext-js/4-0/#!/api/Ext.data.proxy.Proxy

Salesforce developers can check the excellent code base by Jeff Trull for examples of using various Ext Proxies with different options in force.com platform like Ajax Toolkit, Javascript remoting, REST API etc, here is the link to the GitHub page: https://github.com/jefftrull/ExtJSWidgetsOnForceDotCom

Benefits

Clean isolation of data access via proxies is very helpful in big applications. Such proxies allow easy mocking of services in early stages of development, via MemoryProxy etc.

Apart from isolation proxy and store work really well to do handle common app requirements like

• errorMessage response

• pagination

• filtering

• sorting

• custom ID attribute mappings etc

All the above can be achieved by simple configuration.

Issues

On salesforce side these proxy doesn’t map really well, direct proxy is most reasonable option to be used with force.com Javascript remoting. Here is reason why:

• REST Proxy : This doesn’t easily maps Consuming REST services or Apex REST services in Salesforce, you need to write decent code in Ext just to make proxy work right with force.com REST services. A sample component for REST Proxy in force.com is here for reference.  Overall these are key disadvantages of using force.com REST services in Ext

  • Doing so much code to make Ext and force.com REST services talk defeats the purpose and beauty of EXT because thats not the business requirement, it turns more to be a GEEK’s experiment to make the assembly work.

  • If the Ext screens are in heavy use one can easily hit 1000/5000 API call limit in 24 hours or 25 concurrent call limit as well in case many users like customer portal or sites users are accessing the same page. More details here : http://login.salesforce.com/help/doc/en/integrate_api_rate_limiting.htm

• JSON Proxy: One can create a hacky visualforce page to give partial read and update support via this hack. But this doesn’t works well as all CRUD is not possible and code becomes unmaintainable for big apps.

• Direct Proxy: This somehow maps to force.com javascript remoting(JSR) with some fixes in Ext Direct fixture. This is best option to use as it doesn’t counts under API limits. But creating such a JSR fixture in force.com platform, that works with Ext is a project in itself for a new bie. One example component available here: https://github.com/jefftrull/ExtJSWidgetsOnForceDotCom/blob/master/components/ExtJS_Data_Grid_with_JSR.component This fixture is very generalized and requires some other fixes to make it work well in Ext 4.1 MVC, we will be sharing details on the same soon.

 

 

Conclusion : When is Ext JS right for Force.com Platform ?

Force.com platform comes with its on rich and fluent HTML interface, as a developer one should try to reuse native CRUD functionality via Standard/Custom object tabs as much as possible. In case one needs a custom complex screen, developers should try making best use of existing visualforce components like detail, pageBlock, sectionheader, pageBlockTable etc. This keeps your custom screens look like native and doesn’t creates a shock to salesforce users when they stumble upon your visualforce pages.

So, where does Ext fits in ? I would say we should use Ext very carefully only where its really required, we have really good examples in salesforce only i.e. most of the screens are in normal HTML/CSS only, complex ones like Page Layout editor is the one that requires a quick and rich experience on client side, so Ext is used. So developers should use rich ext components like grids, charts etc, where something beyond available visualforce components is really required.

Thanks

Special thanks goes to Jeff Trull he has done some amazing work with Ext and helped me in fighting Ext JS issues as well.