On the comparison of adopting Node and Java...
My shop refused to adopt Java on the IBM i because: (1) we were already using .NET, and (2) database drivers and stored procedures were sufficient for the few times we needed to make .NET interact with DB2 and COBOL.
Node is different for our shop for a variety of reasons.
* Using Node would let our .NET developers stop using ADO.NET to interact with the IBM i. Getting rid of dependency on ADO.NET would let them move to .NET Core.
* Node uses one of the de facto standard languages of the Internet: JavaScript. People need to get over bad impressions they may have formed in olden days. JavaScript (actually ECMAScript now) has matured quite a bit as a language. And TypeScript offers enhancements if you want/need them. I am NOT saying JavaScript is the best language ever. I AM saying we already have people in our shop who have coded JavaScript for years.
* Node has proven scalability. It is used by businesses that need to handle very high volumes of concurrent requests as fast as possible while keep CPU *relatively* low. Businesses like Walmart, PayPal, eBay, LinkedIn, Netflix, Dow Jones, and others use Node because it helps them scale well. Our company has reasons for wanting the ability to scale very big, too. I am NOT saying other technologies don't scale (they do). I AM saying a lot of big businesses are choosing Node as a technology to help them scale very big-and Node has proven successful for them. We are leaning towards doing the same.
I don't know if I see Node replacing ILE languages in our shop. I tend to think of Node as a niche technology. Use it when you need to process high volumes of concurrent requests really fast while keeping CPU relatively low. I'm not under the impression that Node/JS was intended to be a general purpose programming platform like .NET or Java or CL/RPG/COBOL/C. I'm not sure why I would use Node for a batch program that runs over a large number of DB2 records to spit out a report. I'll keep an open mind. But someone would have to persuade me.
Thanks,
Kelly Cookson
IT Project Leader
Dot Foods, Inc.
217-773-4486 ext. 12676
www.dotfoods.com<
http://www.dotfoods.com>
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Aaron Bartell
Sent: Saturday, March 17, 2018 8:24 AM
To: Web Enabling the IBM i (AS/400 and iSeries) <web400@xxxxxxxxxxxx>
Subject: [EXTERNAL] Re: [WEB400] Rise of Node
Anyone that's worked with Javascript will tell you it can be an absolute
nightmare, apart from the fact Javascript itself it a poor language in
which to write business logic,
I need to understand context. Are you talking about writing Javascript on
the client or on the server? The server is a different world where you get
to control literally everything (what Javascript version is used, when it
is upgraded, etc).
Any project you write will inevitably depend on other libraries, which
often take a cavalier approach to backwards compatibility and you can end
up in dependency hell.
Is this not something the server-side developer is in full control of?
Picking safe/dependable packages is an important part of being an open
source programmer (Node.js, Ruby, Python, PHP). For the record, and maybe
this is what you are getting at, there have been some missteps in the
Node.js community. Those have since been corrected.
Concerning relating the poor adoption of Java on IBM i to what Node.js will
have; I think that you're going to fail to prove your point. Many are
already willingly and excitedly embracing it.
As with any new technology, it should be embraced with great scrutiny to
make sure it will serve the needs of your organization. I say that because
I appreciate certain aspects of your arguments. But you're not giving
Javascript/Typescript enough credit for the strides that have been made the
past few years.
Aaron Bartell
IBM i hosting, starting at $157/month. litmis.com/spaces<
http://litmis.com/spaces>
On Fri, Mar 16, 2018 at 7:33 PM, Tim Fathers <X700-IX2J@xxxxxxxxxxx<mailto:X700-IX2J@xxxxxxxxxxx>> wrote:
While this is true if you're a software vendor, it might not be true if
you're a service provider. It might be argued that the days of ISVs are
numbered anyway as people move towards cloud computing and software as a
service. This is where I think there could an opportunity for smart
software vendors, who have perfectly serviceable software that no-one will
buy because it's green screen and runs on a "legacy" platform. If they
could re-architect their software as a web application and market it as a
managed, cloud-based solution, for which they charge a fee per seat or
whatever then who cares what the back-end technology is? Does anybody
really care what platform Saleforce runs on? Who knows, given the economies
of scale and the IBM i's famous reliability and low cost of ownership, it
might represent a viable model.
In some respects we've had for years the ability to do "mainstream"
development on the IBM i using Java, but relatively few people do and I
don't see Node changing that. I'd go so far as to say that doing
"mainstream" development on IBM i is pretty pointless anyway, as is using
it as a simple DB2 server, as neither to me leverage some of the key
strengths of the platform. While RPG might be considered old fashioned it's
proven an extremely stable environment to create robust business
applications and there's a lot to be said for software that just works, and
keeps on working. Anyone that's worked with Javascript will tell you it can
be an absolute nightmare, apart from the fact Javascript itself it a poor
language in which to write business logic, the entire ecosystem around is
considerably less stable than anything we have been used to in the past.
Any project you write will inevitably depend on other libraries, which
often take a cavalier approach to backwards compatibility and you can end
up in dependency hell. For the front-end this is manageable and the
benefits clearly outweigh the drawbacks, I'm not at all convinced the same
can be said of redeveloping the back-end in Javascript or even Typescript.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx<mailto:WEB400@xxxxxxxxxxxx>
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/web400<
https://lists.midrange.com/mailman/listinfo/web400>
or email: WEB400-request@xxxxxxxxxxxx<mailto:WEB400-request@xxxxxxxxxxxx>
Before posting, please take a moment to review the archives
at
https://archive.midrange.com/web400<
https://archive.midrange.com/web400>.
midrange.com
