Benefits Of Using A WebRocketX SPA

Below is listed the most notable benefits

• Every navigation is faster - The browser is only getting the new content when the user navigates. It is no longer reloading the page head, and all the javascript files, and stylesheet files. It is no longer parsing the javascript again because that all happened when the user entered the welcome page. Back navigation comes out of the browsers memory even when the previous page was the result of a post. The combination of caching and lighter trips makes everything quicker, and also puts less load on your organizations servers.
• The browser back button works - The framework automatically takes care of the browser back button. This might seem simple but it is one the most problematic things web developers have to deal with. For example, go to your favorite hotel or airline website. Enter your reservation information, bring up the available flights or rooms, but then decide that you would like to go on a different date and use the browser back button to return to the search screen. On almost every major website you will have to re-enter a bunch if not all of the fields, and there is usually a big pause when the page comes up like you did something wrong. Annoying right? This won't happen anymore in WebRocketX. Everything the user typed on the previous screen is still right there when you go back to it. It stayed in the browsers memory and no trip to the server is needed to go get it. That page will also come up instantaneously.
• Side flows are now easily coded - Sideflows are one of the most difficult problems that a developer has to deal with in the full page paradigm. To understand what a side flow is we will walk through a use case.
  
  Imagine a user is filling out a long customer form online and has already entered their name, address, phone number and other information. They then arrive at an employer autocompleter. However, when they attempt to enter their employer, they find that the employer is not present. The web application does have another flow that allows an employer to be entered but it is not part of the customer flow. It is not acceptable to expect the user to lose all of their data entry and jump into this other flow, enter their employers record, and then return and start the customer flow all over again. So, instead the developer has to create a side flow. The developer has to persist all of the entered fields to the server, skipping validation because the entry is not complete, go through the create employer flow, and then return to the customer flow, fill out autocompleter with the new employer, and allow the user to pick up where they left off.
  
  As can be imagined, creating side flows like this in the world of full page refresh is difficult. The developer wants to enter the create employer flow and reuse all of those screens from the normal create employer flow, but they have to create new controllers that present those pages when being used from a different point of origin. Furthermore, they need to return to the customer flow from the last page in the create employer flow, which is actually a different point of entry than either the create customer or create employer flows. Now imagine how much worse everything gets when the create employer flow is used in a third flow as an additional side flow. The result of sideflows and sideflow reuse is simply controller sphagetti, no matter how good a job the developer does at trying to keep the code maintainable.
  
  Now let's imagine how differently this plays out with our HTML injection SPA. The user fills out the first half of the customer form, then presses a button to enter the create employer flow. The customer form is simply kept invisible in the browser queue complete with the filled out information. The user fills out the create employer screens and submits the new employer info to the server. The create employer flow, being encapsulated is self contained and therefore behaves like a reusable component that can be brought up anywhere in the application. When the user commits the new employer they simply go back to the customer form using the standard framework back call and the employer name and account number is copied to the customer form using javascript and the user moves on. Since the relay of the information was done in the browser no server side controller mappings were required to stitch these flows together. Also, no development effort was needed to preserve the users previous input. Yes, some extra logic was required in the create employer flow so that it knows that it is not a stand alone flow, but it is minor. Also, if the side flow will be used in multiple places, than a javascript publish subscribe mechanism should be used to copy the employer values to the customer form. Regardless, the sideflow is substantially more simple to code than in a full page refresh paradigm.
• Stale pages can be reloaded declaratively - By setting the pageReload attribute to true a developer specifies that a page will always be retrieved from the server when the user returns to it. This way the developer has a choice as to whether a page comes from the cache or from the server. The framework automatically stores all the details of the request that retrieved the page previously so that they can be sent again.
• Modal dialogs are built in - HTML based modal dialogs are structured, easy to implement, and can be stacked up indefinitely, removing the need for buggy browser pop ups that can get lost on the users desktop.
• User interaction is controlled - A problem with ajax calls is that the user can press buttons and change values while calls the server are in progress. This can make coding difficult for the developer and there are lots of ugly solutions out there like putting up a message telling the user not to press the button again, or disabling and changing the color of an individual button after that button is pressed. WebRocketX by default blocks user interaction with the interface during calls and therefore eliminates the need for all of these messy and labor intensive solutions. It also by default changes the cursor to show progress and gracefully returns to interactive mode if there are javascript or server side errors. We don't want the user being stuck with an unresponsive screen if something goes wrong, and that doesn't happen.
• Server side error handling is standardized - The handling of server side errors is standard and built in. Very few frameworks help the developer with handling errors. This takes a lot of the responsibility off of the developer and also forces them to handle errors consistently.
• Application development is much more efficient - One of the most challenging things a web developer has to deal with is navigation. As described above, WebRocketX makes coding navigation simple. Error handling is also difficult and that is also taken care of. Controlling user interaction is complicated and that is also already done automatically. Also, since more state is kept in the browser, the developer does not have to display state between pages in multi step flows which eliminates close to 50% of the mappings needed in the server side controller. All of the operations the developer has to deal with become more atomic and targeted, meaning only new data has to be pulled into flows until the flow is complete, at which time everything can be persisted to the database backend.
• Improved user experience - Lastly but most importantly, all of these other benefits will result in an enhanced user experience. Your web application will behave much more like a desktop based application and will also be more reliable than other web applications. The extra time that developers normally spend pulling their hair out over navigation and other issues can now be spent creating a rich user experience.