|
Anyone that's worked with Javascript will tell you it can be an absolutenightmare, apart from the fact Javascript itself it a poor language in
Any project you write will inevitably depend on other libraries, whichoften take a cavalier approach to backwards compatibility and you can end
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.