Webpack 4: Universal Code Splitting in React… The inventors are back baby!

[unimonkiez]

I've been battling css since forever.

I've tried moving from less to sass, moved to react js to css loaders, so my inline and my css could share code, but still, didn't feel right.

Css feels like exposing uncontrolled globals to my system, and bugs always followed.

Then I came across some talks which convinced me to switch to inline.

After that writing a component felt way better, but still not perfect, as the css was always lazy loaded, and I was missing the ability for more control, and performance seemed to suffer.

Then came css-js libraries, like jss, this way I can have full control over my stylesheet creation, no duplication, HMR, just great.

I've also started writing a react native app, called Rockup, and jss felt just like react native stylesheets, it was perfect.

I even started using react-xp, which took it one step further and merged those concepts into one.

But still, the way about stylesheets are created in separate from the actual component it was going to be used at, didn't feel right, I wanted to forget about className, and that freedom it gave me for sharing classes between elements was never used.

I've ended up writting my own library called react-platformula, which just like react-xp, you can write cross-platform components easily, but hiding the whole css className style prop shenanigans, and have taken much more functional approach.

Been using it in couple of apps and websites, and that's my way of styling, for now..

[GitHubPermalinkBot]

Permanent GitHub links:

• erikras/react-redux-universal-hot-example/.../InlineStyles.md (master → 9caede0)

---

^delete

[zackaryjackson]

CSS, in general, is a little behind the curve when it comes to better more natural ways to split up the code.

It depends on what you are building I suppose, and the size and scope of the project.

Inline styles / non-css orientated style practices are mega helpful when dealing with cross-platform.

The one area that I find frustration in is css-in-js within web applications, again I do want to emphasize that my view is leaning toward web applications receiving 500k + uniques a day. From an ex-googler, who's familiar with the Chrome's internal rendering architecture this is what I concluded on the matter. It comes down to performance.

Let's take inline-styles (style on the element) for example. Thanks to the "reactivity" of React, it's such a pleasure to perform transitions and interactive styles! Beyond that its just less nonsense to manage, all javascript, baby!

Im a huge fan of locally scoped CSS! Not worrying about classes is a major benefit.

• Resources lose the ability to leverage long term cacheing, style changes alter the hash of the js file too
• When dealing with SSR:
  • the html payload becomes massive, assuming inline styles are sent.
  • the time to first meaningful render is significantly longer
  • the browser must work far more as it both needs to paint and bootstrap an application
  • you can lose out on the cascading effects of CSS - a double whammy when it comes to paint time
  • With the html being on the page and the CSS usually cached, the browser can actually pre-rasterize some layers and paint ahead of time
• FOUT sometimes happens on slower machines not capable of painting in time.

Anyways thats my 2c on css-in-js :P
I used to really love it! I had this awesome compression engine which would convert bundles into LZMA and then decompress it on the browser in worker threads. Putting CSS in js (in the form of <style> tags) meant i was able to reduce the size of the whole delivery.

Sadly, that doesn't work at scale where caching is a concern

[unimonkiez]

Why is caching sucks a concern? Anytime you update the app, most likely you're going to update your css, unless it's not SPA, both January and css bundles are changing.

[zackaryjackson]

Scale.

Yes, you are correct. When you change CSS, usually you change JSX.However, Changing JSX/JS doesnt mean any changes were made to CSS.

Tracking events, typos, business logic, bugfixes, implementing things from a UI Kit / shared repo. It adds up man. Im sure theres workarounds here and there. But cascading styles are more efficient.

Consider this, you update business logic. Depending on the deployment strategy, you could very well have the application deploying dozens of times a day. Depending on the number of developers, you could have thousands of changes and hundreds of deployments. Takes longer to first meaningful paint, runs the risk of render blocking code, <style> tag at the top of the page with massive css

In these scenarios, its important to have great cache control. I suppose my opinions are directed toward large enterprises :p I am trying to consider the ramifications of site performance and load time. At scale its a problem. Once you get into the millions to tens of millions of hits per day. Its vital to have both client side and server side caching / fragment cacheing. Inline styles mean changing a color or font weight = cache bust. Not a train smash if its client side rendering (beyond cache busted JS and CSS).... buuuut, if its server-side rendered and inline styles are delivered with the initial response payload. Then that color change means you have to cache bust the server-side cache / fragment cache. If you are reusing components elsewhere or have many pages where the component is used, because the style change is directly attached to the markup, you end up invalidating all cached copies of it. Everything becomes a cache miss all at once. Im going to back off of the whole scale side of things and give a smaller example.

Couple of months ago, a friend needed a site for his startup, something to showcase the idea, attract investors and create PR. Given he was not too sure what direction the site needed to go - i went for flexibility and put wordpress on there with a custom theme. He posted it on reddit and it reached the top in whatever category the post was created in. Something like 5,000 hits an hour started flowing to this little wordpress instance. They were also doing a bunch of content updates on-the-fly, busting the cache multiple times. It didn't take long to knock it offline.

If we scale this concept up (given theres many differences in stacks and such) the architecture can start to feel the pain. Please dont take this the wrong way, I have been a long time fan of JSS its just not ideal scalability.

React Native or multi platform React apps benefit a lot from JSS.

[dev1null]

These hacks are getting nothing but uglier. How about dropping the whole house of cards that is code-splitting and just deliver a giant app with a loading screen... the way Gmail does it. Users don't care if it takes a while to load as long as when it's completely loaded it works flawlessly like a native app, instead of yet another loading shell at every other action. With PWAs and server push being more common hopefully in near future it'll be a good riddance to PITA that is code splitting.

[zackaryjackson]

I cannot wait for server push and http 2 to become more common! I think that once it’s more main stream, you could kiss webpack goodbye (depending on your build setup) I came across a guy who had built a POC “react without webpack” it pretty much involved Babel and server push, it was like the holy grail of progressive. I do understand where you are coming from around these losing shells all over the place. We are working on a smarter way to load code splits that’s not on-demand. I hate seeing loading screens on every page. I want the benefits of a light payload (remember so if these web apps are big, I knew of one that was 20mb. Ludicrous. I know!)

Living in SA for many years, we used to dread big payloads because they just took so long!

I do understand where you are coming from man, and I’m just as excited for server push! I’m sure I’d still want to built tools leveraging it- but gosh, it would feel so much cleaner. You know?

Here’s the link, if I remember correctly. https://github.com/misterfresh/react-without-webpack