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
