Hacker News new | past | comments | ask | show | jobs | submit login

Unfortunately, "JS tooling in JS" is a dead end.

Countless people before me have tried, and I myself have written and maintained a (proprietary) JS toolchain that has caused a some trouble with users over the years.

In the end, using a systems language is what I've settled on.

> Further, you double the dependencies

I'm acutely aware of this problem. Which is why if you look at Jam now, it has zero dependencies. Not even libc (which is mostly thanks to Zig).

The only "dependency" is a Unicode property detection library I wrote for Jam itself. And it is currently the fastest implementation for Unicode identifiers to exist. This simply isn't possible in JavaScript.

Same story with the Parser, etc. Parsers for JS already exist, but it's already known how far one can go, stitching together existing tools that aren't meant to work with each other.

Some dependencies can't be avoided in the long run, But I try to be very cautious, and vet every dependency thoroughly before considering it an option.

Ultimately, the dependence on two languages is a tradeoff that I've accepted, and the problem you mentioned with dev environments is one I'm going have to live with.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: