jstafford
commented
7 years ago Hey, I was looking at the dependencies of mocha, and saw JSON3, and I was like, what's that? Should I be using that? And then I read the project description on npmjs, and I was confused, because it didn't add up, but with 332,940 downloads a day, I figured I must be missing something. Then I found this ticket of yours. I guess I wasn't missing anything, but it seems you have missed your deadline. By my calendar it is now May 17th, 2017, so I think you are two months overdue for pulling the plug.
I know how hard it is to give up on something you've put so much time and effort into, but you're actually making things worse by doing nothing. If you mark it as deprecated, and suggest using the browser native JSON, projects will slowly start switching away from JSON3, and eventually it will fade away. The entire JavaScript/Node/NPM/browser/V8 mess/ecosystem will be a tiny, tiny bit better for having one less unmaintained, bloated package.
Just my two cents.
avioli
Hello GitHub stargazers,
I think it's been clear for a while that I've abandoned JSON 3. To the folks watching and using this project, I'm very sorry for letting PRs slide, and for my inattention to new issues. It's upsetting to see contributions ignored, and you have every right to feel frustrated. Procrastinating, instead of asking for help and looking for new maintainers, was not a constructive way to sunset the project. I will do better in the future.
TL;DR: If you'd like to take over JSON 3, please reply to this issue. I'll leave it open until 17 March 2017. After that, I'll update the readme, description, and package managers to indicate the project is obsolete and unmaintained. I won't delete or unpublish it, but you should definitely think about using JSON 2, or removing the polyfill entirely. In the meantime, I'll go through and merge or close outstanding PRs and issues.
So, what's the state of the project? Short answer: old and busted. Longer answer:
It's slow.
evalisn't a speed demon, but walking large strings character-by-character in a big loop, then recursing into objects and arrays, will lock up old browsers. We've had several issues like that. The included "benchmark" is a 168-byte string, plus some longer strings in the jsPerf that run on modern browsers. The claim that this design "provides security and performance benefits in obsolete and mobile environments" is blatantly wrong, and I shouldn't have made it in the first place. If you pick and choose what you're looking for, and don't test on platforms that need this most, of course it's going to perform well!It's big. 3.5k is a lot, especially on mobile. For comparison, a core build of Lodash is 4k, and it's packed with useful functions. This, OTOH, is a library-sized polyfill that does something your browser can already do, and that most don't even need. All browsers have had fully compliant implementations (or mostly compliant, with weird edge cases that don't matter) for years. For example, there's a feature test that checks if six-digit years are stringified correctly. How many apps need to work with dates 275k years into the past or future?
It's old. The description "a modern JSON implementation" is about 5 years out of date. Our feature tests check for bugs in IE 7, Firefox 3, and Safari 5, which are 10, 8, and 7 years old. The modern web would be unusable on one of these browsers today. It's fun to say we can technically support hipster browsers that run on Windows 2000, but that means nothing if you can't actually use the web. A JSON polyfill won't change that.
It's overly clever. The
lexfunction is a giant loop that sets and reads from global state. There are several one-liners and empty loop bodies that I thought "clever" 5 years ago, but that just make the code unreadable, and make linters complain. This isn't JS1k or an Obfuscated C/Perl code contest. Clever code is for fun and minifiers, not boring libraries.It's monolithic. The library is wrapped in a giant IIFE, with conditional exports, feature tests, and shared helpers strewn about. I started working on a webpack-based build system, and had vague ideas about pluggable parsers and conditional builds. But that means introducing more bloat into an already big library, and I'm not sure it's worth it. Browsers released since 5 years ago haven't needed JSON 3, I don't think custom builds are the answer.
There's one more reason, and it's that I haven't had much time to fix outstanding issues. Maintaining a crufty project like this takes discipline, and it's easy to get distracted by other things.
So...if you've read through this Saturday afternoon rant, thank you. If you've contributed a patch to JSON 3, or found it useful, thank you. A big thank you especially to @demoneaux, who optimized the parser as much as he could, removed support for ancient environments, cleaned up the code, and set up tests.
If you'd like to maintain it, I'll take the time to help you get set up, and go through the backlog of issues. If not, the project will still be here, but with a warning that you probably shouldn't use it. I picked 17 March 2017 arbitrarily, so that I can follow through, instead of letting this sit for two more years.