[deleted]
Rich on serialization
Sorry, this post was deleted by the person who originally posted it.
Best
Open comment sort options
Best
Top
New
Controversial
Old
Q&A
Not going to dignify this bullshit with a full response here, but for anyone who is interested in the rationale, here you go.
Devalue does support dates
Rich's Devalue is significantly inferior:
unmaintained, got its last update 2019 (non-README)
lacks many types, e.g.,
ObjectId,BigInt,Deciaml.js,Prisma.Decimal,Error+ morenot type-safe
no autocomplete
no plugins
no low-level access to its
serializeanddeserializefunctionsno option yet, no ETA for an integration has been announced (only post-1.0.0 which might be 2023) and you know why? Because devalue is not ready for prime-time
It's not about dates but that users get a choice.
superjsonsupports more types, plugins and type safety with autocomplete. And we get devalue sometime post-1.0.0, why the wait? I'd be already happy having devalue included with Date supported.Comment removed - leaving Reddit permanently due to their massive mistreatment of 3rd party app developers, moderators, and users, as well as the constant lies and scumbag behaviour from CEO u/spez.
Background: Latest SvelteKit blocks all SSR responses incl. Date, ObjectId and more.
Rich could just add
superjsonwhich supports them all, has plugins, small runtime footprint and full type safety! But Rich pushes his own libdevaluewhich isn't anywhere close and isn't integrated yet. We cannot even choose our own serializer. And devalue's integration should happen sometime post-1.0.0 while turn-key ready superjson, at least at temp. solution, is being ignored. Having a fast, type-safe and feature-complete serializer is highly crucial for any framework and superjson fits the bill—now.Related Github issue and current discussion (the first post mentioning superjson was marked as off-topic in case you miss it): https://github.com/sveltejs/kit/issues/6008
Edit: Why the downvotes?
"devalue isn't anywhere close" is clearly a huge exaggeration, and including such hyperbole in your argument undermines your whole position imo because it makes you seem irrational. Based on the your own links, the only return type which superjson supports and devalue does not is bigint. Errors are a non issue because they should be thrown rather than returned.
There's also nothing stopping you serialising arbitrary values (such as a bigint) yourself and then passing them to SvelteKit already serialised (i.e. as a string) and then deserialising on the client.
This topic seems like a super minor convenience feature if you ask me
superjson has a plugin system and also supports ObjectId. https://github.com/blitz-js/superjson/pull/71
I disagree, it has a plugin system, autocomplete type-safety and is turn-key ready, check also https://www.reddit.com/r/sveltejs/comments/wx7aec/comment/ilpjnoy/?utm_source=reddit&utm_medium=web2x&context=3
You lose type safety, create an additional run and a performance hit and e.g. I don't want to have ObjectId to be serialized/deserialized b/c a
new ObjectId()doesn't care if the input is string or ObjectId in the client.ATM, it's blocking, so we have to do something with ObjectIds (or Date) creating this perf hit.
Minor inconvenience? Everyone who's using a DB gets Date types in their responses which currently breaks their code. Not even that, it's a blocking.
Look, I would also be happy to have already devlaue included but Rich want to do this sometime post-1.0.0
I wouldn't call a blocking issue "minor", except you do some static webpages without SSR but then you wouldn't use SvelteKit in the first place.
because it's trying to be a meme and it's misused
I hate seeing crap like this. Rich might or might not have made the right decision, but seeing his decision being satirized/memefied as some sort of insecurity is pretty distasteful. It's an open source project, you could at least open a pull request with an adapter that permits other serialization options and give the Svelte team the option to reject it before posting stupid stuff like this.
Not saying you gotta agree with the guy and I totally understand the community's frustration with this particular issue, but stupid stuff like this is exactly what turns people off to OSS development.
You either die the hero or live long enough to see your decisions become memes about how you can't handle other people's work. If you're talented enough, why not try to contribute yourself?
I'm out of the loop. What is superjson?
It's a serializer which covers types which aren't covered by JSON.stringify and JSON.parse, you need a serializer when sending stuff between server and client
So basically Json with types?
But what do you mean by serializer? What is seralizing?
> Edit: Why the downvotes?
lol. first time (in a previous post) I thought it was honest/bona fide... my mistake, it's just passive-aggressive and jerkiness disguised as naivety.
All of this just because OP use a beta software (and can't assume this fact), throw a tantrum because maintainers don't reply as quickly he wants, and can't propose anything concrete/actionnable. "Just use superjson" isn't enough, you have to make all the moving parts to work: type system, generated types, load() + page + fetch coupling + adjust the tests and ensure non-regression, etc. etc.
I wish OP to grow up and to experience a real lead or maintainer role in his life. Clueless snarky comments only generate negativity, bad karma and don't help anyone.
I’m not sure that supporting OBjectID is so important
Even if, you must filter out ObjectIds or transform them either on app or DB level. This creates an unnecessary performance hit compared to just leaving them in the serialized/deserialized JSON as strings. And you lose type safety in case you transform them yourself.
Have you actually measured and profiled this performance hit?
Have you tried reaching out to the team on Github?
There's already an ongoing discussion: https://github.com/sveltejs/kit/issues/6008
You don’t have to like Rich’s work to respect what he does. Making a meme insulting a decision he made has to be the most childish thing and invalidates everything you are saying (to a User like me who really doesn’t know the difference of anything being mentioned). I’ll support Rich’s decision, especially since this isn’t a breaking change. Next time, if you’re upset about a change, don’t make a meme of it and pretend like you can do things better. Until you show us your framework and it’s better than SK, your insulting opinions won’t matter.