Scripted: A JavaScript editor from VMware(github.com)
github.com
Scripted: A JavaScript editor from VMware
https://github.com/scripted-editor/scripted
7 comments
bonus points for using Esprima to parse
Absolutely. Esprima is one of the better things to happen to the JavaScript world.
The lack of a good, fast, reusable JavaScript parser has been an annoying deficit that is finally being adequately addressed.
There's been a bunch of JS parsers over the years (many PEG-based), but my project (at least) has brought all of them to their knees. Very, very frustrating to get OOM errors trying to parse large JavaScript frameworks and perform code transformations.
Absolutely. Esprima is one of the better things to happen to the JavaScript world.
The lack of a good, fast, reusable JavaScript parser has been an annoying deficit that is finally being adequately addressed.
There's been a bunch of JS parsers over the years (many PEG-based), but my project (at least) has brought all of them to their knees. Very, very frustrating to get OOM errors trying to parse large JavaScript frameworks and perform code transformations.
It isn't quite pure Esprima, we (Scripted) are using my (unfinished!) fork of Esprima that has some recovery features. That way we can get a decent AST out even when there are errors, it is setup here for playing around with: http://aclement.github.com/esprima/demo/parse.html
This is indeed very cool, but i'd love to hear VMWare explain why they created this. Does anyone know? Hopefully one of the members of the team can pipe in and share with us some of the decisions that led to making this.
Hi. I'm one of the Scripted guys, let me chip in on that.
The team working on Scripted are also the guys creating language/framework tooling on the bigger IDE platforms - so writing Eclipse plugins. The real developers using those tools are starting to write more JavaScript whilst at the same time there is the new wave of developers coming straight into JavaScript who aren't great fans of IDEs - usually from the point of view that they are a bit 'heavy' for what they are trying to achieve. We even surveyed some teams about what they were using for JavaScript and that confirmed this tendency towards more lightweight editors.
We could have just done our usual thing and crank out more eclipse plugins but we wanted to investigate something more radical. I, myself, still use vi when I'm on the command line because it is so easy and just works. We wanted to create something with that convenience and speed but that had the key capabilities that can really help productivity - so early error indication through things like JSLint as well as good content assist and fast navigation.
We are also aware of the increasing buzz around Cloud IDEs and wanted to explore that too. We tried some prototype full Cloud IDE setups (so server side workspace with browser interface) but didn't get much traction. This approach of desktop client/server app with potentially movable server let's us start where we think users want us and grow to server side workspace setups later. I know this setup is working for me as we are using Scripted to develop Scripted.
If you haven't seen it, there is a bit more detail in my blog article: http://blog.springsource.org/2012/10/11/scripted-a-javascrip...
The team working on Scripted are also the guys creating language/framework tooling on the bigger IDE platforms - so writing Eclipse plugins. The real developers using those tools are starting to write more JavaScript whilst at the same time there is the new wave of developers coming straight into JavaScript who aren't great fans of IDEs - usually from the point of view that they are a bit 'heavy' for what they are trying to achieve. We even surveyed some teams about what they were using for JavaScript and that confirmed this tendency towards more lightweight editors.
We could have just done our usual thing and crank out more eclipse plugins but we wanted to investigate something more radical. I, myself, still use vi when I'm on the command line because it is so easy and just works. We wanted to create something with that convenience and speed but that had the key capabilities that can really help productivity - so early error indication through things like JSLint as well as good content assist and fast navigation.
We are also aware of the increasing buzz around Cloud IDEs and wanted to explore that too. We tried some prototype full Cloud IDE setups (so server side workspace with browser interface) but didn't get much traction. This approach of desktop client/server app with potentially movable server let's us start where we think users want us and grow to server side workspace setups later. I know this setup is working for me as we are using Scripted to develop Scripted.
If you haven't seen it, there is a bit more detail in my blog article: http://blog.springsource.org/2012/10/11/scripted-a-javascrip...
Agreed, although there are a few examples of VMware employees creating internal tools that end up open sourced - Review Board is an excellent example (basically all the management tools in the ESXi environment, including the console UI, are written in Python/swig - they have sharp coders in many languages).
Maybe this falls into that category - vCenter Orchestrator workflows are all written in JavaScript (or at least,they used to be).
EDIT - Apparently this is based on Eclipse Orion, so unlikely it's something used in the way I postulated.
Maybe this falls into that category - vCenter Orchestrator workflows are all written in JavaScript (or at least,they used to be).
EDIT - Apparently this is based on Eclipse Orion, so unlikely it's something used in the way I postulated.
VMWare did acquire SpringSource. Even though they mainly focus on Java and the Enterprise they might have had some other development tools they had dabbled with. Perhaps there are some hints in the source of where the code came from.
They've got a LOT of teams. A large number of SpringSource developers are in North Sydney, Australia. So far as I'm aware, the Spring team probably aren't working on this.
How does it stack against brackets? https://github.com/adobe/brackets
Brackets also targets web development and is extendable with html and javascript.
Brackets also targets web development and is extendable with html and javascript.
In some respects similar to Brackets as it is a desktop app exploiting web technologies (JS front end) - and like Brackets we are sitting somewhere between 'basic editors' and a full blown IDE . However, there are some key differences in terms of tech and where we are heading.
From a tech point of view we are full JS end to end (server being a Node app). In terms of the features of the software itself, Brackets with quick-edits is going in a slightly different direction to us as we are making much more investment in understanding the source structure, with our recoverable JS parser and AMD/CommonJS awareness. We're focusing on smarter inferencing and better content assist for JavaScript - mainly because those are the real pain points we are having as programmers working with the language.
Scripted doesn't yet have the deployment story but obviously we are interested in that space and also some nice integrated debugging - but we don't want to unnecessarily duplicate the excellent Chrome Dev Tools.
From a tech point of view we are full JS end to end (server being a Node app). In terms of the features of the software itself, Brackets with quick-edits is going in a slightly different direction to us as we are making much more investment in understanding the source structure, with our recoverable JS parser and AMD/CommonJS awareness. We're focusing on smarter inferencing and better content assist for JavaScript - mainly because those are the real pain points we are having as programmers working with the language.
Scripted doesn't yet have the deployment story but obviously we are interested in that space and also some nice integrated debugging - but we don't want to unnecessarily duplicate the excellent Chrome Dev Tools.
Similarly, how does this stack up against good 'ol vim? I always get excited when I see a new editor project, but it ends up being nigh impossible to give up the comfort of my vimrc...
Does Vim (or any of its plugins) support Javascript autocomplete based on type inference?
I'm sure Scripted (or Brackets) can't match Vim general text editing, but if the type inference / CommonJS integration is good - it is certainly an advantage.
I'm sure Scripted (or Brackets) can't match Vim general text editing, but if the type inference / CommonJS integration is good - it is certainly an advantage.
Nothing compares to vim.
Brackets seemed like a viable editor to compare it to since it seems to target the same developer niche.
Brackets seemed like a viable editor to compare it to since it seems to target the same developer niche.
Also, what about the popular Cloud9 editor and Nide? http://coreh.github.com/nide/
I've actually been working on something similar in attempt to teach myself AngularJS. I just wired up CodeMirror to a file system tree provided to the browser using Node just as Scripted does.
http://i.imgur.com/HuAZi.png
http://i.imgur.com/HuAZi.png
I've never liked the idea of web based IDE's. Maybe in a few years the technology stack will be ready for it, but I feel like whenever somebody tries this the solution always ends up feeling really rough around the edges.
I'm fully invested in Sublime Text 2. Works on Mac / Linux / Win (I use all three regularly). I write code in a lot of different languages -- it has plugins for 95% of everything I need to do. The universal applicability of ST2 makes it worth investing in (learning all the keyboard shortcuts, etc).
I haven't tried Scripted, but I'm happy with ST2, and the reasons they give for building it vs. using something like ST2 don't jump out at me.
I haven't tried Scripted, but I'm happy with ST2, and the reasons they give for building it vs. using something like ST2 don't jump out at me.
:%s/Sublime Text2|ST2/Vim/g and you have me but I'm always curious and right in the target so I'll give it a try.
Interesting license for contributing back. You have to sign an agreement? Why?!?
The FSF also requires signing paperwork and assigning copyright for GNU code contributions.
Why? So they don't have to worry (as much) about copyright infringement and patent bombs. VMWare could also sell or commercialize it (and the FSF has legal standing to sue for violations).
Why? So they don't have to worry (as much) about copyright infringement and patent bombs. VMWare could also sell or commercialize it (and the FSF has legal standing to sue for violations).
This is common. Otherwise you get a mess of copyrighted code, and making it effectively impossible to determine who owns the copyright to what. Good luck if you ever want to change the license or give one person a special license.
You can use Project Harmony (http://harmonyagreements.org/) to generate one of these agreements for your own project. It's targeted at FOSS, and the licenses themselves are under CC-AT-3.0.
You can use Project Harmony (http://harmonyagreements.org/) to generate one of these agreements for your own project. It's targeted at FOSS, and the licenses themselves are under CC-AT-3.0.
It's quite common when companies open-source stuff. Google does this too.
You give up all rights to your code after you contribute it. AFAIK if you give up all rights to your code, they could potentially change the project license without asking the copyright holders. IANAL.
That's basically correct, though I would hasten to point out that of course they can't change the license of any versions of the software that have already been released.
One of the things I like about Scripted is how it shows jslint warnings and errors right alongside the corresponding line.
I also like the promise of writing plugins in JavaScript instead of Python, in the case of Sublime.
Bonus points for using Esprima to parse; I'm currently exploring using Harmonizr (which uses Esprima) as a way to start using ES6 syntax.