Greg is being modest by not mentioning his [AMDClean](https://github.com/gfranko/amdclean) library more prominently - it's a superb example of what he's talking about in this presentation.
It makes it possible to use AMD modules while building a library or web app (which is utter bliss when it comes to testing and debugging - no build lag or source map nonsense), but to convert it to non-AMD JavaScript in the final step. I use it on a fairly large (~10,000 LOC) library, [Ractive.js](https://github.com/RactiveJS/Ractive), and it's transformed the way I work.
I've had to do a lot of this recently for CodeCombat's transpiler, Aether: https://github.com/codecombat/aether – it uses Esprima, Acorn, JSHint, and a bunch of other JS tools. There's a ton of great stuff out there, and it's easy to put them together since they all operate on the Mozilla SpiderMonkey Parser API abstract syntax tree format.
If anyone likes this stuff and wants to write an open-source, in-browser parser from another language like Python, Haskell, or Ruby to the Mozilla AST format, we'd love to make it worth your while. See https://github.com/codecombat/codecombat/issues/72 and then email me to work out an arrangement.
I just want to point out that parsing is the easy part of writing a language implementation. E.g. for Python all of the interesting stuff is in the VM and bytecode generator, the parser is just one page of a grammar that gets fed into a parser generator (for CPython). You will have a much harder time with Haskell since even more of the interesting stuff is done to the intermediate representation (ghcjs is the only thing I know of trying to run it in javascript).
The larger problem I am doing is static code analysis for Firebase and the JS tools for doing such stuff are delightful compared to yacc and lex and javacc etc.
Functional programming really shines in this domain. You can populate your symbol table with functions that get "called" when "CallExpressions" are encountered during parsing, or functions that expand to function declarations on "MemberExpression" are encounter during parsing (the <dot> operator). Its very easy to mirror the true structure of JS using JS if that makes sense.
thanks! I did not work it out myself. It presented a load of jumble for a flash and did nothing. Clicking it just opened another window with the same initial jumble (Chrome linux something)
I stared at the page for 10 seconds before realising that i have to use arrows. I'd suggest adding simple instructions like "Press arrow keys to navigate".
Ok that is static code analysis for JS. What is static code analysis good for? Seriously, can someone please explain or post a link better than Wikipedia? I live under the impression that I write beautiful (understand sufficiently optimal) OO JS using TypeScript, what has SSA to offer to me? PS: of course I a noob.
You may someday want to build tools to transform javascript code. Suppose you wanted to Typescriptify some legacy code. You'd build your own js code processor, using the libraries this presentation advertises.
My presentation focused on creating new tools, but it is important to understand the concepts so that you can contribute to existing tools. Maybe in the future you will contribute to TypeScript.
In terms of the converting to PDF (to upload to Speaker Deck), it is recommended to just save the webpage to PDF in chrome or another browser that supports this feature (you can do this by beginning the print process and then changing to 'Save as PDF')
Bespoke has a print stylesheet, which is why the styles are still kept.
It makes it possible to use AMD modules while building a library or web app (which is utter bliss when it comes to testing and debugging - no build lag or source map nonsense), but to convert it to non-AMD JavaScript in the final step. I use it on a fairly large (~10,000 LOC) library, [Ractive.js](https://github.com/RactiveJS/Ractive), and it's transformed the way I work.