"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)."
See my reply to Henrik. It has nothing to do with where the code runs, it's more about the fact that Javascript lacks basic features which I think are required to write robust and reliable server-side code (e.g. type-safety, fixed point decimals). Typescript helps of course and I'm not saying you can't do it, I just don't think at this stage it's the right tool for the job.
"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."
I agree to a certain extent, and I haven't developed any proper server-side code in Node it's true, but I don't see why it should be fundamentally different from the client side, none of my issues are specific to the client. You still make careful decisions about what dependencies you're going to have, and whether they are well enough supported etc. but even if you trust them, how do you check what they depend on? Wasn't that long ago a core library was pulled from NPM and broke almost everyone in the world's builds because it was so heavily depended on! As I mentioned, we've spend probably 3 years working on Angular, now this is a framework from Google, not some fly-by-night outfit of cowboys, and in that time it's gone from version 1 to version 5. Version 1 to 2 was a complete rewrite of the framework, in a completely new language (from JS to TS), of course, we could have stayed on Angular 1 but it would have been stupid as Angular 1 was clearly going to die. Luckily, we didn't have a great deal of code at that time so we rewrote it all for Angular 2 in Typescript. Then came Angular 3, this introduced a new router (a core part of the framework) and they deprecated the old one. Again, we could have stayed on Angular 2 but it would have been pointless, so more rewriting... and so it went on. This is by no means unique to Google or Angular, any Node package with a major point change in its semantic version number can be expected to introduce breaking changes and often you don't have much choice but to upgrade to get bug fixes or features you need.
My point is, that in many cases, upgrading to a new version of one of your primary dependencies can, and very often does, introduce breaking changes, this is something that IBM very rarely did to us, when did a new version of RPG or any of the system APIs introduce a breaking change? Almost never that I can remember. Even the OS updates very rarely have a breaking change. Again, I'm not saying you can't live with it, all I'm saying, is that people moving from something like RPG have to expect that the foundations they build on will shift underneath them a lot more often than they're used to and they will spend time having to patch breaking changes and occasionally have to track down bugs in code that's two or three levels removed from the code they actually write in some dependency of a dependency.
As I've said, I love Typescript and I do think I'm giving it the credit it deserves, it a fab language, but it's absolutely true also that Javascript/Typscript frameworks upon which you inevitably depend *will* change and *will* break your code much more often than people are perhaps used to.
________________________________
From: WEB400 <web400-bounces@xxxxxxxxxxxx> on behalf of Aaron Bartell <aaronbartell@xxxxxxxxx>
Sent: 17 March 2018 14:23
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: 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
On Fri, Mar 16, 2018 at 7:33 PM, Tim Fathers <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
To subscribe, unsubscribe, or change list options,
visit:
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fweb400&data=02%7C01%7C%7C6722db1953cc45d5bb4b08d58c0a597d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636568898427872123&sdata=J3GARwlM8iFGp2Ucg2sLcGCqYQrmlwobSXpY8oI1mUA%3D&reserved=0
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%7C6722db1953cc45d5bb4b08d58c0a597d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636568898427872123&sdata=RWxwyZJ7a5ryUcAH3AyoFWv%2FYmO4qezguRSrnL%2ByZe0%3D&reserved=0.
midrange.com
