The sad truth now is that both approaches often lead to hard-to-maintain products that don’t scale gracefully and are a pain to make accessible, localise to different languages or customise to different needs and channels. This is caused by false assumptions made by practitioners of both approaches:
The framework approach relies on a silver bullet and approaches web development with fat-client application ideals from higher programming languages like Java or C++. This does not take into consideration the fact that web development is a discipline that operates with great uncertainties regarding the nature of client-side hardware and software. Optimization has to be for the user and not for the developer (although these don’t necessarily have to be mutually exclusive).
The web standards approach would not be a problem at all if people would follow standards with the goal of making things easier by following an agreed approach and not see following the words of the W3C to the last detail as the only way to do things. Web standards are there to take the randomness out of web development and not to act as a policing tool.
The crux of the matter is that we don’t really yet understand how to build a real web application. We take tried and true methodologies that cover other development scenarios and try to shoe-horn them into something that helps us to achieve what we want on-time and within budget (and when was the last time that happened?).
The other problem is that we approach web application design with browser limitations in mind and plan only for what browsers can do rather than what the application should offer the user.
When it boils down to it, the main differentiator of a web application and a web site is that an app has much more interaction and is process-focused rather than content-driven. Users come in to achieve a goal: They provide data to the application, they use the application to enhance that data, and then they expect data to come out. They interact with components of the application and expect them to do something that brings them closer to their goal. It is of utmost importance that we plan for how users interact with the product and react accordingly.
When trying to accomplish this in the browser, there is one core technique at our disposal: Event handling.
We must try to understand what an event is when it comes to user interaction through the duration of a user session.
Something happens to an element, to the main document, or to the browser window and that event triggers a reaction. For example, the window finishes loading and on that event we start an initialization method; or the user clicks a link and we use that event to trigger another function.
The DOM Event Model however goes a bit further. It has a more granular definition of the workflow:
Something happens; an event occurs.
The investigation begins what element was activated and how. This happens by questioning each element from the window to the body to the first child node and so on until the element that was activated, the event target, is reached. This is called event capturing.
When the element is reached, the process of reporting goes back up through the DOM right back up to the window. This is called event bubbling.
You can intercept events on both legs of this journey at any time by adding event listeners to either the window or any of the objects that get queried. Event listeners define what event to look out for (click, keypress, load, mousedown…), the object to which the handler should be applied, and what method to call when it happens.
You can stop events from going back up to the window by calling a cancelEvent() method and you can retrieve the object the event occurred on, the event target, with a helper method called getTarget().
You can add as many listeners waiting for as many different events and each calling as many methods as you like.
Understanding and implementing this event model can free your application from the constraints of defined elements. For example, instead of applying an event listener for each link in a menu, you can assign a single listener to the menu item itself and retrieve the event target. That way you don’t need to change your script when the menu gets larger or when links get removed from it.
This is a very powerful and flexible approach often referred to as event delegation. Event delegation allows you to react to changes in the document while applying fewer event listeners. You can assign different handlers to different parts of your document (the menu, the main content, a sidebar, a language change menu) and define methods for each event (was it clicked? was a key pressed on it?). These methods then retrieve the element that was affected and react accordingly; for example, you can react differently for links versus buttons.
When using this idea (waiting for an event, investigating where it happens and acting accordingly) in web applications we mostly confine ourselves to what the browser reports us — the DOM events. This is not really necessary, and it’s a big limitation. Much that happens in an application — like a user switching between tabs in a TabView Control — could be thought of as an event and dealt with in the same manner.
Reader Feedback: Page 1 of 1
riccardo molti commented on 21 Nov 2007
So web developers are now 'Front-end engineers' - I like it! Let em start looking at Yahoo! UI, sounds cool.
The standardization of container runtimes and images has sparked the creation of an almost overwhelming number of new open source projects that build on and otherwise work with these specifications. Of course, there's Kubernetes, which orchestrates and manages collections of cont...
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing sm...
DXWorldEXPO | CloudEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need t...
@DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City. From showcase success stories from early adopters and web-scale businesses, DevOps is expanding to organizations of all sizes, including the worl...
DXWorldEXPO LLC announced today that Dez Blanchfield joined the faculty of CloudEXPO's "10-Year Anniversary Event" which will take place on November 11-13, 2018 in New York City. Dez is a strategic leader in business and digital transformation with 25 years of experience in the I...
Your registrations includes: Golden Pass Delegates will receive full conference access on October 20-22, 2008 including: Lunch and Coffee Breaks, Collectible Bag and Archives of all sessions on DVD. Includes access to all Conference Sessions including the Technical Sessions, Exhibits, Keynotes, Vendor Technology Presentations, and Power Panels.
AJAXWorld offers the undisputed best platform to position your company as a leading vendor in the fast-emerging marketplace for AJAX and Enterprise Web 2.0.
Who Should Attend?
• CTOs & VPs of Engineering
• Directors of Technology
• Sr. User Interface Architects
• Front-End Engineers
• VCs & Industry Analysts
• Directors of Business Development
• Software Engineers
• Senior Architects
• Application Programmers & Software Developers
• Project Managers
• Web Programmers & Designers
• Companies & Organizations that need to stay in front of the latest Web technology
AJAXWorld Security Bootcamp
Introducing at AJAXWorld RIA Conference 2008 West the world's first-ever full, one-day immersive "AJAX Security Bootcamp" - led by one of the world's foremost AJAX security experts and teachers, HP's Billy Hoffman.