Tooling for the JavaScript Era
- 1. Tooling for the JavaScript era Andy Clement, Staff Engineer Martin Lippert, Staff Engineer Andrew Eisenberg, Senior Member of Technical Staff © 2012 SpringOne 2GX. All rights reserved. Do not distribute without permission.
- 2. Speaker Introduction • Andy Clement – Staff Engineer, R&D – Lead, language lab • Martin Lippert – Staff Engineer, R&D – Lead, development tools • Andrew Eisenberg – Senior Member of Technical Staff, R&D – Lead, Groovy-Eclipse 2
- 3. Disclaimer • This session may contain product features that are currently under development. • This session/overview of the new technology represents no commitment from SpringSource/VMware to deliver these features in any generally available product. • Features are subject to change, and must not be included in contracts, purchase orders, or sales agreements of any kind. • Technical feasibility and market demand will affect final delivery. • Pricing and packaging for any new technologies or features discussed or presented have not been determined 3
- 4. Agenda • The basic idea • Observations and assumptions • Our prototypes • Where are we heading? 4
- 5. The basic idea • Where are IDE and development tools in general heading towards? – Big integrated desktop IDE? – Lightweight editors? – Browser-based IDEs? – Does Cloud have an impact? • Why can Google search the web in 10ms, but it takes 1000ms or more for my IDE to lookup a type hierarchy 5
- 6. Exploring… • Lets do things differently: – Browser-based – Lightweight instead of fully integrated IDEs – Maybe cloud hosted – Innovate… • And see what comes out of that… 6
- 7. Exploration • Non-coding work: – Talk to people – Ask questions – Scribble • Coding work: – Prototyping – Shipping early 7
- 8. JavaScript • Increasing in popularity • Not only web UI gadgets anymore – Serious large-scale apps in JavaScript – Server-side JS (node.js) • Other dialects interesting: CoffeeScript, TypeScript – JS is first priority • Fits nicely into our scope for browser-based tooling 8
- 9. Results and assumptions #1 • Lightweight beats heavyweight – Simple editors still the most popular JS tool – Don’t want the uber tool • Speed is essential (startup, coding, typing) – No acceptance for long startups, delay in typing 9
- 10. Results and assumptions #2 • Real code comprehension missed a lot – People would love to get good content-assist and code- completion • Aware of module definitions (AMD, RequireJS, …) • Aware of frameworks – Fast/accurate navigation – Early error indication (more than just JSLint) 10
- 11. Results and assumptions #3 • Debugging is great, but good integration with editing is missing – Workarounds exist (for Chrome Dev Tools, for example) – Better integration would be good • Connecting with existing popular tools 11
- 12. Results and assumptions #4 • A cloud-hosted workspace? – Need to work offline – Need to use other tools on my machine on the files • A cloud-hosted tool? – Collaborative editing – Social coding – Zero installation – always up-to-date – Technically using cloud (aka unlimited) resources 12
- 14. Prototyping • Build some basic tools with key features that meet user need • Make them available • Collect feedback, adjust direction as necessary 14
- 15. Prototype #1 • Build: – Editing tool with server side ‘cloud’ workspace • browser based editing experience – Good content assist – Reuse tech where appropriate – No preference on backend technology 15
- 16. Prototype #1: Eclipse Orion “Browser-based open tool integration platform” • Eclipse Project • Client/Server tool • Orion is a tools platform • Not an IDE in a browser tab 16
- 17. Prototype #1: Features • An Eclipse Orion deployed internally in VMware • With extra capabilities: – Better content assist than real orion – Basic command line console included for running some server side commands • e.g. vmc push to Cloud Foundry • What happened? 17
- 18. What happened? • Very little interest – Developers are busy people – The benefits of basic content assist did not outweigh cost of giving up their environment – Developers happier with code on their machine – Even just to ‘try it out’ they had to migrate some code over to the cloud workspace 18
- 19. Prototype #2 • Learn from our own experiences extending Orion – What do we need? • Create a tool that would support local or remote workspace – Continues to be a web app, just with a local server – Can optionally have the server deployed remotely – Keep a low adoption barrier 19
- 20. Prototype #2 • Could use Orion, but: – UI for Orion not quite as snappy/fast as we wanted – Server is a bit heavy – Orion offered more facilities than we wanted • Another Git UI • Multi user setup 20
- 21. Prototype #2 • Reuse Eclipse Orion Code Editor • Implement alternative lightweight backend • Focus on: – Speed (startup and usage) – Code awareness: • Static code analysis • Content assist – Module system comprehension 21
- 22. Scripted Architecture: client side • Eclipse Orion – Just the editor: familiar to Eclipse users • Dojo for now • Inferencing engine relying on – Recoverable JS parsing: esprima – Dependency analysis code 22
- 23. Scripted Architecture: server side • Small Node.js server – Serving the client html/js – Serving requests from the client • ‘give me the contents of file X’ • ‘search for this string’ • ‘tell me the dependencies of this JS file’ • Restarted on each editor launch – Likely to eventually be a long running process 23
- 24. Scripted • Much more positive feedback internally • Decided to open source to access a wider audience • Now on github: https://github.com/scripted-editor/scripted 24
- 25. Scripted: Features • Fast – startup and during use • Code awareness – JSLint early error indication – Module system awareness, transitive dependency analysis – JSDoc comprehension • Basic editor configuration • Basic navigator • Side-panel 25
- 26. Scripted Demo 26
- 27. Scripted – near term goals • Even more code awareness – Even better content assist – More module systems – Maybe always ON content assist… • Plugin model – Extend it with JavaScript 27
- 28. Scripted – near term goals • More side-panel contents – More panes (documentation, search results) – Automated management of panes by the editor • UI overhaul – we’re smarter than we were when we started ! 28
- 29. Scripted – longer term goals • Debugging – Not reinventing CDT – Helping developers in callback hell – Step into server from client • Selected tool integration – But not replacing command line tools, e.g. Git • Even further out – Other languages (Java) 29
- 30. Some images from the drawing board… 30
- 31. Original overlays instead of side panel Discarded • Covering the user code just too irritating 31
- 32. Other side panel entries Will be implementing • Documentation pane • Search results pane • Panes pinnable • More panes to follow 32
- 33. Navigator filters Still exploring • Filters try to ensure navigator content relevant • Tag based filtering with auto-tagging 33
- 34. Scrolling side panel Still exploring • Confusing ‘scroll’ story 34
- 35. ‘Overview’ for side panel entries Unlikely to pursue • Overview doesn’t communicate enough information • Still somewhat fiddly scrolling story 35
- 36. Accordion style side panel Still exploring • How lightweight can the collapsed entries be? • Easier scroll story 36
- 37. Smart global search box Likely to implement • One place to search for anything 37
- 38. Git integration Likely to implement • Initially just a browsing tool for comments/ commit changes • Timeline feature (at the bottom) still work in progress 38
- 39. Feedback welcome • Having a reaction to some of those images? • Let us know! https://groups.google.com/forum/#!forum/scripted-dev https://issuetracker.springsource.com/browse/scripted 39
- 40. Summary • The basic idea • Observations and assumptions • The prototypes – The Scripted Code Editor • Where are we heading? 40
- 41. Any questions? • Google Group: scripted-dev https://groups.google.com/forum/#!forum/scripted-dev • Project page: https://github.com/scripted-editor/scripted Andy Clement Martin Lippert Andrew Eisenberg aclement@vmware.com mlippert@vmware.com aeisenberg@vmware.com @andy_clement @martinlippert @werdnagreb 41
- 42. The End 42