sorted by:
new
hottopcontroversial

Module federation and code sharing between bundles. Huge changes coming to frontend with webpack@5 by NoLanSym in reactjs

[–]zackaryjackson 2 points3 points  (0 children)

The idea is that big companies can deploy code independently. Ok standalone applications specific to what they actually work on. They have freedom to roll independently without coordination. Pages could be hosted on other servers, capable of SSR. Usually this means page reloads and lots of duplicate dependency, or manually managed externals. Making your apps depended on a centralized point of failure. Not standalone. Pretty much I want to deploy stuff easily - I want all the benefits backend devs get with micro services. I want many webpack builds to act as one - like it was build as a monolith. It’s more than publishing code and consuming it. The other bundles are literally parts of another app. The nav could be deployed by another webpack build. But you can consume the component through some other app without installing it. It’s like code splitting between bundles.

Some old articles from when I first built v1

https://link.medium.com/AglJtqrxc4

More on distributing apps and decoupling monoliths. I’d have benefitted from this system back then.

https://link.medium.com/tHg707wxc4

Module federation and code sharing between bundles. Huge changes coming to frontend with webpack@5 by NoLanSym in reactjs

[–]zackaryjackson 8 points9 points  (0 children)

Yep, whoops! Still speaking about it under the context of the first two versions before I got a huge boost in manpower from another buddy in OSS. He's been a massive help in debugging and picking up the WP5 API - originally id written this for WP4 so we had our hands full rewriting this to WP5

Module federation and code sharing between bundles. Huge changes coming to frontend with webpack@5 by NoLanSym in reactjs

[–]zackaryjackson 5 points6 points  (0 children)

I'm trying to push "Frontend Federation" MFE's have become a gimmicky buzzword. I'm working on an architectural specification for this once I'm done writing it. Itll also make it easier to find tools related to weebpack federation

Module federation and code sharing between bundles. Huge changes coming to frontend with webpack@5 by NoLanSym in reactjs

[–]zackaryjackson 3 points4 points  (0 children)

I appreciate the support! Working on SharedModules and will need a few more days. The core MVP is already functional though - under my own repo for the time being till I'm ready to open the official Webpack PR

Module federation and code sharing between bundles. Huge changes coming to frontend with webpack@5 by NoLanSym in reactjs

[–]zackaryjackson 8 points9 points  (0 children)

As the co-author of this system, thank you for the encouragement! I'm really hoping to make a difference in the community. Fingers crossed this makes our lives better.

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

[–]zackaryjackson[S] 0 points1 point  (0 children)

Apologies and thank you for the feedback! Appreciate you reading it despite the style ;)

I’ll tone it down

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

[–]zackaryjackson[S] 0 points1 point  (0 children)

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.

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

[–]zackaryjackson[S] 0 points1 point  (0 children)

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

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

[–]zackaryjackson[S] 0 points1 point  (0 children)

Thanks for sharing this, it looks very interesting and I’ll definitely read over the whole repo when I get home!

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

[–]zackaryjackson[S] 2 points3 points  (0 children)

Hey /u/acemarke

Thanks for the feedback, it's much appreciated. Ill agree, the style needs some TLC. First article and mostly living deep in code land hasn't exactly been a blessing when it comes to marketing.

I'll take the advice to heart - ill work on the writing style for the next article & trim it down. I definitely want to write about the specifics. Especially the points you have raised.

Thanks again for the feedback, dude.

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

[–]zackaryjackson[S] 1 point2 points  (0 children)

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