evanr76
1 Jun 2007, 3:45 PM
I'm a couple weeks into an ExtJS-based project and I'm pretty hooked.
The project is from scratch and the UI is built completely dynamically from Ext components. Coming from an early 2000's web development mentality, I have had to unlearn or at least set aside a lot of ingrained notions about web development to get this far.
While the app looks and works great, and development time has been drastically reduced, I continue to have this nagging feeling that the deeper I go, the more committed I will be to a strictly rich app, and the harder it will be to go back and create a "lightweight" experience for some of the application functions: for legacy browsers, mobile devices, or simply users who prefer a lighter experience. Ext makes it so easy to forget about these fringe users but experience tells me they are out there!
How to solve this? I envision a server-side UI component framework that could complement Ext. This framework might be realized in the form of a JSP taglib, Symfony "helpers", etc.
The framework would assist in a few key ways:
Client (browser) feature detection
Abstracting the Ext components we know and love (trees, grids, dialogs, forms, etc.) into server-side equivalents
Providing implementations of those components which would use the browser feature profile to provide just the right combination of client- and server-side functionality, to degrade the experience to the lesser of
The client platform's abilities
The user's preferences ("I run Firefox 2.0 but prefer a lightweight app sometimes")
Examples of degradations that such a framework might help facilitate:
Degrading event production/consumption into form submission/processing and links
Degrading pop-up windows into page inlays
Degrading dynamic visual components (trees, grids, etc.) into server-generated HTML/CSS equivalents
Degrading client-side state into server-side (session) state
This might be a pipe-dream, and it is a given that such a "one-size-fits-all" experience is going to have compromises, but it could provide a starting point, and would sure beat writing the app twice.
I'll add this one to my to-do list :D
The project is from scratch and the UI is built completely dynamically from Ext components. Coming from an early 2000's web development mentality, I have had to unlearn or at least set aside a lot of ingrained notions about web development to get this far.
While the app looks and works great, and development time has been drastically reduced, I continue to have this nagging feeling that the deeper I go, the more committed I will be to a strictly rich app, and the harder it will be to go back and create a "lightweight" experience for some of the application functions: for legacy browsers, mobile devices, or simply users who prefer a lighter experience. Ext makes it so easy to forget about these fringe users but experience tells me they are out there!
How to solve this? I envision a server-side UI component framework that could complement Ext. This framework might be realized in the form of a JSP taglib, Symfony "helpers", etc.
The framework would assist in a few key ways:
Client (browser) feature detection
Abstracting the Ext components we know and love (trees, grids, dialogs, forms, etc.) into server-side equivalents
Providing implementations of those components which would use the browser feature profile to provide just the right combination of client- and server-side functionality, to degrade the experience to the lesser of
The client platform's abilities
The user's preferences ("I run Firefox 2.0 but prefer a lightweight app sometimes")
Examples of degradations that such a framework might help facilitate:
Degrading event production/consumption into form submission/processing and links
Degrading pop-up windows into page inlays
Degrading dynamic visual components (trees, grids, etc.) into server-generated HTML/CSS equivalents
Degrading client-side state into server-side (session) state
This might be a pipe-dream, and it is a given that such a "one-size-fits-all" experience is going to have compromises, but it could provide a starting point, and would sure beat writing the app twice.
I'll add this one to my to-do list :D