Re: Web Enabling Applications

I wouldn't deprecate HTML yet. Dynamically generated brochure-ware is still needed and growing across the globe. About 25% of the menu items in our Web portal generate reports, which I think in our case are 100% HTML plus CSS (no JavaScript). We're currently getting more requests for new reports than new interactive applications, and we expect that over time the number of reports on our menus could tie or exceed the number of interactive applications.

Speaking of reports, a former close colleague of mine now works for a company that wants to generate customer account statements in PDF format in batches of 25-30K statements per cycle. They developed a process that runs on a Windows server that extracts data from IBM i and produces PDF files. They have not deployed it, however because in testing they estimate that it would require 3 days to generate that many statements.

It makes me wonder where the bottlenecks may be? Under IBM i, and using RPG, we generate student report cards and transcripts at a rate of 3-4 thousand PDF files per minute. I think architecture matters.

I've had one very good experience in teaching RPG to a former PHP developer. I agree with prior comments about looking for people with good browser UI skills and training them in RPG, which under the right circumstances comes easy.

On the other hand, we recently pursued a partnership with another developer who is in the school software market with us. I think he is using a JavaScript framework for the UI. He is using "JSON RPC" to communicate with Python under Apache/Linux, and using Python to communicate with MONGODB (database). So, he's into a full open-source stack from browser to database. I proposed that we merge our databases under IBM i and that we provide an IBM i JSON RPC based web service to support his browser UI. We were flatly snubbed. There would be no moving him off a complete end-to-end open-source stack.

-Nathan





----- Original Message -----
From: Scott Klement <web400@xxxxxxxxxxxxxxxx>
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Cc:
Sent: Saturday, December 8, 2012 12:37 AM
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