Different levels of abstraction. TeXstudio is akin to an IDE for LaTeX, whereas LyX is more a nice frontend on top of LaTeX. IMO, if you're already experienced and happy with LaTeX there's no reason to switch, but if you don't already know LaTeX or you find the workflow clunky LyX may be a good fit.
I actually have, but it doesn't alleviate my biggest issue with Javascript, which is its async story.
Also I've had experiences with Typescript code compiling with an error then immediately recompiling without any errors. Then errors when I switch to my browser. The immediate recompilation is probably just webpack but it doesn't inspire confidence when errors are non-deterministic.
async/await is still based on promises, and promises are a naive/simplistic answer to the problem.
It works fine for simple cases, but those are cases that were simple to begin with (Ok, maybe they would not be fine with CPS, but async/await is just thin sugar over promises).
To really solve the async problem, you need either Observables or monadic constructs. The former is much more mainstream and mature in the JS world right now. It's not as cute as async/await and you'll be typing more functions, but it really solves the problem altogether.
The problem I experienced with async/await and Typescript was always the lack of built-in support for promises among the libraries I was using. Once I had to use something like promisifyAll() I lost any type information I had about the library in question.
Is there any better workaround to that these days?
This is changing pretty steadily. For example, the AWS SDK has TypeScript types packaged now and a promise interface. Compare this the boto3, the Python SDK, which has had a story open for years(?) to add async support with no official solution.
Node.js's own libraries are a mix of events and callbacks. Some of it can been "promisified", however they have yet to start a real async conversion AFAIK. I've had to wrap some of this stuff to create async interfaces for my own code.
Not really but I also don't see it as that much of a problem. The libraries I use either provide a Promise based interface or I've written my own as a thin veneer atop a callback interface.
Ditto for apply your own types atop the results. Most are already there and only a few edge cases need to be added.
I had a somewhat different experience. Most of the libraries I used lacked types in the library itself. There were types provided by DefinitelyTyped, but they were often incomplete or out of date, and I think a wrong type definition can be worse than none at all.
As far as writing your own types on top of those libraries, how do you ensure any amount of correctness?
