bundlejs VS hammer

Package Size Checker

I was closing out some long lived issues over on bundlejs, when issue #50 reminded me of the ongoing debate about how bundlejs should handle the ESM and CJS packages.

Still, I'm not really sure about its dependencies: it lists react and @tanstack/react-query (as opposed to @tanstack/query-core) and bundlejs reports 124KB gzipped. Also, while using it, you still need to refer to their react docs (that documentation is really good and has a lot of examples) but not everyone will be thrilled about checking a react documentation when they're using an angular package.

It's somewhere in between.

React as a lib and architecture _is_ platform-agnostic. The core logic is defined in the `react-reconciler` package. It contains all the implementation of rendering components, diffing trees, managing state, and running effects, as well as all the "Suspense" implementation.

However, the way `react-reconciler` works is that it's built _into_ each platform-specific renderer implementation. So, the size of `react-dom` is actually the size of `react-reconciler` + all the DOM-specific behavior.

A quick check of https://bundlejs.com/?q=react-reconciler suggests it's about 100K minified. https://bundlejs.com/?q=react-dom is 138K, so that tells me that the DOM-specific logic is 38K.

React Hook Form has no dependencies and a small bundle size. It has a gzipped bundle size of 12.12KB, according to bundlejs.

These are shameless plugs, but https://bundlejs.com and https://inthistweet.app. I built both tools specifically because I didn't find any other tools that solved the problems I kept running into.

Try https://bundlejs.com/ to see

bundlejs (pronounced bundle js) is a quick and easy way to treeshake, bundle, minify, and compress (in either gzip or brotli) your typescript, javascript, jsx and npm projects, while receiving the total bundles' file size.

Don't know of any but was going thru Adam Wathan's twits and replies. Found, https://github.com/okikio/bundle Looks medium sized.

NX repositories build slower, drop 1000's of dependencies in your project and has configurations so verbose you need vscode plugins to drive it (also I didn't like that I had to drop in project scaffolding templates to provision new library or application types). I disliked using it so much I went ahead and built this thing https://github.com/sinclairzx81/hammer.

My development workflow is principally based on https://github.com/sinclairzx81/hammer which is esbuild tooling I wrote myself. I think these days, if you're using TS and want the rapid development workflow, anything that is leveraging esbuild or swc under the hood will be a good thing to pick. So Vite ticks the esbuild box.

I use https://github.com/sinclairzx81/hammer. It provides watch / reload workflows for both node and browser development and it scales from single applications into large mono repository projects. It takes one dependency (esbuild) and needs next to no configuration to use.

I gave up on community build tooling and ended up rolling my own tools. https://github.com/sinclairzx81/hammer. It's difficult to find any tooling in the community that does all the things you may need it to. I found by investing the time into developing tools to align to my workflows, I'm free to modify those tools without getting bogged down in ecosystem plugins, or arcane configurations, or whatever else.

If you just want to get going, you can try https://github.com/sinclairzx81/hammer, (disclaimer I wrote this), or https://parceljs.org/ . Both are zero configuration and will allow you to add in frameworks as you need them (rather than relying on the kitchen sink project bootstrappers like create-react-app).