Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debloat the library #8

Closed
st-schneider opened this issue Oct 29, 2018 · 8 comments
Closed

Debloat the library #8

st-schneider opened this issue Oct 29, 2018 · 8 comments

Comments

@st-schneider
Copy link

103kb gzipped for simple redundance of localstorage and cookies is pretty unacceptable.
Try to tree shake lodash for example or do it manual via https://www.npmjs.com/search?q=keywords:lodash-modularized

@kr05
Copy link

kr05 commented Oct 29, 2018

I totally agree. I'm excited to use this but as of now it's going way over my performance budget.

@gruns
Copy link
Owner

gruns commented Oct 29, 2018

I agree wholeheartedly; the fat shall be trimmed.

@jcar787
Copy link
Contributor

jcar787 commented Oct 30, 2018

I opened a PR to fix this issue.
https://github.com/gruns/irondb/pull/11

@gruns
Copy link
Owner

gruns commented Oct 31, 2018

IronDB hit the gym: with @jcar787's PR #11, iron-db.min.js bundle size is now
down to 23kB.

More fat remains to be trimmed.

@tsavo-vdb-knott
Copy link

tsavo-vdb-knott commented Oct 31, 2018

Hello everyone !

I have been watching this repo and am currently contemplating using it with rematch for a custom persisted state (there have been issues with redux-persist on android) and I must say that this looks very promising.

I am not sure if this will be of much help - haven't studied the code enough to understand its architecture fully.

-- but that being said --

Perhaps there is a way to prioritize client delivery where say the IronDB LocalStorage Primary mechanism is pushed/delivered as a critical path resource, to the client, and subsequently there after IronDB boots up client side and proceeds to internally Lazy Load its other secondary and tertiary mechanisms/non critical-functionality.

The inspiration comes from a framework-less application that I am currently building - consisting of entirely LitElement and Custom Web Components and the philosophy has lead to very small builds. (our entire app is less than 31K with feature parity ~80% that of Slack)

From a perspective of use case, the only critical functionality that I would need on application boot-up would be "Getting" data from Local Storage for the sake of redux rehydration. Other than that, "Setting" data, data validation, and multiple storages, could be "import(../Non-Critical-Functionality)" after the fact.

Please let me know some thoughts on this idea and maybe there is a way that I can get involved. This is very exciting.

All the best,
-Tsavo

@ecwyne
Copy link

ecwyne commented Oct 31, 2018

https://bundlephobia.com/result?p=iron-db

@gruns
Copy link
Owner

gruns commented Nov 16, 2018

@T-Knott-Mesh I'm afraid I don't understand your question.

Please open a new issue so your question gets proper attention and isn't
mistakenly amalgamated into this issue.

@gruns
Copy link
Owner

gruns commented Nov 16, 2018

IronDB v1.0.0 hit the gym again. I replaced lodash[-es] entirely. Minified
bundle down to 5kB. Minified + gzipped down to 2kB.

Closing this issue; no large, low hanging footprint optimizations remain.

Huge thank you @bm-stschneider, @kr05, @jcar787, and @ecwyne for your input and
help. Don't hesitate to let me know if there's anything else I can do for you.

@gruns gruns closed this as completed Nov 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants