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

plans, roadmap #427

Open
paulvi opened this issue Jun 28, 2016 · 4 comments
Open

plans, roadmap #427

paulvi opened this issue Jun 28, 2016 · 4 comments

Comments

@paulvi
Copy link
Contributor

paulvi commented Jun 28, 2016

With Eclipse Neon JavaScript Editor come with full EcmaScript 2015 (ES6) support. (Internally uses esprima, but not ternjs parser).

http://nodeclipse.org/history

I have not tried yet fully, but I wonder what should be recommended for end users.
Can tern go well together with JSDT (that uses esprima)?

Please give also what has happen within Eclipse, as I saw you were active there. I think that should be visible. Not just anonymous"Eclipse community" .

@angelozerr
Copy link
Owner

@paulvi it's a very good question.

At first tern.java can work with Eclipse Neon. JSDT 2 provides now support for ES6, right but it doesn't provide advanced feature for completion, hyperlink for a given framework like angularjs, requirejs. So tern.java is again interesting even with Eclipse Neon.

The big problem today is that there are double parsing:

  • JSDT parse JS content with Esprima to create an ICompilationUnit
  • tern.java parse JS content with acorn to provide advanced inference although it doesn't need the ICompilationUnit.

I think more and more that editor should never parsed JS and delegates the parse of a server (like ternjs server or tsserver for TypeScript). I have tried to explain my idea at https://jaxenter.com/typescript-compiler-for-eclipse-126463.html

So today I work a lot for:

where I have implemented my idea. TypeScript IDE is based on JSDT for syntax coloration, etc but doesn't use JSDT Editor to avoid parsing content of the editor (avoid double parsing). That's why my TypeScript editor is very fast.

It consumes tsserver (it's like ternjs server) to provide completion, hyperlink, outline, etc.

More TypeScript provides now the capability to parse JS file (called Salsa) and provides inference engine for JS only (typescript.java provides an editor "JavaScript (Salsa)" for that, but you can consume too tsserver with JSDT Editor (you will have double parsing in this case).

More TypeScript can support JSX too.

I'm very happy because RedHat guys like @mickaelistria is implementing this idea with "Language Server" which is a specification to communicate with a server provided by VSCode to support any language. The idea is that Eclipse IDE, Eclipse Che and VSCode could share the same Language and benefit with completion, hyperlink, etc for any language like C, TypeScript, JavaScript, etc

It follows the same idea than typescript.java which consumes tsserver where tsserver is consumed by VSCode, Sublime, Visual Studio, etc. The only difference is that it's for any language. See https://code.visualstudio.com/blogs/2016/06/27/common-language-protocol

Once this language server will be implemented inside Eclipse, I will try to move to this language for TypeScript IDE.

I will continue to maintain tern.java but I'm not sure that I will add missing features like refactoring, because:

  • JSDT is not enough extensible for that.
  • JSDT plan is to swith to language server (perhaps tern.java could to swith too to langauge server)
  • ternjs is not very active compared to TypeScript and it misses some features like multiple signatures Support for multiple signature (find a sponsor?) ternjs/tern#713 that TypeScript support it.

TypeScript is now used inside VSCode and Visual Studio for TypeScript, JSX and JS, and TypeScript is very active. The only miss compare to ternjs is that it is not extensible today to provide advanced features like find Angular2 component, provide completion for Angular2 model inside HTML, but Microsoft guys are working on this issue microsoft/TypeScript#6508

You can see the amazing demo in this issue with Angular2. Once this issue will be fixed, typescript.java could benefit with this feature!

@mickaelistria
Copy link
Contributor

Tern.java is still relevant with the new JSDT. Tern.java adds to JSDT some features that aren't yet implemented. The recommendation is IMO to have end-users using latest JSDT + Tern.java.

JSDT has started CQs at Eclipse.org to be allowed to ship tsserver. Once tsserver is in, I believe it will be used to implement many features provided by tern.java (+ addition for typescript). I believe once JSDT starts relying on tsserver, then the tern.java project is likely to become not useful anymore. But there are still months before this becomes available.

Any help to contribute tsserver in JSDT once CQ is approved would be more than welcome. Please join the wtp-dev mailing-list and/or JSDT meetings ( https://wiki.eclipse.org/JSDT/Confcalls ) if you're interested in participating to this effort in JSDT.

@angelozerr
Copy link
Owner

Any help to contribute tsserver in JSDT once CQ is approved would be more than welcome.

@mickaelistria you mean that you could be interested to move typescript.java to JSDT? If it that, yes I'm really interested!

Please join the wtp-dev mailing-list and/or JSDT meetings ( https://wiki.eclipse.org/JSDT/Confcalls ) if you're interested in participating to this effort in JSDT.

I will try it, yes sure.

@mickaelistria
Copy link
Contributor

mickaelistria commented Jun 28, 2016

you mean that you could be interested to move typescript.java to JSDT? If it that, yes I'm really interested!

Concretely, either you contribute some parts of this integration into JSDT; or it's going to be reimplemented in JSDT. Taking advantage of the existing code would for sure be better. However, I don't think JSDT is ready to take the whole typescript.java project "as it". The best approach is to first wait for JSDT to be allowed to consume tsserver, have some minimal integration between JSDT and tsserver working, and then you could consider migrating some features 1 by 1. Smaller patches are easier to review and integrate that huge chunks of code. Divide and Conquer

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

3 participants