# On the new json module **URL:** \ **Category:** Mojo\ **Tags:** discussion\ **Created:** [May 6, 2025, 5:33pm UTC](https://forum.modular.com/t/on-the-new-json-module/1381 "2025-05-06T17:33:57Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![bgreni](https://avatars.discourse-cdn.com/v4/letter/b/e495f1/32.png) [@bgreni](https://forum.modular.com/u/bgreni)\ **Post date:** [May 6, 2025, 5:33pm UTC](https://forum.modular.com/t/on-the-new-json-module/1381/1 "2025-05-06T17:33:57Z")
I see in the recent nightlies that a [`json`](https://github.com/modular/modular/blob/main/mojo/stdlib/src/json/json.mojo) module was introduced to the stdlib, which I think is a good thing, but I’m curious why we didn’t consider porting in the [EmberJSON](https://github.com/bgreni/EmberJson/tree/main/emberjson) implementation. At the time I started the project I was told that a json module was unlikely to be included in the stdlib, so naturally I built it as a community library, but since that is no longer the case. I think it would make sense to take advantage of the work already done, rather than reinvent the wheel? At the time of writing this EmberJSON has the following benefits - 0 Dependencies - 114 existing tests - An existing benchmarking suite - Superior performance to the current stdlib implementation - UTF-8 support - Fast float point parsing using the simdjson algorithm, with a truncating fallback implementation for floats with many decimal points - Distinct parsing of integers and floats to avoid precision loss for large integers - SIMD-accelerated minifier - SIMD-accelerated string parsing - Tree-based object representation to improve large object parsing performance - Pretty-print formatting Granted I do employ a fair amount of unsafe code to achieve this, so if the team is unwilling to adopt it for that reason, then I respect that. I just figured I would prod a bit here out if curiosity. - Brian ---
**Author:** ![sora](https://avatars.discourse-cdn.com/v4/letter/s/ad7895/32.png) [@sora](https://forum.modular.com/u/sora)\ **Post date:** [May 6, 2025, 6:20pm UTC](https://forum.modular.com/t/on-the-new-json-module/1381/2 "2025-05-06T18:20:32Z")
We should at least ~~blindly~~ port all the tests. ---
**Author:** ![gryznar](https://avatars.discourse-cdn.com/v4/letter/g/e5b9ba/32.png) [@gryznar](https://forum.modular.com/u/gryznar)\ **Post date:** [May 6, 2025, 6:32pm UTC](https://forum.modular.com/t/on-the-new-json-module/1381/3 "2025-05-06T18:32:01Z")
Also as I’ve pointed at Discord, current naming is far away from being good. `load` as free function is just a strict copy from Python which API is confusing. `load` and `loads` are not informative and have sense only with module name context. ```mojo from json import load var _ = load(...) # not enough context to make `load` unambigous ``` As stated [here](https://forum.modular.com/t/on-the-compatibility-familiarity-ergonomics-dynamism-and-api-design-for-the-python-mojo-relationship/1234) there are no objections to have different API at Mojo side with extension support for Python compatibility. Overall I am +1 for using `EmberJson` as a base for future improvements @joe gentle ping as you are stdlib team leader ---
**Author:** ![martinvuyk](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/martinvuyk/32/48_2.png) [@martinvuyk](https://forum.modular.com/u/martinvuyk)\ **Post date:** [May 6, 2025, 7:45pm UTC](https://forum.modular.com/t/on-the-new-json-module/1381/4 "2025-05-06T19:45:31Z")
FWIW if anyone ever builds something that uses json for compute-heavy workloads, then they are probably going to search for libraries like EmberJSON. I’m guessing, but I imagine the thought process behind the decision was somewhere along the lines of: “less lines, less maintenance”. The stlib implementation stands currently at around 1270 lines. I do however sincerely hope that EmberJSON is fully incorporated into the stdlib, it is faster and much better organized. I think many in the community would be willing to step in as maintainers. Unstructured JSON parsing is something that should be SOTA in the stdlib, maybe we can leave out structured JSON for external libraries. FWIW I also feel that I would become quite distraught if something similar were to happen with an inferior datetime library being incorporated into the stdlib instead of the one I’ve worked on for months with the express goal of integrating it into the stdlib. IMO Modular should not disregard the community like this… ---
**Author:** ![adakkak](https://avatars.discourse-cdn.com/v4/letter/a/b19c9b/32.png) [@adakkak](https://forum.modular.com/u/adakkak)\ **Post date:** [May 6, 2025, 11:27pm UTC](https://forum.modular.com/t/on-the-new-json-module/1381/5 "2025-05-06T23:27:01Z")
Hi Bgreni, I wasn’t aware of the EmberJSON project - thanks for bringing it to my attention. I’d definitely encourage you to submit a PR replacing our existing JSON module with what you’ve developed. Your implementation looks to be of higher quality than what I’ve put together. To be transparent, I wrote the current JSON code during a plane ride as a quick solution, so there’s nothing particularly special about it. I’d be happy to see it replaced with your more robust implementation. Looking forward to your contribution! Best regards ---
**Author:** ![bgreni](https://avatars.discourse-cdn.com/v4/letter/b/e495f1/32.png) [@bgreni](https://forum.modular.com/u/bgreni)\ **Post date:** [May 6, 2025, 11:38pm UTC](https://forum.modular.com/t/on-the-new-json-module/1381/6 "2025-05-06T23:38:35Z")
Thanks Abdul, I appreciate the update! I’ll touch base with the stdlib team later to figure out how best to move forward with that since it would be a fairly hefty contribution ---
**Author:** ![adakkak](https://avatars.discourse-cdn.com/v4/letter/a/b19c9b/32.png) [@adakkak](https://forum.modular.com/u/adakkak)\ **Post date:** [May 6, 2025, 11:42pm UTC](https://forum.modular.com/t/on-the-new-json-module/1381/7 "2025-05-06T23:42:21Z")
Just FYI: No need to integrate anything. I’d be happy to delete the json.mojo file and replace it with your implementation if that’s the easiest approach. ---
**Author:** ![bgreni](https://avatars.discourse-cdn.com/v4/letter/b/e495f1/32.png) [@bgreni](https://forum.modular.com/u/bgreni)\ **Post date:** [May 6, 2025, 11:49pm UTC](https://forum.modular.com/t/on-the-new-json-module/1381/8 "2025-05-06T23:49:50Z")
I’ve done a few things that Joe and others might take issue with (like write number parsing and stringification from scratch) from a maintenance burden point of view. So mostly there might need to be some discussion around that ---
**Author:** ![gabrieldemarmiesse](https://avatars.discourse-cdn.com/v4/letter/g/e79b87/32.png) [@gabrieldemarmiesse](https://forum.modular.com/u/gabrieldemarmiesse)\ **Post date:** [May 7, 2025, 7:18am UTC](https://forum.modular.com/t/on-the-new-json-module/1381/9 "2025-05-07T07:18:01Z")
Purely for coordination purposes, here is the PR for fast float parsing. If everything goes well, I should get a review this week. > > > \> @jackos @JoeLoser let me know when you have the bandwidth to tackle this subje…ct, I'll update my PR then :) > > We should have bandwidth to review this sort of thing later this week if you'd like to rebase. Thanks for your patience, @gabrieldemarmiesse. CC: @abduld as well since you just posted about this on Discord. ---
**Author:** ![joe](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/joe/32/471_2.png) [@joe](https://forum.modular.com/u/joe)\ **Post date:** [May 7, 2025, 5:36pm UTC](https://forum.modular.com/t/on-the-new-json-module/1381/10 "2025-05-07T17:36:22Z")
Hey @bgreni I’ll take a look at your library and let’s work together with @gabrieldemarmiesse as there’s likely room for overlap in creating space for a “format” module to contain these shared utilities. ---
**Author:** ![bgreni](https://avatars.discourse-cdn.com/v4/letter/b/e495f1/32.png) [@bgreni](https://forum.modular.com/u/bgreni)\ **Post date:** [May 7, 2025, 5:50pm UTC](https://forum.modular.com/t/on-the-new-json-module/1381/11 "2025-05-07T17:50:28Z")
Thanks Joe! Admittedly the documentation is a bit sparse, so let me know if you have any questions ---
**Author:** ![martinvuyk](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/martinvuyk/32/48_2.png) [@martinvuyk](https://forum.modular.com/u/martinvuyk)\ **Post date:** [May 7, 2025, 10:18pm UTC](https://forum.modular.com/t/on-the-new-json-module/1381/12 "2025-05-07T22:18:00Z")
I think there might be room for a json-specific implementation or at least splitting up/parametrizing atof, because there are things like `1e10_0` which aren’t part of the json standard ---
**Author:** ![bgreni](https://avatars.discourse-cdn.com/v4/letter/b/e495f1/32.png) [@bgreni](https://forum.modular.com/u/bgreni)\ **Post date:** [May 7, 2025, 10:23pm UTC](https://forum.modular.com/t/on-the-new-json-module/1381/13 "2025-05-07T22:23:19Z")
If I had it my way I would probably prefer keeping them separate for such reasons, as well as I am inlining things much more aggressively then we probably should be for the general use `atof` function, but in the end it’s up to the team of course. ---
**Author:** ![strangemonad](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/strangemonad/32/412_2.png) [@strangemonad](https://forum.modular.com/u/strangemonad)\ **Post date:** [May 20, 2025, 5:43am UTC](https://forum.modular.com/t/on-the-new-json-module/1381/14 "2025-05-20T05:43:03Z")
@bgreni @joe @adakkak, I’m loving the discussion about potentially including emberjson into the stdlib. I’d like to suggest a few thoughts related to data serialization / deserialization and data format support. I’m not sure if this is the right place to have that discussion? The topics can roughly be organized as follows: 1. Ser/De and data-formats beyond json 2. What formats belong in std-lib # 1. Serde beyond json One of the things that both go and rust did really well was expose common mechanisms / traits for struct serde to and from various data formats. This is something that’s lacking in pure python but would be great to have in the stdlib for mojo. - Go exposed the conventional way of using tags + a few common interfaces (the various Mashaller and Unmarshaller interfaces in `package encoding`), to drive data marshaling. This is probably one of the language features that’s allowed go to be used heavily to define APIs and data types across the cloud-native ecosystem (eg the entire kubernettes API is canonically defined as go structs) - Rust obviously has the serde crate for a long time now. I haven’t followed recent developments of alternatives (eg sud, merde, etc) so some of the thoughts around state of the art might have evolved here # 2. Implementations I think the ecosystem would benefit from defining the core ser/de or marshalling traits in the std lib but not all data formats need to live there. I’m not sure if something like this has been discussed yet, but in a world where it’s easy to fetch packages with a package manager, it might be nice to keep the std lib smaller and setup an set of official extension packages similar to how go structures its various “x” packages [Sub-repositories - Go Packages](https://pkg.go.dev/golang.org/x) (ie those part of the go project but out of tree). For things that might have an open ended number of variants like data formats or hashing algorithms, especially ones that might got stale over the years, it might be nice to set up an out of tree package structure that proactively resilient to future changes while still providing “official” implementations. ---
**Author:** ![martinvuyk](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/martinvuyk/32/48_2.png) [@martinvuyk](https://forum.modular.com/u/martinvuyk)\ **Post date:** [June 17, 2025, 4:43pm UTC](https://forum.modular.com/t/on-the-new-json-module/1381/15 "2025-06-17T16:43:04Z")
Hi @strangemonad 🙂 > 1. Serde beyond json I think we are mostly waiting for reflection and parametric traits to enable good ser/de capabilities and traits. > 1. Implementations As for having different repos for the implementation, that sounds interesting. But I’m not sure how the stdlib team would be able to handle it given the whole modular stack is a monorepo This is worth posting as a separate forum post about ser/de. But probably later on once we have some more language features