Add JavaScript support (node.js).

[treeform]

JavaScript is very popular and is similar to python. There is node.js and Deno. Node.js is way more popular abut Deno is new an exciting. It does not look like Deno has its FFI flushed out yet.

[lantos1618]

Recently I have been trying to write/find a solution to tie a backend (typescript, TS) and frontend (TS) together. I've found a decent stack to achieve this, (ts, express, trpc, svelte/vuejs/react). This is all to provide types from the backend to the consumer.

However I have been tainted by nim, every time I write something on this TS backend I think in nim and then can't help but wonder if the thing I am doing would just be easier in nim.

Watching this +1

Are there plans to support TS definitions?

just as a side note (and to check my thinking)

1. why generate TS defs? so I can use them in my TS FE/consumer
2. why have TS defs in the FE? so avoid api errors between BE api from the FE written in TS 2.1 why is the FE written in TS? to leverage TS frameworks and packages and to make dev onboarding (TS) easier
3. why are there api errors? because the frontend has no understanding of the backend
4. why is there no understanding between the FE/BE? because they are separated by network (HTTP/WS)
5. why are they separated? So I can have protected business logic and provide the customer with a decent user experience when they visit my website/app 5.1 why are you protecting business logic? to take economic rents -> end
6. why does user experience degrade doing this? This is how http was set up and the nature of request and response -> requests are not known ahead of time. 6.1 why was http setup this way? developed this way over time -> end 6.2 why are req/res not known ahead of time? data can be changed from initial response and the number of combinations is not computable and can not easily be bound -> end

first thoughts from that

• use an API schema language on top of the BE instead of generating target language
  • swagger/openAPI - is good but the implementation is huge and most backend swagger/openAPI require a load of markup
  • Graphql - Doesn't support maps structures, also is actually is kind of used to solve a different problem set it in be/fe communication.
  • rpc/grpc - I don't think this one maps from language X to language Y?
  • openrpc - idk need to findout
• nim compiles to JS, use that that to generate api-> the FE world is moving to TS because it provides more safety over JS and you can not call (without mapping) JS from TS but you can call TS from JS (using generators)
• Use karax or some other nim FE client -> I could use them but other API consumers might not be in nim

I appreciate that this is genny is a dynamically linked generator and what I've described is over rest but I don't think it is too off. Generate TS bindings -> pass bindings through a query wrapper.

If TS is a supported target by nim it might open up a huge audience for BE dev. Untyped languages are not great in the backend and AFAICS (opinion) other languages go/rust don't have a truely elegant solution to target the frontend

ps - some of this is probably wrong, I'm just airing thoughts also to go back to, thanks if you actually read this

[treeform]

Generating TypeScript bindings is not a bad idea if some one wants to do it. But only server side.

Generating rest APIs, anything that goes over HTTP or network is not were we want to take genny.

If you need an API generator (which could be really cool) you can make your own library or fork genny.