I don't think anyone suggested deprecating HTML. It is just a different approach where the (bulk) of the HTML is generated on the client, rather than generated/delivered by the server.
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: 08 December 2012 17:14
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] 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
--
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
