Web app dreaming
My scratch-list for features I want in 2009's web application framework
The view moves to the browser
We've been watching this happen bit by bit for a while, but for the most part people still think of web applications as a collection of "pages" - the 'url-driven state system'. This simply isn't efficient anymore, with things like Chrome and Firefox pushing Javascript to the next level on highly-capable browsers, our continual insistence on delivering one stupid page at a time is counter-productive. Frameworks like Cappuccino are, in their own idiosyncratic way, pushing people to understand the new reality - a web application is just that, an application, we're not using VT100's anymore.
Demands:
* The framework must provide an application skeleton that works primarily in javascript for the view, the 'application' downloads initially, possibly in segments on demand, and views are generated and manipulated from this rather than page by page.
* The framework must make use of native widgets and looks where-ever possible
* The framework must interact properly with CSS etc, rather than trying to replace it.
* The framework should not demand pixel-based placement but instead work with relative, flow based placement if desired.
* The framework must provide easy solutions for managing mobile displays, this need not be automatic.
* The framework need not support any browser slower/less capable than IE8.
* The framework must provide mechanisms to allow standard browser functions such as bookmarks and the back button to continue to function effectively.
The remote/local split
With the view moved to the browser to such a degree, the "things don't change until I hit refresh" approach has gone the way of the horse cart. The framework of 2009 must provide effective, efficient, rapid methods of communicating between the server and the client. People like the dojo guys have already starting working heavily towards much of this, their 'datastore' interface provides an abstraction over a collection helping to keep things in sync between the server and client.
This becomes ever more critical as we move into complex inter-relations between data on a server in a single view - adding a user changes not only the list of users on the page, but the user-count, and possibly changes billing details etc. All this needs to respond instantly, easily, and without pointless server load.
Associated with this is the dramatic change to what is essentially an event-driven model for views. Web application programmers are going to have to get used to the idea that pages are not static, but instead constantly changing in response to client and server generated events and messages.
Demands:
* The framework must provide event and message propagation via polling and comet as appropriate
* The framework should provide data with timeouts that trigger events
* The framework must provide easy-to-implement r/o and r/w data sources that transparently talk to the server to maintain sync via the event/messaging channel
Scaling and hosting
The framework of 2009 isn't the kind of thing you run on your $95/mn hosted server. A bare machine with an operating system is no longer the appropriate place for the hosting of a web application. Cloud services being made available now solve numerous problems that are extremely difficult and error-prone to handle on regular systems.
The need for reliability, scalability and uptime demand that the framework deploy on - and provide management tools for - cloud platforms that can scale up and down with demand and provide data backends that are inherently safe without the need for fiddly replication and backups.
Demands:
* The framework must provide trivial deployment to cloud platform(s)
* The framework must provide mechanisms for managing testing, pre-production, branches, production, testing and profiling on the cloud platform
* The framework must provide tools and patterns for managing off-cloud backups of critical data
* The framework must provide no-downtime methods for posting updates and rollbacks
Look, feel and use
As web based applications become faster, more responsive and more..application-like, people will start treating them more like applications. Chrome and others have acknowledged this tendency by creating one-click "Make this an app" buttons. The expectation will follow that the app look native where possible. This cannot be met in a cross-platform fashion with frameworks (like dojo and cappuccino) busily replacing widgets with their own - often ugly - versions.
Nor can we continue to ignore the need for more advanced, capable widgets. Tight integration with remote data streams, sorting, filtering, charting and graphical manipulation are the cornerstone of a powerful application.
Lastly, many aspects of user interfaces today demand visual clues that graphic designers and programmers often do a poor job of. Thing like icons indicating success or failure in an immediate visual form, icons for "new", "delete" etc.
Demands:
* The framework must provide widgets with data source integration for instant, no-code responsiveness to events.
* The framework must provide charts which respond to data sources
* The framework should provide widgets that respond appropriately to the write-status of a user
* The framework should provide an icon library for standard operations and visual events
Efficiency
The average web application today is hideously inefficient. Enormous chunks of layout, markup and data are redelivered with every request. As applications become more and more integrated into peoples lives - and as demand for up-to-the-minute information becomes greater, it is necessary to remove as much of this redundancy as possible. Efficiency in delivery can result in decreased server load, massively reduced bandwidth costs and much higher responsiveness for clients.
Demands:
* The framework must provide JSON based event and messaging transport
* The framework should provide tools for managing script and asset compilation and compression
* The framework should provide tools for easily managing CSS sprites to reduce connection overheads
* The framework must provide tools for managing cache settings for delivered content
Advanced data patterns
The amount of reinvention in various data areas is getting a bit stupid, and people are doing it poorly. Areas like full-text searching, data and database versioning, exports etc have been done enough now that we can select good quality patterns and provide support infrastructure for them.
Demands:
* The framework must provide trivial integration for full-text searching
* The framework should provide patterns for managing data versions ( for say, a row in a database )
* The framework should provide tools and patterns to help deal with database structure changes
Security
As time goes by, various classes of security attack are discovered, defenses are devised, and these are then slowly propagated out as developers stumble upon them (or get hacked). The framework of 2009 needs to provide defenses against all currently known attacks in a fashion that makes it completely transparent, or at least very easy, for the developer.
Things like XSS attacks on forms, lack of validation, failures to encode HTML entities etc should not happen without effort on the part of the developer.
Demands:
* The framework must provide anti-XSS form defenses
* The framework must demand validation on all user-supplied data
* The framework must default to displaying quoted entities whenever user-supplied data is rendered unless the developer explicitly overrides it
* The framework must provide functions for managing encoding, decoding and quoting entities as standard
* The framework should provide built-in authentication support, including OpenID in and out
* The framework should provide demonstration or default code which utilizes proper patterns for user data care, such as the three-level login state (none, from-cookie, fully authorized) and re-requests of password for changing critical user data.
* The framework must provide functions and widgets for password entry and rating
* The framework should provide code or patterns for classic attack vectors such as password resets
* The framework should provide patterns for dealing with classic race conditions like prepare-commit
* The framework must provide exception tracking, viewing, notification, application logs and methods for archiving/searching/filtering those logs
Testing
Testing is ever more critical. The massive uptake of agile approaches to web development has resulted in a lot of stuff going out partially functional, and a great deal of post-release breakage. While everyone understands the need to create test suites, full end-to-end testing is currently a difficult proposition - production platforms are often significantly different from test platforms, and a variety of data-related issues make it hard to test for conditions such as "this goes away 30 days later", resulting in releases that look fine, then go weird after some time - often after the developer has delivered the product.
The framework of 2009 acknowledges this issue and makes easy end-to-end testing a priority.
Demands:
* The framework must provide for the easy creation of end-to-end tests
* The framework must support pre-prod on alternate domains within the cloud platform to ensure the test platform is as near as possible to the production one
* The framework must provide not only functionality tests but performance tests, and profiling mechanisms in pre-prod to help identify hotspots
* The framework must provide libraries and support for clock-shifting, so that tests can 'change time' in order to properly test time-related operations
* The framework should provide mechanisms for result-recording and reporting
Supporting infrastructure
A large number of related areas are done over and over again in web applications, often poorly and in some cases this is extremely concerning - poor management of credit-card transaction state for example. The framework of 2009 needs to acknowledge both code and non-code areas where the requirements are common enough that proper, debugged, tested versions should be supplied by the framework.
Demands:
* The framework must provide a standardized interface for credit card payment gateway libraries, and other forms of payment like paypal. This interface should demand proper recording and state management.
* The framework should provide standard templates or tools for things like privacy policies, terms and conditions, site icons etc.
Easy to code
On top of all this, the framework of 2009 should be easy to code in. There is no place in 2009 for libraries and functions full of inconsistent usage, complex heavily-prefixed naming schemes, weird framework-specific replacements of standard language constructs like arrays, or invention of new wacky names for things that already have perfectly good standard terminology.
A wealth of examples is vital, every single API call should be used in a minimum of two examples so that any time the documentation isn't readily understandable actual in-use code can be checked and toyed with.
Demands:
* The framework must provide complete documentation on every single API call, including at least one example of use for each module
* The framework must provide a set of examples. Every API call must be used in a minimum of two examples
* The framework must be language-native, and avoid replacing standard language constructs
* The framework should support easy debugging via standard language support where possible, and a minimum of a debug console where not.
* The framework must provide APIs and libraries in a fashion which can be auto-completed by popular editors where at all possible.
* The framework should avoid magic which makes stack traces or errors difficult to read
Things I haven't mentioned
There's a ton of stuff I haven't mentioned, from accessibility to batch job support, but the above is pretty much the list of criticals I'm currently keeping in mind when watching new technology.
There is no question that the various things above are addressed in one form or another by someone, unfortunately there is no framework I'm aware of that comes close to matching all of the demands above.
Dojo probably comes closest, but is much more like a library a framework might use to achieve the above than a real solution. In addition they are progressively failing to acknowledge the importance of the native-look requirement, and things like their datastore APIs are difficult to implement. I won't even mention the highly variable and often contradictory nature of the documentation (but hey, at least they're trying).
In the end I'm a bit pessimistic at seeing a significant percentage of the above in a single place any time soon, but I can hope right?
The view moves to the browser
We've been watching this happen bit by bit for a while, but for the most part people still think of web applications as a collection of "pages" - the 'url-driven state system'. This simply isn't efficient anymore, with things like Chrome and Firefox pushing Javascript to the next level on highly-capable browsers, our continual insistence on delivering one stupid page at a time is counter-productive. Frameworks like Cappuccino are, in their own idiosyncratic way, pushing people to understand the new reality - a web application is just that, an application, we're not using VT100's anymore.
Demands:
* The framework must provide an application skeleton that works primarily in javascript for the view, the 'application' downloads initially, possibly in segments on demand, and views are generated and manipulated from this rather than page by page.
* The framework must make use of native widgets and looks where-ever possible
* The framework must interact properly with CSS etc, rather than trying to replace it.
* The framework should not demand pixel-based placement but instead work with relative, flow based placement if desired.
* The framework must provide easy solutions for managing mobile displays, this need not be automatic.
* The framework need not support any browser slower/less capable than IE8.
* The framework must provide mechanisms to allow standard browser functions such as bookmarks and the back button to continue to function effectively.
The remote/local split
With the view moved to the browser to such a degree, the "things don't change until I hit refresh" approach has gone the way of the horse cart. The framework of 2009 must provide effective, efficient, rapid methods of communicating between the server and the client. People like the dojo guys have already starting working heavily towards much of this, their 'datastore' interface provides an abstraction over a collection helping to keep things in sync between the server and client.
This becomes ever more critical as we move into complex inter-relations between data on a server in a single view - adding a user changes not only the list of users on the page, but the user-count, and possibly changes billing details etc. All this needs to respond instantly, easily, and without pointless server load.
Associated with this is the dramatic change to what is essentially an event-driven model for views. Web application programmers are going to have to get used to the idea that pages are not static, but instead constantly changing in response to client and server generated events and messages.
Demands:
* The framework must provide event and message propagation via polling and comet as appropriate
* The framework should provide data with timeouts that trigger events
* The framework must provide easy-to-implement r/o and r/w data sources that transparently talk to the server to maintain sync via the event/messaging channel
Scaling and hosting
The framework of 2009 isn't the kind of thing you run on your $95/mn hosted server. A bare machine with an operating system is no longer the appropriate place for the hosting of a web application. Cloud services being made available now solve numerous problems that are extremely difficult and error-prone to handle on regular systems.
The need for reliability, scalability and uptime demand that the framework deploy on - and provide management tools for - cloud platforms that can scale up and down with demand and provide data backends that are inherently safe without the need for fiddly replication and backups.
Demands:
* The framework must provide trivial deployment to cloud platform(s)
* The framework must provide mechanisms for managing testing, pre-production, branches, production, testing and profiling on the cloud platform
* The framework must provide tools and patterns for managing off-cloud backups of critical data
* The framework must provide no-downtime methods for posting updates and rollbacks
Look, feel and use
As web based applications become faster, more responsive and more..application-like, people will start treating them more like applications. Chrome and others have acknowledged this tendency by creating one-click "Make this an app" buttons. The expectation will follow that the app look native where possible. This cannot be met in a cross-platform fashion with frameworks (like dojo and cappuccino) busily replacing widgets with their own - often ugly - versions.
Nor can we continue to ignore the need for more advanced, capable widgets. Tight integration with remote data streams, sorting, filtering, charting and graphical manipulation are the cornerstone of a powerful application.
Lastly, many aspects of user interfaces today demand visual clues that graphic designers and programmers often do a poor job of. Thing like icons indicating success or failure in an immediate visual form, icons for "new", "delete" etc.
Demands:
* The framework must provide widgets with data source integration for instant, no-code responsiveness to events.
* The framework must provide charts which respond to data sources
* The framework should provide widgets that respond appropriately to the write-status of a user
* The framework should provide an icon library for standard operations and visual events
Efficiency
The average web application today is hideously inefficient. Enormous chunks of layout, markup and data are redelivered with every request. As applications become more and more integrated into peoples lives - and as demand for up-to-the-minute information becomes greater, it is necessary to remove as much of this redundancy as possible. Efficiency in delivery can result in decreased server load, massively reduced bandwidth costs and much higher responsiveness for clients.
Demands:
* The framework must provide JSON based event and messaging transport
* The framework should provide tools for managing script and asset compilation and compression
* The framework should provide tools for easily managing CSS sprites to reduce connection overheads
* The framework must provide tools for managing cache settings for delivered content
Advanced data patterns
The amount of reinvention in various data areas is getting a bit stupid, and people are doing it poorly. Areas like full-text searching, data and database versioning, exports etc have been done enough now that we can select good quality patterns and provide support infrastructure for them.
Demands:
* The framework must provide trivial integration for full-text searching
* The framework should provide patterns for managing data versions ( for say, a row in a database )
* The framework should provide tools and patterns to help deal with database structure changes
Security
As time goes by, various classes of security attack are discovered, defenses are devised, and these are then slowly propagated out as developers stumble upon them (or get hacked). The framework of 2009 needs to provide defenses against all currently known attacks in a fashion that makes it completely transparent, or at least very easy, for the developer.
Things like XSS attacks on forms, lack of validation, failures to encode HTML entities etc should not happen without effort on the part of the developer.
Demands:
* The framework must provide anti-XSS form defenses
* The framework must demand validation on all user-supplied data
* The framework must default to displaying quoted entities whenever user-supplied data is rendered unless the developer explicitly overrides it
* The framework must provide functions for managing encoding, decoding and quoting entities as standard
* The framework should provide built-in authentication support, including OpenID in and out
* The framework should provide demonstration or default code which utilizes proper patterns for user data care, such as the three-level login state (none, from-cookie, fully authorized) and re-requests of password for changing critical user data.
* The framework must provide functions and widgets for password entry and rating
* The framework should provide code or patterns for classic attack vectors such as password resets
* The framework should provide patterns for dealing with classic race conditions like prepare-commit
* The framework must provide exception tracking, viewing, notification, application logs and methods for archiving/searching/filtering those logs
Testing
Testing is ever more critical. The massive uptake of agile approaches to web development has resulted in a lot of stuff going out partially functional, and a great deal of post-release breakage. While everyone understands the need to create test suites, full end-to-end testing is currently a difficult proposition - production platforms are often significantly different from test platforms, and a variety of data-related issues make it hard to test for conditions such as "this goes away 30 days later", resulting in releases that look fine, then go weird after some time - often after the developer has delivered the product.
The framework of 2009 acknowledges this issue and makes easy end-to-end testing a priority.
Demands:
* The framework must provide for the easy creation of end-to-end tests
* The framework must support pre-prod on alternate domains within the cloud platform to ensure the test platform is as near as possible to the production one
* The framework must provide not only functionality tests but performance tests, and profiling mechanisms in pre-prod to help identify hotspots
* The framework must provide libraries and support for clock-shifting, so that tests can 'change time' in order to properly test time-related operations
* The framework should provide mechanisms for result-recording and reporting
Supporting infrastructure
A large number of related areas are done over and over again in web applications, often poorly and in some cases this is extremely concerning - poor management of credit-card transaction state for example. The framework of 2009 needs to acknowledge both code and non-code areas where the requirements are common enough that proper, debugged, tested versions should be supplied by the framework.
Demands:
* The framework must provide a standardized interface for credit card payment gateway libraries, and other forms of payment like paypal. This interface should demand proper recording and state management.
* The framework should provide standard templates or tools for things like privacy policies, terms and conditions, site icons etc.
Easy to code
On top of all this, the framework of 2009 should be easy to code in. There is no place in 2009 for libraries and functions full of inconsistent usage, complex heavily-prefixed naming schemes, weird framework-specific replacements of standard language constructs like arrays, or invention of new wacky names for things that already have perfectly good standard terminology.
A wealth of examples is vital, every single API call should be used in a minimum of two examples so that any time the documentation isn't readily understandable actual in-use code can be checked and toyed with.
Demands:
* The framework must provide complete documentation on every single API call, including at least one example of use for each module
* The framework must provide a set of examples. Every API call must be used in a minimum of two examples
* The framework must be language-native, and avoid replacing standard language constructs
* The framework should support easy debugging via standard language support where possible, and a minimum of a debug console where not.
* The framework must provide APIs and libraries in a fashion which can be auto-completed by popular editors where at all possible.
* The framework should avoid magic which makes stack traces or errors difficult to read
Things I haven't mentioned
There's a ton of stuff I haven't mentioned, from accessibility to batch job support, but the above is pretty much the list of criticals I'm currently keeping in mind when watching new technology.
There is no question that the various things above are addressed in one form or another by someone, unfortunately there is no framework I'm aware of that comes close to matching all of the demands above.
Dojo probably comes closest, but is much more like a library a framework might use to achieve the above than a real solution. In addition they are progressively failing to acknowledge the importance of the native-look requirement, and things like their datastore APIs are difficult to implement. I won't even mention the highly variable and often contradictory nature of the documentation (but hey, at least they're trying).
In the end I'm a bit pessimistic at seeing a significant percentage of the above in a single place any time soon, but I can hope right?
Labels: web app 2009 framework
posted by PhiRatE at
10:52 PM
1 Comments
