We love telling stories behind the daily challenges we face and how we solve them. But we also love hearing about the insights, experiences and the lessons learned by prominent voices in the global community.
In this new series of 1-on-1 interviews, our very own Wix Engineers talk directly with some of the most inspiring minds in the tech industry. From software engineering to architecture, open source, and personal growth.
In the first article in this series Natan Silnitsky sat down with Martin Kleppmann, check out that conversation here.
This time we’re happy to share with you a conversation between Wix’s front end engineer Gil Eckstein and the mind behind Loadable Components library, Greg Bergé.
Although quite often these conversations follow an interview format, sticking to a question - answer pattern, this one did not. A true deep discussion on the state of Loadable Components, the Reach ecosystem and where Webpack development might be headed in the future, and much more.
And spoiler alert - Gil spilled the beans on the use cases in Wix for loadable components and how it helped us solve one big problem only to create a new one!
Without further adieu, below is a collection of excerpts from the conversation between Gil and Greg - you can watch the full talk here. We hope you enjoy it as much as we did!
Gil: Did you start working on open source projects a long time ago?
Greg: Since I was a young developer, I was publishing my scripts. Since, maybe, my first script.
I was publishing things like solutions to the Pythagorean Theorem and things like that when I was very young, 12 or so. You can say I started to open source very early - GitHub didn’t exist yet and I was publishing things on a small network, one of the predecessors to GitHub.
When I discovered GitHub, I started to create more open source projects - like “shipit” - it was a thing to deploy applications. Not like we deploy today, of course, because there’s Kubernetes and everything. At the start it was like Capistrano but for JavaScript. And, well, after I discovered React, I started to publish things around React.
And about Loadable Components specifically, I found that the problem of doing SSR and loading components asynchronously wasn’t solved.
Gil: Dynamic loading, right.
Greg: Yes, dynamic import in SSR wasn’t solved. It is now with Next.js, but if you don’t use Next or Gatsby, it is not solved. Basically the only solution today to make it work is Loadable Components. So that’s why I started it - because it wasn’t solved.
Gil: You had a use case in one of your applications that made you think about this problem, right?
Greg: Yes. I had SSR in my React application and I wanted to do code splitting. So I had to solve it. There was React Loadable, but it wasn’t maintained and it didn’t solve the problem completely, so I decided to create Loadable Components.
Gil: Let me tell you a bit more about our use case for Loadable Components. So we’ve got many applications in Wix - we work with a platform where we load all these applications, all the React components, and then we render them. And obviously we also do SSR. The problem with our application was that in a lot of use cases users could configure those applications.
For example, let’s look at our e-commerce application. Users can configure if they want to, say, display the comments widget on the product page or not. Which is controlled via the settings panel in the Wix editor. And so in cases like that if we needed the application to render the comments widget in SSR, we couldn’t dynamically load it depending on the user’s choice. Everything had to be downloaded and the decision - to show or not to show - had to only be made on runtime.
This was an issue for us because the bundle size of applications like that became very large - because we had to bundle all the different products, no matter the user’s choice of having or not having them show up on their website.
One obvious workaround was to only show it on the client side. But then in some use cases we had to do the server-side rendering of those components, and then we couldn’t do it - so everything had to be bundled still.
Greg: Yeah, that’s a good use case.
Gil: We had many discussions about the approaches to solving this. One possible solution was to split the one bundle into multiple bundles. For example, you have the desktop and the mobile versions - so we thought that maybe they can be exported separately and then we could load each one in each environment, but… You have so many permutations of use cases!
We thought about this for a little bit, but then decided to drop the idea. There were just too many bundles to export, and then the build time would take longer, and it would be hard for the developer to create those bundles… So we dropped it. And then we saw Loadable Components and we thought, “wow, this is exactly what we need!”...
Now, the Loadable Components library is very coupled with Webpack. Do you think that it's thus going to be harder to maintain the project, to keep up the upgrades? I know that Webpack 5 just released lately - do you think it’s making it harder?
Greg: Yes, Loadable Complements is coupled to Webpack - but we don’t have a choice, really, to do it in any other way to solve this problem… Webpack evolves slowly, so it’s not really a problem though. Webpack is the most used bundler so it’s not really a problem, again. But, yeah, it should not be coupled to Webpack - but to be able to not couple it to Webpack, we need some API on the import to get some information. We need specification - and the specification is not yet ready. It evolves, because you have import everywhere, including in Node now, so it’s going in a good way. That’s also why, I think, the React team didn’t solve this problem - because they didn’t want to couple React and Webpack.
Gil: I really hope, like you said, that Webpack will expose the APIs. So at least they will have to, you know, support those APIs. For example, if they expose the registry, then it will be easier to get the registry of the chunks from an API and not from, you know, something internal. Which will, probably, make it easier with upgrades, with documentation exports... I hope they do it.
We are now starting to use module federation - have you heard about module federation in Webpack 5?
Greg: Yes, I heard about it. I haven’t had a chance to use it yet, but yes, I’ve heard about it. I don’t know if it really solves the problem.
Gil: We use it for a different use case - we use it to share code between applications. Say you have two runtimes, they bundle each one with their own Webpack, but then some code is shared.
Greg: The promise here is to be able to share code between applications in the same project, but also in all the projects on the web. If you need to load React, you shouldn’t have to bundle it in every website, you could just download the same version of React across the whole web.
Gil: Exactly... What’s funny about module federation is that to use it you have to use internal Webpack variables. I’m sure they’ll fix it, they will make the API better. And I hope that once they do it they will also fix the other APIs. And the more applications use it, the better the documentation will become.
I also wanted to ask you if you ever heard about ESBuild? We started to investigate ESbuild because we had some problems with slow builds in Webpack - and we heard that ESBuild is very fast, have you heard about it?
Greg: I’ve heard about it, but didn’t have a chance to use it. I gave it a look though. ESBuild is a very fast way to build JavaScript from REST Modules. But ESBuild is not really a bundler. Maybe it will become one, but I think it’s not their DNA. That’s why there is VGS and VGS is a bundler that uses ESBuild - but VGS takes care of everything, like CSS and everything that is not JavaScript but that’s needed to create a rich application.
So maybe VGS could replace Webpack, but ESBuild itself cannot. It could replace Babel as Babel is often the slow part of Webpack in an application. There’s already a loader available, but today there are a lot of things - like Loadable Components - that rely on the Babel ecosystem. So it’s complicated to use ESBuild inside Webpack, inside the React ecosystem. Because since the beginning we have been using Babel and everything is coupled with Babel, you know? Like the state component or emotion, everything has a Babel plugin to transform code before it is bundled...
So ESBuild is a good thing, but it will take time before it’s able to replace the actual ecosystem. Maybe in a new application, if we start with ESBuild or VGS, that kind of ecosystem... I think it’s a good move for a new project - because it’s faster and it’s obviously better. Because although the problem at hand was solved by Webpack, Webpack is now in version 5 and although it needs to evolve, they can’t really make breaking changes. The alternative is built for the web of today and with the ES module in mind that’s the default now, Webpack has to support everything - AMD and CommonJS. So it’s faster because they reduced the gap by supporting just what is needed.
I don’t think ESBuild is really fast because it’s written in GO. It could also be fast in JavaScript, but when Webpack was designed, the speed was not one of the considerations, that’s why it’s slow - because we wanted things that work and at the time the applications were much smaller and the speed was not a problem. Today it is.
Gil: Do you think they will work on the speed in future releases? Because I think they will, since the alternatives that come up right now will force them to. For instance, I saw a lot of people use ESBuild because of speed.
Greg: I don’t know, really. But maybe it will be similar to something that happened to npm when yarn came along. You know, npm was very slow and yarn came along and said ‘OK, we are the speed!’. And now npm and yarn are both the same speed pretty much.
Although that would really depend on who’s maintaining Webpack and if they really have the money or the interest to do it. Webpack is not a company - so it’s not like npm and yarn.
Gil: There’s this one other use case that we have for the Loadable Components I wanted to mention in this context. Inside any Wix website you have access to a rich text editor, which you can use to, say, write a blog post and add to it various features like video or images, a photo gallery, or any number of things you get via plugins. And so, like we talked earlier, one of the issues was that we couldn’t dynamically load those plugins - we had to bundle everything, so the bundle was huge. And then Loadable Components solved that for us by only loading the plugins that were actually needed.
So that’s all swell and great, but now the new issue we encountered is having too many network requests. Because now if you have many plugins, you have many network requests instead of one big one.
The way we’re trying to solve that now is by working with BI to try and see which network requests always go together and then bundle those together with Webpack cacheGroups - so that we could bundle together chunks.
Greg: Well, if you just name the chunk they should be in the same JavaScript bundle and that should solve it. But you have more advanced options in Webpack to solve this problem.
Gil: This is a kind of a problem that you start having after you fix one thing and then you get another one. But those are smaller problems. We see that the performance has definitely improved, but now we’re trying to see if it can do even better.
Greg: I think this could be solved with just the Magic Webpack Commands maybe? Gil: Yes, but we don’t want the code that makes the decision about which bundle to put together to be in the source code. The configuration is a good place to try and play with different bundles, different chunks together. You know, we just change the configuration, we push it, and then see if that affects the performance.
Greg: You should maybe take a look at the Next.js source code - because they have configured that with the help of Google and Webpack and everything. And maybe they have a good default. Although maybe not suitable for your use case. Gil: Well, that’s definitely a good idea… I wanted to ask you about future plans that you might have when it comes to Loadable Components or for other projects that are related to this area.
Greg: Recently Dan Abramov asked me about the internals of Loadable Components, so I hope that React will take the problem and solve it, now that they have incremental iteration and hydration and things like that. So, I think that they are working on it. And for now with Loadable Components - we’re just maintaining it, but we don’t really push features to it because today there’s Next.js and Gatsby and those mainly solve other kinds of problems.
Gil: Do you know how Next.js solved the SSR and dynamic imports?
Greg: Well, in about the same way Loadable Components did, but bundled in their project. It’s the same idea.
That’s also why they bundle their router - because to be able to solve this in Next.js you have to use their router, which allows them to track everything. It is the same thing, but they collaborate with the React team - so I think it will eventually be solved by React. Because React also submitted something to create a kind of specification on import to be able to implement those things. It was a long time ago when I saw that, maybe two years ago...
Gil: I saw the server components by React, so maybe the server components can…
Greg: Maybe, yes. They have server components and React lazy and the SSR that needs to spot React lazy and suspense and everything. So they have to solve it in React now... The problem is coupling with Webpack, but they have a strong motivation to solve this.
Gil: So do you think that their solution will not be tied to Webpack, they will do something else? Greg: Yes, I don’t think they will couple it with Webpack. If they implement it, they will most likely rely on the official spec in the import system to not use Webpack internals. And then they will collaborate with Webpack to implement these things for the community to be able to use it. Because if the Webpack team doesn't follow suit, it will never happen.
Gil: I know that the main maintainer of Webpack recently joined Next.js, so everything is together now. So they can probably talk about everything together now. Switching gears a bit, I wanted to also ask you what you thought was the biggest challenge around the open source projects you maintained? Like maintaining open source projects with many users.
Greg: The biggest challenge is to maintain a project that you don’t use - because when I developed Loadable Components, I was using it, so it was kind of easy. Now I don’t use it because I work at Le Monde as lead developer and we don't really need SSR, Loadable Components is not required.
So I don’t use it - and maintaining something that you don’t use is very complicated. Except maybe if you are paid for that, but I’m not. Since the beginning I got in total maybe $300 in donations, not more, from Loadable Components.
If I work just one day as a freelancer that’s better than all of the donations I have gotten in its entire history for Loadable Components. And Loadable Components is much more work than a day of freelance, so…
I’m not working on it currently, but I have a friend who’s maintaining it, Anton Korzunov. He created a similar library to do the same thing - and then asked me to be the maintainer on Loadable Components because it just had more traction. And he’s very interested in the problem and also works on React Hot Loader, although that’s now solved by React. In any case I’m glad he could maintain it.
Gil: We’re actually in the migration phase, so some of the applications already use it... I think once they see the big value of cutting the bundle size more and more, Wix will also start using it very soon. We’ll for sure help you with anything we can, you know, with fixing, finding bugs and reporting and things like that - because we'll be using it a lot very soon.
It was great to have you with us, it was a really interesting talk. Thank you very much for this!
Greg: Thank you!
Bio - Greg Bergé: When Greg was 12 years old, he created a gaming website which after a few months grew big enough to be sold to a company. A lead engineer at Le Monde (1st french newspaper), he's currently helping build their CMS.
Greg was also a founding member of Doctolib, the first medical booking software in Europe. In 2017, he founded Smooth Code, a software development studio, to help startups like Payfit, Scaleway, and Welcome to the Jungle grow. Over the years, he became passionate with open source software and with sharing with others, be it from behind the screen of his computer, or as a speaker at conferences.
His open source projects are trusted by thousands of developers worldwide. Greg is also very active in the training field as he has given workshops to more than 400 developers in companies such as SNCF, Alan, and Mappy.
For more engineering updates and insights:
Join our Telegram channel
Visit us on GitHub
Subscribe to our YouTube channel