Re: Rise of Node -- WEB400

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!

Yes, it was a big blunder, though "everyone in the world's..." is a little
over the top. But it was definitely a big issue.

Concerning RPG being more stable than Typescript/Javascript. You're
correct that they are on opposite ends of the spectrum (RPG should retire
more things and Javascript isn't afraid to break many things). You're
correct, it is a new world for those that have only lived in RPG.

Aaron Bartell
IBM i hosting, starting at $157/month. litmis.com/spaces

On Sat, Mar 17, 2018 at 11:26 AM, Tim Fathers <X700-IX2J@xxxxxxxxxxx> wrote:

"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 di
dn'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.