N.B. This one of the first sessions held at nodeconf, everybody was still somewhat rusty.
One of the first recommendations were to do static analysis. This goes through your code and finds dead dependencies or function that are never called. By using this you can eliminate redundancy in this way. Some modules that work great for this are @substack’s detective or the module tree analysis by @hughsk called disk (looks good too!).
Substack actually did a talk on Abstract Syntax Tree’s (which can be used to do static analysis) at jQuerySF, which goes a bit more into detail on what you can do with AST’s and how Static Analysis works behind the scenes.
React got a lot of attention too. A small template rendering engine that let’s you render the page on the server, and with the same set of libraries render the changes on the front-end. So the page is fully loaded when you first land on the page, in stead of the startup time that’s required for full-fledged MVC(-likes) such as: AngularJS, Ember and Backbone. React’s server side rendering here is the one thing that really stands out, together with the speed and the small size of the library. Most people really seem to be fond of this approach (after dealing with the ugliness which is JSX).
According to substack, we shouldn’t use big shims, we shouldn’t use frameworks. Because it will break stuff, or come back to haunt you. Especially if you’re trying to run Universal JS. We should create small modules that uses CommonJS’
This kind of moved on to the discussion of Modular UI which was another topic. The gist of this session was to make modules that expose css and assets through inline css or conditional building. A well known implementation doing UI in this way is the Polymer Project. Every component is a module that doesn’t have to be a part of the rest of the project. To include a small piece, you just:
npm install --save my-special-module.
The rest of my notes say:
So if anyone feels like filling me on on what this meant, that would be grand.