Skip to content

Typescript.java without JSDT at all #125

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

Closed
PhaserEditor2D opened this issue Dec 17, 2016 · 4 comments
Closed

Typescript.java without JSDT at all #125

PhaserEditor2D opened this issue Dec 17, 2016 · 4 comments

Comments

@PhaserEditor2D
Copy link

I am playing with version 1.1.0 and I see there is the option to use the Salsa inference engine for projects with no JSDT nature. That's great, JSDT is taking a lot of time to get a better type inference engine so to delegate it to the typescript language service is a great alternative (I think, even better than ternjs).

Is this a goal of this project? To be fully independent from JSDT? I see 1.2.0 introduced textmate, so no need of JSDT for coloring, but I guess there more stuff like outline, refactorings, etc...

If to remove all dependencies on JSDT (or make it optional) is a goal or is aceptable for this project I would like to focus my collaboration on it, on add the missing parts.

Well, maybe JSDT will be needed for HTML files. JSDT does a good job with HTML. But maybe the language service and textmate can replace it too. But I guess for now JSDT is fine.

@angelozerr
Copy link
Owner

I am playing with version 1.1.0 and I see there is the option to use the Salsa inference engine for projects with no JSDT nature.

Indeed, the idea is that to extend JSDT completion with Salsa.

That's great, JSDT is taking a lot of time to get a better type inference engine so to delegate it to the typescript language service is a great alternative (I think, even better than ternjs).

The time which is taken to create the JSDT DOM AST will be the same because JSDT create an AST as soon as you open the JSDT editor. Neon is very slow because it uses Nashorm+Esprima. JSDT should be improved by using Google Closure I think.

Is this a goal of this project? To be fully independent from JSDT?

No it was not this goal. I wanted just extend JSDT completion with Salsa.

I see 1.2.0 introduced textmate, so no need of JSDT for coloring

Indeed, but it's for the moment experimental. Its not perfect and using textmate requires more memory and it is less performant than classic Eclipse ITokenScanner.

, but I guess there more stuff like outline, refactorings, etc...

refactoring is not well implemented. There are dependencies to JSDT to support bracket, etc. Having a TypeScript editor without JSDT dependencies is possible but a lot of work. I think the best editor should be to use GenericEditor + Language Server once TypeScript wil provide a Language Server protocol. More Eclipse language server should provide the capability to support custom command (needed for compileOnSave for instance)

In other words, we must wait for several months I think before having those features. I prefer developping features like "compileOnSave", Angular2 template completion, etc than having an editor which is not dependent to JSDT.

But I try to provide step by step some components like textmate to remove JSDT perhaps in the future.

@PhaserEditor2D
Copy link
Author

The time which is taken to create the JSDT DOM AST will be the same because JSDT create an AST as soon as you open the JSDT editor...

I mean they are not going fast with the implementation of the new features. It is what I feel. They will take a lot of time to implement something that works let's say at the level tern.java is working. I think for them is harder because they want to keep it compatible, there are many products attached to JSDT so it is not an easy task to do breaking changes.

Yes I think the GenericEditor + Lang Server should be the recommended general solution for any language in Eclipse. If JSDT goes with it, much better.

Anyway, I will continue exploring this project to include it in Phaser Editor.

@angelozerr
Copy link
Owner

Anyway, I will continue exploring this project to include it in Phaser Editor.

If I understand, Phaser Editor doesn't use JSDT, is that? So you wish to have a TypeScriptEditor which is not linked to JSDT. If you wish that, we could create a new plugin which is not linked to JSDT that you could integrate in your Phaser project and once we will have the same feature than this TypeScritp Editor linked to JSDT, we could remove the current TypeScript Editor. What do you think about that?

Pay attention, I would like to break the TypeScriptServiceClient API by using Java8 CompletableFuture #63 and remove collector API.

Pay attention,

@PhaserEditor2D
Copy link
Author

Phaser Editor uses JSDT for JavaScript development. Well, a JSDT with minor modifications to improve certain parts of the type inference engine. JSDT is great in many aspects but the type inference is not at the level of many other projects. So I really need to improve it. I considered tern.java but at the end I preferred to keep using JSDT as it is the Eclipse standard.

But in the case of TS, there is not an official implementation so this is a great opportunity to add your work to support TS but, since TS and JS have lot in common, the TS solution could be used also as a JS solution. For that reason I was asking for a JSDT removal, because at the end we can have support JS with the TS tooling, as it seems that VSCode does. For me it is fine to use all the VSCode backend in Phaser Editor.

I am not sure if after read your thoughts it will be good to create a complete new editor without JSDT. Right now Phaser Editor is using JSDT so if you are using JSDT in TS we can keep doing like that.

What's the disadvantage of use the JSDT editor with TS? If there is not real drawbacks in face to the users then I guess it is better to keep using JSDT and improve all related to the TS-Language Server implementation.

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