Re: Single Page Applications -- WEB400

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-you-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.