CSVjs: Basic CSV parsing and encoding in JavaScript

yet, that is what most csv code does. heck, ms excell did that until a few versions ago.

(sorry accidentally hit the downvote button, so commenting to give you the karma back. hmm that used to work afaik, doesn't seem like it helped.)

You should ditch CoffeeScript and do it in vanilla JS, if for no other reason than to avoid people like me telling you to ditch CoffeeScript and do it in vanilla JS. ;)

In all seriousness though, far beyond anything I was doing at 16. Kudos.

Some feedback:

- Vanilla JS would be cleaner

- Make it useable with Node. (Check if "window" variable exists, if not, do export CSV as a module. Should be this easy AFAIK)

- You have some typos on the README.md

- Put this on bower and npm

Good work. I was writing software at 16 but I wasn't doing it open source, I wish I did.

The fact that you're 16 and getting into software development is cool, but not particularly exceptional. I don't know how much more exceptional it is that you're already into OSS, as that was less of a concept when I was at that age...though I'm going to say that as someone much older than you who is just now slowly contributing to OSS, you're probably ahead of the curve.

But what impresses me most is that you're only 16 and you care enough about something as "boring", yet bread-and-butter as CSV parsing. CSV-parsing is not particularly sexy, and there are a lot of libs that do it...but tackling it as a problem to solve, nevermind open-sourcing your solution, is really cool...even if you decide you don't want to be a full-time software developer, your experience (and tolerance) for this kind of data-munging is going to make you a valuable person to work with in any field.

The fact that you're taking the time to write readable documentation for this puts you even farther afield.

In terms of criticism/feedback...what was your reasoning for returning an Object with certain domain-specific properties (i.e. `data` and `fields`) rather than just an Array of hashes? I think the CSV constructor call works fine, and that being the case, maybe add an option in the options hash to return a CSV-object-with-metadata...but by default, `csv.parse()` should return a plain array of objects, so that other programs that utilize it don't have to remember that the data is actually in the Object's `data` property.

Also, you've probably seen D3's implementation, which is designed with the mindset that the CSV-to-be-parsed is likely an external file: https://github.com/mbostock/d3/wiki/CSV

Where did you get your inspiration?

This is pretty similar to a library I'm actively working on called Papa Parse: http://papaparse.com

Don't cast by default. It unnecessarily slows down the parser when the input is purely string data.

Don't hesitate to look at how other CSV libraries work. They've likely solved most/all of the issues you're currently having.

Do add the ability to cast scalar values (ex ints, floats).

Do verify RFC compliance using tests.

Do use vanilla Javascript. Niceties like Coffeescript are good for one-off webapps but add unnecessary dependencies/problems if you're targeting a larger audience.

Do have a solid plan for versioning. Only add backwards-incompatible changes to major versions (ie 1.0, 2.0).

Do have your users try the code in different browsers/platforms. Differences in Regex implementations can cause problems and using streams in Node will be completely different than handling them in the browser.

You win the million dollar prize if you can manage to figure out how to write a CSV stream reader that works in the browser.

Mike Bostock pointed out that he had already extracted D3's DSV parsing into it's own repo when i expressed my disappointment i couldn't use d3's w/o rewriting parts of D3's DSV parser.

It lives here: https://github.com/mbostock/dsv

ps it properly scans & tokenizes CSVs and handles quoted fields fine as a consequence

It's not as complex as you make it sound. The parser should pass along any non-terminal characters without issue.

The rest of the edge cases (ex newlines in data) can be handled by using a proper DFM (Deterministic Finite State Machine). None of that String.split('\n').split(',') garbage.

If you're processing text as binary without using a string reader that can differentiate between UTF-8 and ASCII then you're doing it wrong.

With that said, I agree completely that people should use an established library. Code that has been viewed, used, broken by thousands of users is infinitely better than any home grown variant.

Source: With lots of blood sweat and tears I authored one of those 'solid' libraries.

Thanks for the feedback on the docs. Working on them now.

As for overriding the header, I think its possible utility offsets the ~3 LoC that it adds. Coming next commit.

This'll return a CSV based off of a JavaScript array of objects (or arrays). You'll have to find something else to allow the user to download a .csv, since that's out of the use-case this was designed for.

You could create a download file, but only in newer browsers.

We have an internal application which requires CSV export, we use something like this:

        csv = cleanTurkishChars(makeCSV(data));
        csv = 'data:application/csv;charset=utf-8,' + encodeURIComponent(csv);
        $("#csvexport").attr({
            'href': csv,
            'target': '_blank'
        });

Looks like you've missed values enclosed in quotes that might contain new line characters or commas -- very important for things like address fields.

Congratulations, this code failed to properly parse my CSV at least 100 times faster than OP's :)