Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] JSDT JS parser, internal representation, type inference and all that jazz
:). You guys are hard to follow.

As I mentioned a few months ago, I'm working on an editor for Qt's QML language which is another superset of _javascript_. Ideally, I'm using the same technology, and hopefully just extending JSDT, but for now we're slightly going a different route using tern.js and acorn.js directly (not using tern.java) running on Nashorn. That should at least get us through Neon and we can see where you've ended up and bring things closer together.

The Closure Compiler looks very interesting. As you've mentioned, going across the JNI bridge is expensive no matter what technology you're using. That's why I'm staying on Nashorn and it's performing well enough. It's not the fastest JS VM, but it avoids any JNI hopping. Being pure Java would be ideal but very expensive to build. If we could incorporate an existing project like the Closure Compiler, we'd be miles ahead.

Do note though that the CC don't really have an extensibility framework. There's a big enum to select which language features so if you wanted to add JSX, of if I wanted to add QML, we'd have to contribute it upstream or fork it. That makes it less appealing.

Doug.

On Thu, Apr 7, 2016 at 9:37 AM, Angelo zerr <angelo.zerr@xxxxxxxxx> wrote:
Hi Gorkem,

2016-04-07 15:09 GMT+02:00 Gorkem Ercan <gorkem.ercan@xxxxxxxxx>:

Hi Angelo,
You seem to be concentrated on typescript nowadays.

Yes because I would like to support Angular2 https://github.com/angelozerr/angular2-eclipse based on typescript.java
 
Does that mean you have abandoned tern.java?

No, don't be afraid with that! I will continue to maintain tern.java but here my motivation to work a lot for typescript.java where the integration looks like tern.java:

 * ternjs is not very active today. It misses some features like support for multiple signature for methods. TypeScript is very very active, it supports multiple signature for methods, support JSX and more.
 * I'm limitated with JSDT Editor  to add new features like override outline, generate comments (with type), refactoring. With typescript.java, I have now a custom TypeScript Editor which uses JSDT features for syntax coloration, matching bracket (lightweight editor) and which is very fast when you open a big file (because I don't need AST). More I will able to add refactor, outline, Ctrl+Shift+G by using tsserver without be blocked by JSDT AST and JSDT nature that I don't use it because I don't need Install Path, etc (Ctrl+Shift+G throws an error if your project has not JSDT nature for instance)
 * I would like to support Angular2. See https://github.com/angelozerr/angular2-eclipse which is based on typescript.java
 * TypeScript is improving the inference engine to use it for _javascript_ (called Salsa). Visual Studio has switched to Salsa. typescript.java is able to support too _javascript_ with Salsa. The inference engine is less powerfull than ternjs, but Micosoft guys are working a lot about this feature.
 * tsserver is very fast even with large project with big files. I try to implement typescript.java like VSCode to have the same fast features and it starts working well (compare to existing Eclipse TypeScript): completion, hover, hyperlink, validation are implemented and it is fast even with big project. I have used timeout in order to not freeze Eclipse when tsserver takes time.
 * The main problem with tsserver is that it is not extensible (like ternjs provide with custom plugin) but they are working hard for that. See demo with Angular2 at https://github.com/Microsoft/TypeScript/issues/6508 When it will available, typescript.java could provide that.

I think more and more that tsserver is the very good solution for inference engine and for _javascript_ too (not only TypeScript). My main goal is to provide the same powerful feature than WebStorm and VSCode want to do that too, tsserver is everytime improved  for VSCode and I can benefit with this feature too:)

Hope you will understand my motivation.

Regard's Angelo
—
Gorkem



On 7 Apr 2016, at 3:33, Angelo zerr wrote:

Hi Eugene,

Many thanks for your feedback!

At first please read my post at
http://dev.eclipse.org/mhonarc/lists/wtp-dev/msg09842.html

I have started to implement my idea with TypeScript Editor and it starts
working great, in other words when I edit a big ts file, I have a very fast
performance because I don't use an AST:

 * syntax coloration is done with Eclipse ITokenScanner (I have reused the
JSDT JavaCodeScanner)
 * code folding that I'm implementing is done according tabulation

My conclusion is to create an AST only on background and not when a ts file
is editing like JSDT does today. This AST should be used only for inference
engineckgr (or filll outline on background) and not for features like
syntax coloration, code folding, etc (it's the idea of VSCode which is so
fast).

My TypeScript Editor is a lightweigt editor that it could be used for
_javascript_ too. In my case the build of AST is done on background with
tsserver. Hyperlink, completion, validation, hover call the tsserver
(inference engine) with a timeout and if it takes too time, it doesn't
freeze Eclipse. User has not available result of completion when inference
engine takes too time the first time but eclipse doesn't freeze. When
inference engine has finished to compute AST and other inference jobs,
completion is available. If JSDT could provide a lightweiht editor,
tern.java could be very fast too.

Perhaps I have missed something, but today my TypeScript Editor is very
fast with large file when user open a big ts file.

Regard's Angelo





2016-04-07 9:00 GMT+02:00 Eugene Melekhov <emvv@xxxxxxx>:

Hi all,

I've been working on accommodation of the JSDT core to ES6, new esprima
parser etc. Right now I'm working on restoring
so called "bindings" used for code assistance etc.

I will finish the job that I've started and will implement initial
bindings resolver for single source but... I must admit
that in my opinion what we're doing at the moment is wrong.

* We're trying to reuse old dom model inherited from JDK which is not
fully compliant with JS reality even after
 addition of ES6 specific constructs.

* This model is not very convenient for internal and especially external
use.

* We have to convert this model to fro JSON/other AST formats.

* Integration with JS modules like esprima or Tern or anything alike is
resource consuming, complex, opaque, error prone
 etc.


So, what is the right way in my opinion? The answer is to completely
abandon or internal representation (ASTDom) model,
esprima parser and any other JS based tools like Tern and switch to using
Google closure compiler infrastructure instead.

This approach has the following advantages:

* Closure compiler is fast

* It's written in Java and there are no problem with integration.

* It's a mature project with vast and VERY active community

* It has it's own perfect internal representation (IR) and it's possible
to use just AST(rhino trees) if necessary

https://github.com/google/closure-compiler/tree/master/src/com/google/_javascript_/rhino

* IR has great traversal infrastructure

https://github.com/google/closure-compiler/blob/master/src/com/google/_javascript_/jscomp/NodeTraversal.java

* IR and a pluggable compiler allows to perform all tasks that we need. IR
can be used for for outline
   view, symbol tables for code assist, search, navigation, auto
completion, refactoring and so on.

* It has call graphs, type flow graphs, type inference out of the box.

https://github.com/google/closure-compiler/blob/master/src/com/google/_javascript_/jscomp/TypeInference.java

* It has code validation, lint etc

https://github.com/google/closure-compiler/tree/master/src/com/google/_javascript_/jscomp/lint

* It has code printer

https://github.com/google/closure-compiler/blob/master/test/com/google/_javascript_/jscomp/CodePrinterTest.java

* It's possible to use it's IR to perform any other necessary tasks like
more elaborate type analysis that TAJS does.



In conclusion, I believe JSDT should switch to Google closure compiler
back-end as soon as it possible before it's too
late. It would allow to forget about almost all low-level problems and
concentrate on implementing functionality that is
visible and is really necessary for JSDT users:

* Fast modern editor

* Elaborate code assistance

* Smart navigation

* Smart refactoring

* Integration of v8, node, npm, gulp, babel etc

* Debugging

* JSX support

* and so on, you name it


Thank you.


--
Eugene Melekhov

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev


_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev

Back to the top