Difference between revisions of "JSDT/JSDTRenewalArchitecture"

Revision as of 07:49, 9 November 2015

Principals

The new architecture should be based on principals which will allow JSDT to meet the following fundamental requirements:

• Fast (Performance is the key requirement. If we choose between performance and some advanced feature, performance always wins)
• Stable
• Leveraging source solutions elsewhere
• Extendable

The functionality may be limited to the basics: Syntax highlighting, very basic code completion and validation, debugger. The main goal for Eclipse Neon is to provide a platform which meets the requirements above and not to focus on any advanced functionality. JSDT should not prevent users from developing (performance issues, false positive validation problems, etc) and help when possible.

Current Problems

• JavaScript Parser
  • No ECMAScript 2015 support
  • Problems with corner syntax cases on the current specification
  • AST model does not cover ES 2015
  • Inference Engine is built-in
  • Validation is built-in
  • Validation only covers syntax errors found through parser.

• JavaScript Editor
  • JavaScript Code Scanner does not support ES2015

JSDT architecture proposal

• JS compiler (for the file)
  • Parses the file
  • Infers
  • Creates the model of the file and store it in JS model.
• JS model
  • Provides API for clients:
    • Code completion
    • Validation
    • Refactoring
    • Navigation
    • Debugger
    • …
  • Think about the structure of JS model. It could be a set (or tree?) of individual components/models each of them representing a *.js file or a lib. It should has a predefined contexts/libs (browser, etc.) + ability to add/remove individual js models to it.
• JS Editor
  • When the editor is opened it triggers JS compiler on the file
  • JS Source Editor configuration provides:
    • Presentation reconciler for highlighting
    • JS Code Assist for code completion
    • Hyper-link navigation
    • Outline
  • As-you-type validation. Transform it to a Structure Source Editor? SSE provides as-you-type validation out of the box but we need to investigate if the current as-you-type validation in SSE has any big issues preventing use it as-it-is for JS files. Anyway we need an as-you-type validation via SSE mechanism or our own validator pluged-in via a dedicated reconciler.
• HTML Editor
  • Should support the main functionality of JS Editor for JS code withing an HTML file.
• Validation
  • Build time validation can be plugged-in via the WST validation extension point.
• Debugger
• ...

Principal changes comparing to the current architecture

• Kill the builder. Compilation (for the file) is triggered when the editor is opened or changed in the editor. It means we won't have an up-to-date model for entire project. We will have fragments. Each fragment represents a *.js file opened in the editor or a predefined lib/context. The main advantage of this approach is performance and scalability. Should work on huge projects as fast as on small ones.
• Rely on third-party parsers/compilers which are being actively driven by the community so we will get the latest standards (ECMA6 etc) supported in the tooling. Plus the ecosystem of extensions (jQuery, Angular, etc).
• Do we need JSDT nature?