Re: Truly later thinking...Honey, grab me another beer -- WEB400

How old is PHP? About the same as Net.Data and Java, right? So the immediate response is, oh, they released OO capability in PHP. It's new.

What it is is that PHP was (and for many PHP apps, still is) a security nightmare. The original way of progamming PHP, and much of that vaunted open source code when one tosses out millions of lines of code numbers that is based on it, is now more than deprecated, anyone using it is braindead and deserves what happens to their site, this any PHP advice will tell you.

So fine, it was reworked because it was a security nightmare. And I'm supposed to be impressed because it's "new and improved" and Net.Data just works?

As for all that open source, it's not trivial to copy code from a sizable project and tweak for your own ends for a business. Almost all of the PHP code is simple variations on post and display (BB's, wiki's, etc.) There are a few CRM/ERP's, they're cited often, but to go in and figure out the infrastructure and borrow pieces of it to base something of your own on inscrutable code is about like going into an older RPG ERP and trying it.

Sure, there's lots of examples of code to look at, as far as something specific like how do I like at the environment variables or trying to figure out how do I do something here that I'm familiar with in RPG, but I really don't see the open source providing any leverage for a serious business application.

Nathan has hit it on the head on so many ways here, simpler in this case also leads to better performance as well as faster development, two wins that are hard to get at the same time.

And the keeper is, when is modernization just a codeword for wannabe migration. Using the unique capabilities of the iseries is not in any other platforms's interest, and you won't find it in cross platform technologies.

rd

Nathan Andelin wrote:

From: "Haas, Matt
At this point, I don't know why anyone would want to start new
development in Net.Data.

Let me admit that the lack of traction is a valid concern. But that could change quickly if IBM chose to commercialize it, or help establish an open-source community around it. Like any product, it needs someone promoting and supporting it.

If you just consider Net.Data architecture and features, there's a lot going for it. It runs in the native virtual machine and offers an exceptional interface with native language environments. Contrast that with products that offer a migration path off the platform. A good word-smith may characterize them as IBM i modernization tools, but they're actually migration tools - a good way to kill a platform.

I'm impressed that Net.Data doesn't make a "project" out of Web development. Contrast that with tools where the first thing you do is to make a project, and set up about a dozen different directories for your files. Then in order to create a new file within the project the tool offers about 6 dozen wizards for creating it. Since the tool is based on multi-tier architecture, and offers a migration path off the platform, and implements numerous convoluted "standards", and attempts to mitigate between disparate interfaces, you begin to lose site of the desired result, and begin to focus on the mechanics of implementation. When that's your view of Web development, you begin to believe that you need the wizards and code generators, when what you really need are simpler interfaces.

With Net.Data I'm impressed that you don't need to setup an entire development and runtime environment on your PC. You don't need a personal HTTP server, a personal virtual machine, a personal application server, or 12 different editors integrated into 1 IDE. You don't need a wizard to deploy your application to a server. You don't need to make a "project" out of setting up or upgrading your development environment. You don't need a beefy workstation. You can make incremental changes to macros and immediately see the results. You don't need to redeploy your entire project.

I like the fact that with Net.Data you're dealing directly with HTML, CSS, and JavaScript rather than working with various tag languages that generate server and client-side components that generate HTML, CSS, and JavaScript, but do little to improve the user interface. Instead, they lock you into less flexible interfaces.

Net.Data performance surprised me. In my last message I provided a link to an inquiry screen which I implemented in both Net.Data and RPG, and where client response times were essentially identical for both versions.

Nathan.