"This paradigm has really changed "
I tend to agree with your observations Scott. We are now working on the next generation of our Renaissance Framework and it is highly unlikely that there will be any CGI programs (or programming) in it - and probably no use of CGIDEV2 either. The UI is entirely built on the browser (we are sticking with jQuery, jQuery UI and jQuery Mobile) and requesting data elements from the server as and when required. In our case, we are using websockets for the data transport - I am currently evaluating jWebsocket, Kaazing and Lightstreamer for this purpose. The performance for each on the IBMi seems pretty good using JDK 7. Of course, the business logic will still be RPG for our applications, but the UI generation should eventually be portable to any platform that can run an HTTP server and java. The HTTP server will probably only be used for delivering an initial minimalistic page (to kick things off) and static content like javascipt files, CSS and images.
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: 08 December 2012 07:38
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Web Enabling Applications
Hello,
I hesitate to weigh in on this discussion, as it has all the earmarks of a long and unproductive "holy-war" type of discussion. However, I'm going to be optimistic and hope that doesn't happen, and put in my 2 cents:
If you look at web development 5 years ago, most web apps were HTML that was emitted from server-side programs. Tools like Net.Data were good for that sort of approach (though, Net.Data didn't catch on) Popular tools were perl, PHP, ASP and JSP. Within our community, CGIDEV2 made it easier for RPG to do the same things that PHP, ASP, JSP did in other languages. (Commercial products like RPGsp also did this nicely.) These would all emit HTML, with just some variables inserted from business logic, and that business logic tended to be coded inside the same script along with the HTML.
This paradigm has really changed. As others have said, emitting HTML from the server side is passe in today's world.
Server side programs today perform the business logic, and perform only small pieces of logic at a time (which is to say, they do not generate whole web pages as output.) The output is a simple XML or JSON that's passed to the front-end.
The front-end logic is where almost all of the UI is coded.
I've seen two prevalent approaches to the front-end:
1) An HTML page, with JavaScript to perform certain functions. (The jQuery approach)
2) Very little HTML, with most of the page described in JavaScript (The ExtJS approach.)
In either case, though, the UI logic is coded on the front-end, and the important technologies to understand are JavaScript, CSS, and HTML (though, HTML knowledge is somewhat fading.)
WITH THAT IN MIND...
Since no UI coding is done on the back-end, it seems to me that it doesn't make too much sense to pick a language that makes it easy to code HTML. 5 years ago it was very useful to have technologies that made it easy to incorporate HTML in your programs -- but that's not really needed today. All of the older techs still work -- you just replace the HTML with JSON or XML... But, in a manner of speaking, they are overkill. Since you no longer emit HTML, you spend very little of your UI coding on the server side. You don't really need a language that specializes in embedding web technologies into your server side language...
What's most important on the server-side now is a language that makes it easy to code BUSINESS LOGIC. This is where RPG can really shine, because it's great for business logic.
It may be true that languages like PHP make it easier to build JSON -- but, it's not really all _that_ big of a deal, there are JSON libraries for RPG, or you can code them with regular/normal string manipulation (which really isn't that hard.) Same is true of XML.
The big focus of your work when you sit down to build an application is
really on the writing the business logic itself. I've coded in 20+
programming languages, and I have always found RPG to be the best thing out there for business logic... it's just an elegant environment for business logic!
The other time-consuming part is the UI design... and this is an important piece, but since that logic is all on the front-end these days, it really doesn't matter what the back-end language is, since that's not where you code it!
-SK
On 12/7/2012 4:43 PM, Allen, Todd wrote:
That's great to have this functionality available. Admittedly, there
is more than I was aware of. However, we're talking about RPG
expertise required to handle the server-side component of your web
application. That is where I would be careful about my decision to
use RPG for that part of it. This may sound like blasphemy,
especially since I wrote RPG code many years back, but I think
businesses must keep an eye to the future in these cases.
There are many factors that go into that and every shop is different
so that may make the decision a foregone conclusion. If I am thinking
long term then I am very hesitant to invest heavily in RPG for the web
server-side language. I would never advocate changing the back-end
business logic but there are too many other options out there to go
with CGIDEV2 blindly just because your business logic is written in
RPG. You are limiting your future resource pool by putting all your
server side web scripting in RPG.
--
This is the Web Enabling the AS400 / 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.
NOTICE: The information in this electronic mail transmission is intended by CoralTree Systems Ltd for the use of the named individuals or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone, so that the sender's address records can be corrected.
--------------------------------------------------------------------------------
CoralTree Systems Limited
25 Barnes Wallis Road
Segensworth East, Fareham
PO15 5TT
Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton, UK
SO15 2EA
VAT Registration Number 834 1020 74.
midrange.com
