remove browser support

[davidchambers]

Closes #62

I did most of this work in 2015. It feels good to have finished it. :)

[danse]

it's great that you found the time to clean up pending tasks. this doesn't seem to remove as much infrastructure as i thought, so are you sure you want to drop support? some years have passed and while i personally never used doctest in the browser and i will probably never do it, now i can imagine its use for educational purposes. one of the easiest ways to introduce someone to programming is to give them an index.html and script.js and adding doctests to this scenario seems a powerful way to introduce newcomers to test driven dev. am i missing something? anyway you have visibility on the maintenance costs of this feature, i don't ... so feel free to go ahead! 👍

[davidchambers]

Thank you for reviewing this pull request, Francesco! I hope life is treating you well. :)

this doesn't seem to remove as much infrastructure as i thought, so are you sure you want to drop support?

Yes, I'm sure. I've had several years to consider the matter. ;)

More than any other project to which I contribute, this project supports multiple ways of doing things:

• Environments. Browser and Node.js.
• Languages. CoffeeScript and JavaScript (ES3 and ES6).
• Module systems. AMD and CommonJS. Likely import/export too, at some point.
• Comment styles. Block comments and line comments.

I believe it's important to remove support for options which fall out of favour, to prevent the project from accumulating code paths which are rarely exercised. CoffeeScript's popularity is declining, for example, so we should consider removing CoffeeScript support at some point.

Simplifying the project allows us to simplify the documentation. I agree with your comment from #25:

keeping a slim README may help newcomers in approaching the tool

one of the easiest ways to introduce someone to programming is to give them an index.html and script.js and adding doctests to this scenario seems a powerful way to introduce newcomers to test driven dev.

I don't recommend using doctests in place of unit tests. I see doctests as executable documentation, guaranteed—in conjunction with continuous integration—to be up to date. This project is primarily a documentation linter rather than a code tester. I'm in favour of introducing newcomers to testing early in their programming journeys, but I don't think doctests are the right tool for this job.

[danse]

oh, very interesting to know what you consider to be the proper use of doctests ... it's a succinct and effective way to explain it, maybe it could go in the README in a section about the role of doctests ... i feel like there has been declining awareness about how to take advantage of them. to me personally, doctests were the way i got addicted to test driven dev. everything started with a python doctest, and i tried it because i saw that it was easier to run the doctest than to set up unit tests. i got addicted to doctests because they helped so much in designing code yet to write, and a lot of time later i realised that i could achieve the same with unit tests and that it was called "test driven dev" ... but really, that sounds and feels way more boring than a sneaky test in your function's doc.

now after years of test driven dev i almost never use doctests, but they've been fundamental in my growth as a developer ... so ... now thinking of them like "doc that is always up to date" gives me a new way to try to use them.

i am a bit skeptical because my experience is that code is understandable via doctests when it's developed via doctests ... when it's not, the complexity of types or classes makes them difficult to build in a doctest ... but i might be wrong, it's worth another try

[davidchambers]

everything started with a python doctest, and i tried it because i saw that it was easier to run the doctest than to set up unit tests.

Ergonomics matter, particularly for optional parts of the development process. Your experience indicates that for unit testing in Python, the barriers to entry are—or were—prohibitive.

i am a bit skeptical because my experience is that code is understandable via doctests when it's developed via doctests ... when it's not, the complexity of types or classes makes them difficult to build in a doctest ... but i might be wrong, it's worth another try

This is an excellent point. Doctests, as input expression – output value pairs, are best suited to testing pure functions. Doctests promote the definition of pure functions to a greater extent than do unit tests.