Henrik,
I just don't see a reason to avoid SPAs for replacing 5250 green screens when so many website are successfully using SPAs in the wild. Many people feel the experience when using an SPA is faster and more fluid than the experience when using traditional web applications. The users get a more desktop-application-like experience. A faster, more fluid, more desktop-application-like experience seems like something one might want when replacing 5250 green screens.
Here we have to remember that while 5250 has existed for many
decades the lifespan of a web application is maximum 5 years or
shorter and there is traditional no back-level support when technology
change. EXT JS 3.x doesn’t run on EXT JS 5.x and Angular 1.x doesn’t
run on upcoming Angular 2.x so the bigger the old code base are the
more expensive it is to move.
First, with respect to lifespans of applications...
For me, it doesn't make sense to make broad-brush comparisons between 5250 green screens and browser-based GUIs. Reasons other than the technology on which they are built determine the lifespan of each. For example, part of what contributes to the long life of 5250 green screens is the fact that RPG\COBOL developers never learn to do anything else. As a result, many of those long-lived 5250 green screens are actually preventing users from having the benefits of contemporary GUIs.
Plus, the idea that web applications have a maximum lifespan of 5 years is simply incorrect. A web application or an SPA is not like milk that goes sour after a certain amount of time. Google's Gmail has been an SPA since 2004. Eleven years and going strong shows that SPAs can have long lifespans.
Second, with respect to changes in SPA frameworks...
Google is the creator of Angular. Yes, Angular 2 is not backwards compatible with Angular 1. This is because Angular 2 is going to be a better framework based on lessons learned from Angular 1. The improvements simply break the Angular 1 way of doing things.
But the situation isn't as dire as it might sound. Here's a news article from InfoQ talking about the change from Angular 1 to Angular 2:
http://www.infoq.com/news/2015/03/angular-2-concerns-addressed
First, Angular 1 is still being developed and will continue to have enhanced versions released in the future. The Google team has said: "We'll continue releasing Angular 1 releases until the vast majority of you migrate to Angular 2." Second, there is now an incremental migration path from Angular 1 to Angular 2. The news article says: "It was announced today that using the new router, a new "incremental" migration path would allow developers to transition from 1.X to 2.0. Because ng-router is one of the first components to span both 1.X and 2.0, it is a natural point developers can use to include pieces of 2.0 in their 1.X apps and also 1.X views in their 2.0 code. This option may not be good for mobile apps as it requires a larger payload, but it offers a way to ease the transition."
Thanks,
Kelly
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Henrik Rützou
Sent: Saturday, May 23, 2015 3:30 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Single Page Applications
Hi Nathan
SPA (Single Page Application) is just another acronym for rich UI client centric web development, FDA (Front-end Driven application) or whatever you want to call it. The technique has been around for years in EXT JS but the acronym probably is “invented” in the similar Angular/Bootstrap group.
A comparison of EXT JS and Angular (that uses two different models) can be found here:
http://www.techferry.com/articles/ExtJS-vs-AngularJS.html
SPA isn’t necessary “responsive” or “adaptive” – it all depends on the application where desktop based Business Applications seldom has a responsive design while it is used in modern homepages and CMS systems. The reason is obvious since an ERP system has too much information to be run on an Apple Watch while you may develop small specialized apps around the ERP that could run on small devices.
Basically SPA moves the UI controller from the server to the client and leaves the server as a “simple” data resource. So the server is back to SOA (Service Oriented Architecture) that serves or consumes data through either AJAX/HTTP/REST/CRUD or websockets.
It is correct that SPA’s has very high bindings between HTML/DOM and javascript and CCS (one way or another) so the traditional server centric framework that generates HTML isn’t really suitable for SPA development.
This does however not mean that you have no user and session management on the server. SOA requires (if any) server side session and request management since SOA/REST services is generic services that can be reached from any URL on the net and thereby is exposed to any that can read the source of the SPA and use the URL’s specified in the code so the server needs to be able to delegate access, bindings and user rules from the login to specific SOA/REST services without passing information to the client that jeopardize the security.
Now I don’t want to start a theoretical discussion about acronyms. I have worked with EXT JS since 2008 and it is based on SPA, however it is not clean SPA but rather extendable SPA or ESPA (don’t try to google it since it is my own definition) since basic SPA isn’t suitable to the kind of Business Applications I do and it is absolutely not suitable when you want to integrate different (maybe cloud based) applications developed in and running on different platforms in the same Viewport where the Viewport is the main SPA.
In big applications (such as 5250 modernization) clean SPA isn’t suitable it will simply be too complicated and the total application will become a monolith. Here we have to remember that while 5250 has existed for many decades the lifespan of a web application is maximum 5 years or shorter and there is traditional no back-level support when technology change. EXT JS 3.x doesn’t run on EXT JS 5.x and Angular 1.x doesn’t run on upcoming Angular 2.x so the bigger the old code base are the more expensive it is to move. It is more or less like trying to move a WEB 1.0 server centric application to a WEB 2.0 SPA client centric application.
My own framework handles this problem with ESPA. The scope 0 is the Viewport SPA that controls and a number of active IFRAMES that each has their own SPA isolated in the IFRAME but still is able to communicate with each other through the SPA in scope 0. The server still controls the environment since it all runs in the same main session that also is able to communicate between active SPA’s sub-sessions even though the server side is completely stateless.
On Sat, May 23, 2015 at 9:31 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:
Nathan,
Single page apps appeal to me because they shift the web application
from the server to the client. Instead of having a traditional web
application running on the server side (e.g., a .NET web application
running in IIS, a Java web application running in WebSphere, a PHP web
application running in the Zend web server), the web application runs
in the client using JavaScript, a JavaScript framework such as Angular, and the browser.
However, there are times when an SPA might not be the best approach.
Here's a blog article that I thought was helpful in understanding why
someone would not want to use an SPA:
https://blog.svpino.com/2014/10/15/is-a-single-page-application-what-y
ou-really-need
For developing GUI interfaces instead of 5250 green screens, SPAs seem
like a solid approach.
Thanks,
Kelly
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan
Andelin
Sent: Friday, May 22, 2015 3:12 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: [WEB400] Single Page Applications
Probably a poor choice to start a topic that has such far reaching
impact as this, on a Friday afternoon. Maybe we can pick it up on Monday.
This is a natural extension of the discussion this past week about
which server architecture might be best to support single page
applications, or SPA's.
I'll begin by asking, what is a single page application? Popular terms
like SPA tend to get hijacked by anyone interested in promoting a product.
Based on my readings, SPAs are essentially static content (HTML, CSS,
JavaScript), which have UI components which adapt to "data", which may
be downloaded after the static content.
SPAs are said to be "responsive" in that pages are not "refreshed";
just page elements which adapt visually as data is refreshed
asynchronously over the life cycle of the application.
Much of the promotion of SPAs seems to originate from frameworks like
Angular and Bootstrap, which supplement HTML with "declarative elements"
such as <tags> and <tag attributes> which are bound to JavaScript and
CSS libraries.
SPAs have far reaching implications in that traditional server-based
frameworks and tools which are designed to generate HTML, manage
sessions, and provide gateways to data appear to be superfluous; perhaps obsolete.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list To post a message email: WEB400@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list To post a message email: WEB400@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.
--
Regards,
Henrik Rützou
http://powerEXT.com <
http://powerext.com/>
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.
midrange.com
