Is ‘lightweight’ always a good thing?
Business applications are supposed to improve productivity.
That is why they exist. However, as developers, we sometimes get excited about a newly released technology and the benefits it claims. We can then end up adopting technology that actually degrades the final product – creating a less productive UI, and even ruining performance, despite promising performance claims.
At Isomorphic, we see this happening with a lot of companies that get excited that there is a framework that can deliver a basic grid component with a very small amount of source code – but this is the wrong focus, because such “lightweight” components not only damage productivity due to their lack of features, they also damage the real-world performance of applications, as we shall explain.
So, what drives productivity in today’s web applications?
End user productivity – from a platform perspective – is driven by:
- Advanced UI features (i.e. performing activities with fewer steps / clicks / screens / actions)
- Performance & scalability (i.e. getting the result of each activity faster)
Can we build high-productivity applications with ‘lightweight’ technologies?
There are a number of areas where ‘lightweight’ technologies consistently fall short, or fail to understand the true enterprise requirements:
1. Wrong performance focus
People are excited about “lightweight” grids, which claim to be able to render 10,000 or more rows in a reasonable time in the latest browser. Developers often think this means that they can skip implementing data paging, and can use client-side filtering and sorting to improve performance. The reality:
- the reason not to load 10,000 rows is the database, not the browser. It’s not important that a grid can render a lot of rows all at once. The purpose of loading rows incrementally was always to avoid unnecessary database and application server load, as well as avoid wasted bandwidth.
- 10,000 rows is not a reasonable upper bound – nor is 100,000. Business data sets routinely get much larger, especially when you consider administrative interfaces that look at data from many users at once. If you ship an application that expects to load all data up front, it will break in production as data volumes go higher than you had assumed.
- client-side filter & sort is achievable with Isomorphic grids – but not with lightweight grids. Our Adaptive Filtering technology automatically switches to client-side sort & filter when data sets are smaller, so you can handle extremely large data sets and reduce server load and bandwidth use. This capability is why Isomorphic grids dominate performance comparisons that simulate actual end-user behavior.
- you can only render rows faster by removing features. Isomorphic’s grid component uses a complex HTML structure because it supports a huge variety of productivity features like auto-sizing of both rows and columns, on-the-fly column freezing, row-spanning cells, components embedded in rows, on-the-fly grouping, as well as many developer override points that require particular HTML structures in order to work. We know exactly what simplifications would result in rendering more rows per second. We intentionally don’t apply those simplifications because they would remove productivity features, while not actually improving real-world scalability or performance.
2. Productivity comes from feature-rich components, not “lightweight” ones.
Consider grid components. End users need capabilities like edit inline, freeze columns, grouping and sorting, formula columns, adaptive filtering, hiliting, export, drag & drop, etc. Without these and other features, performing simple tasks requires end users to complete multi-step processes. For example:
- With edit inline: end users click a row or cell, edit the data, then move on.
- Without edit inline: end users select a record, click an edit button, are taken to another screen, perform the desired update, save the record, and return back to the starting point – hopefully without losing context.
Without feature-rich components, your application can become a frustrating time sink rather than a productivity tool.
3. Forgetting something? Server integration!
Some of the most powerful features in modern UI technologies span both the client and server. Examples from Isomorphic’s technology include:
- single source validation & security rules. Validation rules declared in one place are enforced on the server (for security) and the client (for immediate feedback)
- automatic UI generation. Grids, forms and other components can be automatically configured from server-side artifacts such as Java beans and database tables, greatly reducing redundant declarations and making applications easier to maintain
- exports. Isomorphic’s UI components know to coordinate with our server framework to export themselves and their data to Excel, PDF and other formats. Every application needs this; it can be a huge effort to build from scratch.
- .. and this only scratches the surface of features that a modern client & server framework provides.
- Starting from a ‘lightweight’, client-only framework puts you years behind the state of the art for UI technology, before you even consider which UI components to use.
4. Mixing components never worked, and still doesn’t
Most of the new crop of ‘lightweight’ frameworks emphasize the ability to plug in components from different sources, so you can get the best of each component type. This should all work since they share a common data-binding system, right?
Wrong, unfortunately:
- accessibility requires intensive coordination between components about tab order, modality, and ARIA markup. Really trivial cases where just a few rudimentary components are combined will appear to work, however, when you have a lot of instances of dynamically change tab order, multi-level modality and the like, there’s no way to get components from different sources to work together and actually pass accessibility tests
- skinning conflicts.Each component has a slightly different look and feel, and it can take a lot of work to correct the mishmash of different fonts and styles so that an application looks reasonably consistent, especially since, when fonts are made consistent, the sizes of various controls and sub-controls used in the app may need to be adjusted to fit the adjusted fonts. Also, some frameworks make conflicting assumptions about CSS they can globally apply to the whole page, breaking other frameworks or components on the same page (e.g. Bootstrap)
- export and print support. A rare feature among ‘lightweight’ components, yet most applications require it, and just one component lacking support can ruin the ability to print or export a particular screen or report.
- internationalization and localization. Pulling components from multiple sources typically means that localization work has to be repeated for each component, as every component needs the local word for “OK”, or to be told what date format to use
- inconsistent quality and endless evaluation. There is the practical consideration of whether it makes sense to constantly hunt for components. One grid has inline filtering but no frozen columns. Another has frozen columns, but no ARIA support for inline editing. A third has a nice date filtering interface, but it looks and operates completely differently from a date filtering interface you’re using outside of the grid, which will surely lead to user confusion.
- support. Even if you succeed in finding a workable set of components, you may find later on that your bug reports are ignored by one team or another. If support is even available for your chosen components, how many separate support agreements will you be purchasing? What about the many bugs that are not quite just one vendor’s fault? For the many single-component OSS projects, is there any reason to think the project will last as long as you need to maintain your application?
So, is ‘lightweight’ always a good thing?
No, it’s not … especially when you’re up against heavyweights. SmartClient has the richest set of UI components available, coupled with deep server integration to bring productivity and performance to your enterprise applications.
