An Interview with Jason DiBianco of Linq 4 Javascript

There are a few attempts at building a LINQ implementations for JavaScript. Today we choose to present Linq 4 Javascript by Jason DiBianco because it is based on lazy evaluation, an important design concept for LINQ. The fact that it includes TypeScript bindings is also a nice touch.

InfoQ: At this point I don’t think anyone has doubts as to why LINQ would be useful for any language. So instead I would like to jump right into the implementation details. In .NET, they were able to base Linq to Objects on the IEnumerable<T> interface. JavaScript doesn’t have that concept, or really interfaces at all, so what did you use instead?

Jason DiBianco: The IEnumerable interface in .Net allows the developer to Iterate over something: a list, a set of files, a data stream, etc. LINQ 4 JavaScript was mainly developed to consume a list of T, thus using an array as a basis for all queries. Linq 4 JavaScript implements all of its methods using the prototype mechanism (extension methods) off of an Array to start any query. I.e.: _Array.Where(x => x.Id > 100).ToArray();

InfoQ: What were the biggest challenges you had porting LINQ to JavaScript?

Jason: Many of the top JavaScript LINQ implementations use eager evaluation to return the results. While eager evaluation will work and will for the most part not incur a performance hit, as you start to increase the number of records, properties, or chained expressions, your query performance will begin to degrade due to memory consumption.

Each time a command returns a separate array is materialized. That takes memory - which slows down execution time. In some scenarios only a small subset of that array will be used.

For example, consider the following query: _Array.Where(x => x.Id > 1000).Take(5);

By eagerly building the result set the first Where() statement would need to create an array with all the results. Suppose your _Array has 50,000 items. The Where() clause would first return a separate array with 40,000 elements.

The Take() method would then accept those 40,000 rows and return the first 5 rows. The materialization of the untouched rows is superfluous.

In Linq 4 JavaScript, building the iterator pattern to implement lazy evaluation was essential when porting the LINQ functionality. In the example above,

Linq 4 JavaScript would loop through the record set 1 at a time. When it got to a record where .Id > 1000, it would then progress to the Take() method and return it, and repeat until a count of five records was reached.

No array is materialized when building the results and memory consumption remains negligible.

InfoQ: Did you implement Linq 4 Javascript from first principles or did you base it on an existing implementation for another language?

Jason: I did use first principles with a few adjustments. I always wrote the test cases as I was coding mainly to test the syntax. When I started the project, one of my main goals was to have a syntax that was identical to .NET's syntax. After writing a method, I always created the test case to ensure the syntax matched exactly what I was looking for.

InfoQ: Overall, what are your impressions of TypeScript? Would you choose it again for starting a new library or website?

Jason: I've used TypeScript for a few projects now and I am definitely on the bandwagon. All new projects that involve a JavaScript component will be built using TypeScript.

For no other reason, I would convert legacy js files to TypeScript just for the compiler time checking. The reason I adopted TypeScript instead of Coffee Script is primarily because TypeScript is JavaScript.

I can add as many or few types to variables as I please. In my experience, TypeScript increases productivity and produces cleaner code.

InfoQ: Do you intend to publish Linq 4 Javascript on NuGet or other package repositories?

Jason: Yes. I’ll be expanding the audience in the coming weeks.

InfoQ: I noticed that you settled on PascalCase method names, while others prefer camelCase. Do you have any thoughts or opinions on the current state of naming conventions in JavaScript?

Jason: Not really. I have no preference either way - so long as there’s consistency throughout and the variable name makes sense. Additionally, the original goal of LINQ 4 JavaScript was an application of LINQ to Objects for JavaScript, similar in name and syntax to the original C# implementation, so PascalCase seemed a natural fit.

Linq 4 Javascript is available on Codeplex under the MIT license.

To suggest other open source projects that should be highlighted on InfoQ, contact Jonathan Allen at jonathan@infoq.com.