Re: Single Page Applications

Kelly

with all due respect (being US polite now) Google Gmail was developed in
2004 based on Google GWT
and NOT Angular that first was introduced in 2009.

On Sat, May 23, 2015 at 5:28 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Nathan



No let’s not discuss this or that framework let’s discuss what the
acronym SPA really stands for and that is in my opinion a browser based APP
that you by the way has many of on your smartphone where you run one binary
monolith side by side by others since your device is able to multitask
between applications such as “mobile voice phone”, your mail box APP, your
Twitter APP and your Facebook APP – but also between different browser
based HTML based APP’s where you are able to run an EXT JS based SPA APP
side by side with an Angular based SPA APP.



Your smartphone basically offers you a Viewport to your chosen APP’s
however they are done and what I try to do in my Viewport is doing the same
with a twist as single login and behind the curtains extended integration.

On Sat, May 23, 2015 at 4:42 PM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:

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.

--
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/>

--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>