Add jsxmlhttprequest

[juancarlospaco]

I wrote this designed to be used along with stdlib,
now that Fusion wont ship anymore, lets move it to stdlib,
may be needed for the httpclient for js anyway.
Already tested, reviewed and approved on Fusion.
Changed all mentions of "Fusion" to "Nim" but code is untouched.

[Araq]

I think Fusion is the better place for these modules. The current plan is that we don't bundle Fusion anymore with Nim, but move atomic refcounting and tree tables into std. And not much else.

[juancarlospaco]

@Araq I need jsxmlhttprequest for the "httpclient for the browser" that should be built on top.

Will Pattern Matching be removed?, thats very sad, most programming languages are adding Pattern Matching :(

[Araq]

Pattern matching stays in Fusion until we have "let as expressions" and can do it properly.

[juancarlospaco]

@Araq What about jsxmlhttprequest ?, is part of the same effort of #12531 (comment)
We need the low level module to make an httpclient-like module on top.

[dom96]

I think a good place for these modules is a separate Nimble package. You can easily make a jshttpclient package that includes all of this and allows code that builds on nim c and nim js via:

when defined(js):
  import jshttpclient
else:
  import httpclient

This doesn't need to start out its life in the stdlib.

[juancarlospaco]

This was requested to be on stdlib on the PR of #12531 🤷

Whats the problem with the JS modules ?,
already proven they are not costly to maintain, JS modules not gonna give you a memory leak.
I just want JS target to be a better supported and work properly not incomplete functionalities everywhere.

[dom96]

The problem is exactly this, the load on us to review your changes and the effort on you to be blocked by us. If you put them into a Nimble package then you can move fast.

I'll put this question back to you, what's wrong with putting this in as a Nimble package first?

[juancarlospaco]

Already done that, several times, people do not use a lot of dependencies for something just works on other languages.

• add euclDiv and euclMod to math #16414 (comment)
• https://github.com/juancarlospaco/nim-euclidean

BigInt was the same, most languages are adding bigint, or int128 at least.
Now theres a BigInt, we need someone to step up to make the C target one.

Decimal the same, at the point it is now requested to be added.

Theres more, but you get the idea... is the same thing of "how to add stuff to stdlib" again.

Fusion was proposed by core devs, under the idea that it will be shipped along with stdlib, but failed too.

In the past people created folders, like /experimentals/, /deprecated/ in the repo, etc, but failed too.

I already proposed a "layered stdlib" so this "layer" is NOT supported by core devs ever,
that works just like {.since.} but for a whole folder of modules, but was rejected too.

@dom96
Thinking of something constructive and balanced, for everyone including core devs,
maybe reconsider the idea of layered stdlib now that Fusion is dead, 2 tiers, 1 tier supported by community ?,
/contrib/ folder of community-maintained modules is seen on other open source projects:

• If a module breaks or has any breaking problem is removed on next release if no one from community fix it.
• Core modules and compiler can not import nor depend on contrib modules.
• Contrib modules can import and depend on other contrib modules.
• Contrib modules can not duplicate naming from core modules.
• Core devs can upgrade a contrib module to a core module at any time if they want.
• Core devs can downgrade a core module to a contrib module at any time if they want.
• Contrib modules do not have Deprecation process, just removed on next release if they are not fixed.
• New repo label to mark "contrib" PR and issues.
• You can start with JS modules only (because is easy), after a year if it works, allow any target ?.

Fusion already crash-landed and we are still here...
:)

[nc-x]

I don't understand the objection with things that just work.

This has happened too many times now, a PR is created, reviewed, fixed, and then closed by saying to create an external package, some other times it actually gets merged. So, now everybody is confused about the status of js backend, nodejs, and how stdlib is actually supposed to be progressing ahead.

I think the core team needs to decide and clarify this for everybody's benefit.

[timotheecour]

@juancarlospaco maybe reopen this PR, we just need to address all reasonable concerns before moving forward; sometimes it takes a bit of time but doesn't mean it can't be eventually merged. eg, std/jsbigints took some time but in the end this is a good addition.

replying to #16875 (review)

I think a good place for these modules is a separate Nimble package. You can easily make a jshttpclient package that includes all of this and allows code that builds on nim c and nim js via:
when defined(js): import jshttpclient else: import httpclient

the problem with this reasoning is this doesn't help a bit with existing or third party code that calls import httpclient, so you end up with having to duplicate API's / re-invent the wheel even though code might have been writable in a portable way (working across backends) in the first place.

For very similar reasons, a std/os_js or std/os_nodejs (or likewise in fusion or nimble) instead of supporting std/os in js or nodejs backends would be a bad idea as it would create software silos, making code that calls import os unusable on js or nodejs backends.

refs #15826 (comment)

software not written with nodejs in mind should ideally work for nodejs, without requiring patching code

[Araq]

@juancarlospaco Your "/contrib/" idea is much like the Fusion idea. Fusion is not dead, it's just that we need to decide what Fusion is about and whether to bundle it with Nim or not.

[Araq]

the problem with this reasoning is this doesn't help a bit with existing or third party code that calls import httpclient, so you end up with having to duplicate API's / re-invent the wheel even though code might have been writable in a portable way (working across backends) in the first place.

The chances that something works on node.js when it never was tested this way are close to zero. These code silos remain to be much better than burdening the Nim users who care about the native target with node.js. Likewise if a module was written for node.js it's annoying having to support "nim c" just because somebody might need it. That's effectively what-if development, costly for everybody. YAGNI is a much better principle.

This is not an argument against portability in general, it's just that node.js it's a very special platform, not comparable to Windows vs Posix development.

[juancarlospaco]

The problem is exactly this, the load on us to review your changes

Ok, lets imagine this is true and these JS modules are the worst can of worms for a Nim dev,
therefore these links should give you a huge list of bugs:

• https://github.com/nim-lang/Nim/issues?q=is%3Aissue+is%3Aopen+jsre
• https://github.com/nim-lang/Nim/issues?q=is%3Aissue+is%3Aopen+jsbigints

And these links should give you an empty list:

• https://github.com/nim-lang/Nim/issues?q=is%3Aissue+is%3Aopen+async
• https://github.com/nim-lang/Nim/issues?q=is%3Aissue+is%3Aopen+leak

🤷

[Araq]

Ok, lets imagine this is true and these JS modules are the worst can of worms for a Nim dev,

You're right, they are not and I don't mind reviewing stdlib additions. However, I prefer the layered approach that you yourself argued for. It's just that I think two layers are enough. The "standard library" should consist of a solid core (providing containers, basic IO etc), ideally documented much like C++'s ideas of a standard library that is part of the specification and implementable by independent vendors and then there should be addons and the kitchen sink, but this belongs to Fusion. Much like C++'s boost libraries that eventually end up in the C++ standard. Or not, not everything has to be "standard".

[juancarlospaco]

@Araq
Choosenim already asks relevant decisions to the user on the terminal on install,
outsource the decision to the user, let the user choose, add 1 question on install:
" Do you want to install community-maintained community-supported stdlib modules? ".

[Araq]

@juancarlospaco Ok, yes, let's do it this way.

[Araq]

@juancarlospaco So can we please get these new js modules for Fusion?