To view the webinar, please visit the Sencha Channel on BrightTalk
At the end of the presentation (~56:00) we received a few interesting questions that we simply didn’t have the time to answer. We promised to follow-up on these questions — so here are our responses:
Table of Contents
This was one of the major concerns we raised during the presentation. As you point out, many other enterprise technology platforms (e.g. Java) have far longer release cycles compared to web technologies. In fact, Wikipedia cites roughly two years between the major versions J2SE 5 and Java SE 6.
Sencha however has firmly aligned itself with the needs of the enterprise, and we learned a lot from the experience of our customers during the Ext JS 3 > 4 migration. First we made sure that our latest release (Ext JS 5) offered a smooth upgrade from 4.x. Second, we kept support for the legacy browsers our enterprise customers still require. Third, based on our customer’s upgrade experiences, we have made upgrade paths and backward/forward compatibility a standard roadmap item.
What rule/commitment does Sencha have on supporting older browsers? For example, when will you stop supporting IE8?
The only rule Sencha has for deciding which browsers to support comes from what our customers tell us they need.
When we first released Ext JS 4.0 in 2011, the browser landscape looked a bit different than it does today. Internet Explorer 6 still had significant market share, and Chrome had only just begun its shorter 6-week release cycles. Mobile browsers were far from mature, and at the time, few enterprise companies had mobile strategies.
The browser landscape today is much different, as are the requirements for enterprise web applications. While the need to support Internet Explorer 8 is clearly still a priority for our customers, only a few organizations require anything older (and for those customers, we are supporting them via customized extended support programs). On the other hand, many of our customers also specifically asked us to begin supporting mobile browsers — particularly for use on tablets. Therefore, Ext JS 5.0 (released earlier this year) evolved with the needs of our customers.
When will we stop supporting IE8? Certainly not in the immediate future. The majority of our enterprise customers tell us they still need to support IE8, and this aligns with research from Net Market Share that legacy Internet Explorer still commands a sizeable chunk of IE usage.
Legacy browser support is truly one of the features that sets Ext JS apart from our competition — so while we plan to continue innovating with new features, we also plan to continue evolving with (and not away from) our customers.
Micro-frameworks are specific. How can Sencha guarantee best-in-class features for each specialization?
I mentioned in the webinar that micro-frameworks, by definition, only strive to implement a subset of the functionality needed by enterprise applications. This isn’t necessarily a bad thing — as you point out, micro-frameworks can provide best-in-class features by specializing in their area of expertise.
Taking that point on its own, you might argue that it can be difficult for Sencha to compete with micro-frameworks that specialize in certain areas. One example might be charting and visualizations: Ext JS ships with charting and visualization packages, but how can Sencha guarantee ours are “the best”? There are several parts to this answer.
First, asking which framework is “best” is always a loaded question. Does “best” mean quality? Performance? Extensibility? It’s an entirely subjective analysis, and ultimately “best” is only true in given situations. From our perspective, Ext JS offers an extensible framework in which all of the features are fully integrated. We guarantee you’ll be able to easily modify and extend every class in our framework if the built-in features don’t meet a specific need; moreover, you’ll be able to do this using a consistent code style. Micro-frameworks typically don’t guarantee that because they’re specialized, so in cases where a library doesn’t perfectly fit your needs you are often stuck hacking away at code not intended for customization or extensibility.
Second, you need to consider that micro-frameworks are not used in a vacuum. A specialized charting library needs to be wired into the rest of your application stack — work that can be very tedious as none of the moving parts are fully integrated.
And finally, it’s important to find the right tool for the right job. Ext JS is ideal for building feature-rich and complex line-of-business applications — and while our framework delivers the overwhelming majority of features an enterprise application needs, there may indeed be cases where you want to pull in a third-party library to do something Ext JS doesn’t specialize in (e.g. cryptographic algorithms). Ext JS can play nicely with other libraries — the webinar just warned against complicated dependency chains as they cause problems for long-term maintenance.
What gains are you seeing in HTML5 performance for Sencha apps as it relates to overtaking native apps and becoming the standard for mobile app development?
Sencha engineer Ross Gerbasi recently wrote an article discussing how HTML5 performance on iOS 8 has gained a lot of speed — but that there are also some bugs that still need to be addressed.
During the webinar, we briefly talked about different approaches to building applications. It is hard to beat the performance of native apps with HTML5 simply because native apps are built with technology one step closer to the physical OS, but HTML5 applications can still achieve fantastic speed. Sencha proved this two years ago with our Fastbook demo, and since then others have also built impressive HTML5 apps with performance so good that users can’t tell whether-or-not they’re native.
Our take is that HTML5 already offers great performance for mobile apps, and it will continue to improve to the point where “performance” is good enough that we stop asking this question.
How do you secure your framework? Basically, how would a customer have assurances that it’s secure enough?
Security is definitely a big issue for enterprise applications, but application security also comes in many flavors. Browser applications are inherently insecure as the runtime is open for anyone to debug, so let’s examine how Sencha tackles security.
In the Ext JS framework, many of our classes can be configured to help mitigate common security threats. For example, Ext.ElementLoader automatically prevents remote scripts from being loaded unless configured otherwise. Classes that enable user input (e.g. Ext.form.field.Text) can easily be configured to prevent the direct input of certain characters or expressions, and can also be configured to validate their input on submission. Ext JS also ships with a number of utilities (e.g. Ext.util.Format.stripScripts and stripTags) that enable the developer to implement security as needed.
But as I already mentioned, the browser is inherently insecure. Even if the client application prevented direct user input, savvy developers can easily open their debugging tools to manipulate script logic, DOM interactions or access localStorage. At the end of the day, a client application running in the browser must rely on server-side and network security.
For mobile applications built with HTML5, having your web application wrapped with tools like Cordova might make this more difficult for a hacker — but unfortunately, Cordova applications are still not completely secure.
We created Sencha Space specifically to address the enterprise concerns around building secure mobile applications with HTML5. Our recent white paper goes deeper into the security details to discuss how Sencha Space can help to lower risk, strengthen security, and lower the total cost of ownership for application and data mobility.
We really hope you enjoyed last week’s webinar — please join us in November to hear about what is new in Sencha Space 1.2, and how Sencha Space makes it easier to develop and deploy secure cross-platform HTML5 applications!