Scripted is a new browser-based JavaScript code editor which works locally, having the content being served by a Node.js web server. The editor is being developed by VMware based on Eclipse Orion’s editor component. Scripted was created for developers who want to work locally with a simple and lightweight tool instead of a fully blown IDE.
Andy Clement, a staff engineer in the SpringSource division of VMware, has outlined Scripted’s main features:
- Fast startup, lightweight.
- Syntax highlighting for JavaScript, HTML and CSS.
- Errors and warnings:
- JSLint is integrated to provide error/warning markers on JavaScript code.
- AMD and CommonJS module resolution: there is basic resolution where unresolved references will be marked as errors.
- Content assist:
- Basic content assist for HTML, CSS
- For JavaScript, content assist is driven by a type inferencing engine which is aware of AMD/CommonJS module dependencies and also uses JSDoc comments to help it understand the code.
- Hovers: hovering over a JavaScript identifier will bring up the inferred type signature.
- Navigation: press F8 on an identifier (that the inferencer has recognized) and the editor will navigate to the declaration. This also works on module identifiers (e.g. in define() clauses)
- Formatting: JSbeautify is integrated
- Sidepanel: alongside the main editor a side panel can be opened – currently this can be used to host a second editor.
- Key binding to external command: Key bindings in the editor can invoke external commands (less, mvn, etc)
For the near future the team intends to build better code assist and navigation, to provide more panels that could host various content such as documentation, search results, code preview, etc., a simple plug-in system, and debugging with Chrome Development Tools and Node Inspector. They are also considering adding support for similar languages such as CoffeeScript and TypeScript.
InfoQ has interviewed Clement to find out more about Scripted and the team’s plans for it.
InfoQ: Scripted is based on Eclipse Orion. Why a separate project from Orion?
We loved the Orion editor component - it serves as the basis for the client side of Scripted. But Orion is mainly designed for remote hosted workspaces/projects, with an option for local server mode. We found remote projects didn’t appeal to all developers and wanted to design something initially around a local server mode. In this configuration we felt the Orion server was a bit heavyweight and had features we didn't need at the moment, like the multiple user support and git integration. In keeping a client/server structure for Scripted we have the flexibility to move that local server to a remote location as some point in the future.
InfoQ: What are some of the main differences between Scripted and Orion? I noticed at a first glance that yours has a Subeditor and the Navigator is different. Other notable changes?
Orion is an extensible tools platform. We did not necessarily want to be as extensible and instead offer a more opinionated set of components. Scripted is going for the single-page style of app and attempting to offer an experience familiar to developers using tools like vi, textmate or sublime. Where Orion is offering UI for working with systems like Git, Scripted tries to recognize the user will have a set of tools they are already using for some tasks and we don't want them to learn another UI for the same thing. The key feature we have been working on, and which we'll continue to improve, is code comprehension. We are investing time in building libraries that understand JavaScript - we want to offer great content assist and a good navigation experience when working with code. When a developers code uses either the AMD or CommonJS module systems, Scripted understands that. It will provide error markers (in the editor) for module references that cannot be found and use the awareness of the module structure to give you appropriate content assist when accessing one module from another. It also parses any available JSDoc to get a better understanding of parameters and return values.
You mentioned the side panel where we currently host the sub-editor. We plan to do a lot more with that side panel over the next few releases. Think of it as a place where any support material might go for the task you are trying to achieve in the main editor. So initially it is being used for a second editor but there are plans for panes that hold documentation, search results, etc. Ideally we want it to contain not only material that you have asked for but perhaps preemptively show you material that you haven't asked for but which Scripted has determined would be useful. Perhaps there is a pane that follows the cursor position in the main editor and continuously updates to show the code for the destination of any call being made at that cursor position (this is similar to something seen recently in light table). Importantly we want the side panel to contain relevant content - and Scripted will actively try to ensure that.
InfoQ: Orion uses Jetty on the server. Why have you switched to Node.js?
We wanted to go very lightweight on the server side. The Orion server, that uses jetty as you say, felt a little heavier than we needed. Once we made the decision that we did not necessarily need to use the Orion server then all the options were available to us. Something we have often faced with our previous tooling projects is that we would develop the tools but not actively use them ourselves, we would simply hand them off to our users. With Scripted we wanted to change that and actively use it ourselves in day-to-day development. This led us down a natural path of using JavaScript for the server side in addition to the client side. The obvious choice for the backend technology was then Node.js. So far it is working really well for us. Our CommonJS support has basically been developed because we needed it for easier development of our server.
InfoQ: Scripted runs locally which means faster responses from the server, but how does it integrate with a web based repository shared with other developers?
At the moment, it doesn't integrate with web based repositories or 'server side' workspaces if you will. On our roadmap will be to make the server deployable remotely, of course, but it isn't the initial goal of the project. We found that developers did not want to give up their code to a remote workspace at the moment - but that may change in the future.
InfoQ: What plans do you have for Scripted's future?
It is early days. Version 0.2 is the first version we have put out to collect feedback on. Over the next few releases the key focus continues to be around the JavaScript editing experience: continuing to improve code comprehension and offering even better content assist. Hopefully at the same time we can start to add some panes to the side panel like search and documentation. We also want to start looking at integrated testing by providing an easy way to launch tests and review their output, and further out we want to explore debugger integration.
InfoQ: What can you share on VMware's involvement and plans regarding Scripted?
VMware has been actively involved in developer tooling for a while, with both the Spring Tool Suite and Groovy/Grails Tool Suite. VMware created Scripted as an attempt to explore an alternative to the traditional approach of providing plugins for an IDE. We are recognizing that some developers want to use lightweight editors but right now that tends to mean giving up the usual IDE features that greatly improve productivity like content assist and refactoring. Scripted is attempting to prove that doesn't have to be the case. I should also mention the Scripted team is actively working with the Orion team and contributing enhancements back where possible.
Editor’s Note: Scripted is available on GitHub under the Eclipse Public License 1.0.