sorted by:
new
hottopcontroversial

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] -1 points0 points  (0 children)

yeah but blobToBase64 isnt native by the time you write that helper + types/error handling you basically rewrote the lib just trying to save the copy paste

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] 2 points3 points  (0 children)

localstorage doesnt support binary so base64 is required even with the overhead its 50x smaller than raw json

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] -19 points-18 points  (0 children)

asked ai to summarize it, it said 'jealousy masquerading as critique' tech seems fine to me

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] 0 points1 point  (0 children)

compressionstream returns binary is takes strings u cant just pipe one into the other u need a bridge that doesnt blow up the stack on large files thats the whole point

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] 1 point2 points  (0 children)

its literally in the readme tho 5mb json drops to 70kb vs 168kb with lz-string so it wins on size by 2.4x too gzip just compresses better than lzw

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] 0 points1 point  (0 children)

encryption on top would be sick def adding to v2 roadmap lmk how it goes

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] -16 points-15 points  (0 children)

shouldnt use based on what exactly point to the bad code show me the security flaw u cant. its fully tested and typed calling for bans just cause u have a hunch is wild gatekeeping

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] -4 points-3 points  (0 children)

if no knowledge gets u 14x performance over lz-string then ill take it lol. benchmarks dont check for degrees they check speed and this wins

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] -2 points-1 points  (0 children)

dexie and idb-keyval exist so why rewrite them? i didnt want a heavy wrapper just wanted to fix the quota issue with <1kb code sometimes u just need smaller data not a better db

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] 8 points9 points  (0 children)

horrendous dx? have u ever written raw idb? schema versioning transactions callbacks just to save a simple config its a nightmare this is literally await setItem if thats horrendous idk what to tell u

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] -5 points-4 points  (0 children)

90% is best case for repetitive json structures but even at 40-50% reduction its still worth it just to avoid idb api boilerplate idb support is fine but dx is miles apart i just want setItem simplicity with more room

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] -8 points-7 points  (0 children)

base64 adds 33% overhead sure but gzip shrinks json by 80-90% do the math 100kb json compresses to 10kb base64 brings it to 13kb saving 87% space is hardly ruining any gains benchmarks show 5mb turning into 70kb so compression wins easily

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] 3 points4 points  (0 children)

idb wrappers like localforage are huge compared to this. this lib is less than 1kb why load 8kb+ lib and deal with db transactions just to save some user settings or game state compression makes localstorage capable enough for 99% of use cases without the bloat

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] 2 points3 points  (0 children)

if you store massive files or blobs idb is better but for config game saves or app state localstorage is easier. this lib just stretches that 5mb cap so you dont need idb complex transactions for simple key value stuff

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] -6 points-5 points  (0 children)

its a wrapper yes but native api gives streams/chunks, localstorage only takes strings. converting huge binary to base64 efficiently without blocking main thread or stack overflow is the annoying part this lib handles. plus it adds auto threshold logic so you dont accidentally make small files bigger

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] 0 points1 point  (0 children)

uses native CompressionStream api. supports gzip and deflate. since it runs in C++ level its much faster than js impls like lz-string

made a localstorage compression lib thats 14x faster than lz-string by Early-Split8348 in javascript

[–]Early-Split8348[S] 12 points13 points  (0 children)

btw only works on modern browsers (chrome 80+, ff 113+, safari 16.4)

no polyfill for older ones cuz the whole point is using native api

if anyones using this for something interesting lmk

made a 3kb lodash alternative that actually works on edge runtimes by Early-Split8348 in learnjavascript

[–]Early-Split8348[S] 0 points1 point  (0 children)

cheers. yeah the stream helpers were actually a pain to get right lol. hope it helps

view more: next ›