BT

An Interview with Jason DiBianco of Linq 4 Javascript

| by Jonathan Allen Follow 578 Followers on Sep 30, 2014. Estimated reading time: 3 minutes |

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT