Size comparison with react-use

[o-alexandrov]

If you compare react-hookz/web with react-use on BundlePhobia (click the library names to open BundlePhobia).

Then, if you look at individual imports, you will see the majority of hooks increased in size, some of them are twice bigger in this library.

I haven't analyzed the reasons, but one possibility is:

• react-use hooks don't support SSR most of the time, whereas react-hookz/web seems to attempt to support SSR

For most of the users, supporting SSR is actually useless (because they don't do server-side rendering) and, therefore, harmful based on this library's increased size.
Please consider to come up with a way to have an ability to remove SSR support with dead code removal:

• for example, by wrapping SSR-related logic in an imaginary process.env.SSR environment variable, so the users could remove it by assigning false during the build time.

EDIT:

• SSR related logic is treeshakeable in @react-hookz/web if the following text is replaced during the build-time with "object" string
  • typeof window
  • typeof navigator
  • typeof document

[xobotyi]

And its not🙃
SSR compatibility, in most cases, is just 2-3 extra clauses, nothing more.

The reason is difference in features and optimisations. I think i can squeeze some bytes from the files, but it wont be a drastic change. react-hookz reuses more own hooks than react-use

[o-alexandrov]

actually, after thinking about it.
please ignore everything on SSR I mentioned here, I will just replace:

• typeof window
• typeof navigator
• and typeof document

with "object" during the build-time and the dead code removal in this library would work for my usecase

[xobotyi]

if you use Terser's playground

Obviously not everyone use terser.

But, I was probably unclear. Even those, who do use SSR would benefit from the process.env.SSR, as when they build for SSR, they could remove all browser-related code.

AFAIK, SSR uses the same bundle for server side and for client side, thats the point of this technology (or i'm missing something).

But to be clear, those async operations happen so quickly, what you are telling is:

• network state would change, when the component is being unmounted
  Sounds unreasonable, doesn't it?

It does not, it seems that you dont count slow devices and the murphy's law😑

[o-alexandrov]

AFAIK, SSR uses the same bundle for server side and for client side, thats the point of this technology (or i'm missing something).

No, not always. Some bundle for the SSR separately, removing unused parts to minimize memory consumption and improve performance.

• even if I did it, then there are many others who do it also

Thank you for the discussion. I ended up improving the processing of @react-hookz/web for my use case. (modified original message at the top.)

[xobotyi]

So what the savings are? Guess something around 100 bytes ungzipped (but minified, ofc) 🤔

[o-alexandrov]

Down 1 gripped KB in the minified code (without comments).
From 250 to 249 gzipped KB.

1KB is 30% of preact :D
But the size reduction is also based on other libraries that depend on window and related checks.