Re: N3.js 0.2.0: now with browser support

Hey Ruben,

This looks really nice, thanks for the effort!
I am right now using N3.js through rdfstore-js actively. We are building a library aiming to make visualizations of graphs easy (like everybody tries), but also adaptive to the user and device and should also present not yet seen structured graphs in a more or less human readable way. (I am personally annoyed by all the graph representations of graph based information. This because I think graphs representations are not optimized for the human but for …?)

Anyway, to the point: As this library also is build in JavaScript I would like to profit from your learning curve in the way of what tools you did use for your development. I don't speak about editors or such (even if might be interesting) but much more about stuff like the test environment, how to make a library useful in Node and the browser (which build scripts), what is necessary to look at to make it browserify compatible, in a nutshell I would like to hear from a "senior" how to head start the development of a JavaScript library.

Kindest regards,
Michael


On 03.12.2013, at 22:29, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:

> Dear all,
> 
> A few moments ago, I released node-n3 version 0.2.0, which has now been rebranded into N3.js.
> This new version brings lightning-fast, asynchronous, streaming read/write Turtle support
> to Node and all major browsers (and a lot of other JavaScript environments, hence the rebranding).
> 
> The following solved issue in this version might be of particular interest to this list:
> https://github.com/RubenVerborgh/N3.js/issues/13
> The library was performing really well on Node/Chrome, but not on Firefox.
> In particular, a file that took 30ms in Chrome took 1000ms (!) in Firefox.
> This was due to Firefox' inefficient evaluation of some regular expressions.
> As a rule of thumb, expressions with nested parentheses are interpreted rather than compiled,
> which is a very inconvenient for almost all parsers.
> In contrast, (as far as I know) all expressions in V8 are compiled and thus very fast.
> 
> I managed to get around the issue by limiting the needed number of expression evaluations:
> based on the first character of the next token, it is decided which expressions are possible (http://git.io/2NmL8A).
> This resulted in Firefox' performance drastically improving up to V8 level, and a 10% faster execution on V8.
> Lesson learnt: regexes are fast, first-char comparisons are faster.
> Seems actually very logical, but thanks to the bug I actually had to try it.
> 
> Other things worth knowing about:
> - Testling is handy for automated cross-browser tests (https://ci.testling.com/)
> - Weird things happen with regexes in Firefox if `test` is followed by global `replace` (http://git.io/BUSGwQ)
> - IE9 apparently treats 0 as null sometimes (http://git.io/MP87XA)
> 
> Also, I was wrong to think N3.js didn't need browserify support because it offered a custom browser version.
> If other people have your project as a dependency, they can build their project with browserify.
> Plus, browserify brings Node streams to the browser as well.
> 
> Best,
> 
> Ruben

Received on Wednesday, 4 December 2013 14:05:37 UTC