search

ctrlplusb / react-async-component

Resolve components asynchronously, with support for code splitting and advanced server side rendering use cases.
MIT License
1.45k stars 62 forks source link

Comparison with react-loadable #37

Closed oyeanuj closed 6 years ago

oyeanuj commented 7 years ago

Hey @ctrlplusb, this library is great!

But I know when react-loadable launched, you'd considered merging the projects. Wondering if that it still on the cards? And if not, how do you compare the two libraries (pros/cons)?

Any tips in helping make that decision are much appreciated 😃

faceyspacey commented 7 years ago

This will likely help:

https://medium.com/@faceyspacey/code-cracked-for-code-splitting-ssr-in-reactlandia-react-loadable-webpack-flush-chunks-and-1a6b0112a8b8

tarr11 commented 6 years ago

That article seemed to be about some other components (that seem to encompass react-async-component and other stuff), not about react-async-component specifically. Would still like to see a more detailed comparison with react-loadable

Many devs unfortunately judge by stars and commit dates, so explaining why this is superior would be very helpful

Comparison with https://github.com/smooth-code/loadable-components would also be helpful.

ctrlplusb commented 6 years ago

On face value they all have similarities, especially when dealing with client side only. However, I personally find that the real distinction between each solution becomes apparent when you are trying to execute server side rendering.

I haven't dived into each of them enough to give you an honest side by side comparison, however, I can say that with this library I fundamentally wanted to avoid having to configure a bunch of babel/webpack plugins when trying to do SSR.

I wanted a simple JS-only solution that would naturally work with the code splitting APIs that Webpack et al provide. To achieve this I had to lean on my react-tree-walker library which essentially walks the react element tree (js object) that describes your react application and then resolves the code split bundles in preparation for a server side render or client side rehydrate.

This probably adds a slight overhead compared to other solutions that use babel/webpack code replacement magic. I would be really surprised if the overhead was anything significant though, and there is even this article that describes some of the speed gains they got when using this library. You'll also find some additional comments at the bottom of this article that discuss the various libraries.

My hope is by keeping my API "native" JS and not requiring anything too magical with babel/webpack this library will naturally evolve to be able to use any natural dynamic import code that may be coming to servers/browsers.

If the above sounds like something that you would also appreciate then maybe this library is for you. However, if you want absolute blazing perf without any JS overhead for your server side renders then perhaps one of the other options is better for you. I would invite you to do your own research and find out which solution works best for you. ✌️

geyang commented 6 years ago

yeah this one is awesome. I compared it with lyft/universal-async-component and this one won. Thanks for the library!

michaelBenin commented 6 years ago

Totally sold on:

My hope is by keeping my API "native" JS and not requiring anything too magical with babel/webpack

Well, that and this project you can actually open issues on.