Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

comparison to l9t and usage of denojs #362

Open
geekflyer opened this issue Jul 8, 2020 · 1 comment
Open

comparison to l9t and usage of denojs #362

geekflyer opened this issue Jul 8, 2020 · 1 comment

Comments

@geekflyer
Copy link

Heyho, one of the things that held me back from using jk was the lack of typescript support and then over time I thought about using deno (which supports) TypeScript out of the box in a jk-like fashion.
Turn out at least someone has already thought in this direction: https://github.com/nvbn/l9t.

I was wondering what your thoughts are on basing off jk off deno or make it more deno-like.
In particular the way how packages managed (no need for package.json) and that TS is supported out of the box makes its ergonomics a bit nicer.

@squaremo
Copy link
Member

Yeah, deno is an accomplished project, and supporting TypeScript in jk is quite a big job. I was thinking recently about whether the jk library and commands could be ported to use the deno runtime. One advantage lost is that it was quite easy to add e.g., OpenAPI schema validation to jk because it's just an RPC to call into Go code -- this could be harder with deno, both finding an appropriate library in either Rust or JavaScript, and calling it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants