|
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,and the browser.
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,
Monday.
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-wha
t-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
product.
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
perhaps obsolete.
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;
--
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/>
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
