<div dir="ltr">Seemed a shame this email didn't get any discussion as I think it's an interesting topic. Hoping by biting, I can ignite some conversation here ;)<div><br></div><div>So from what I understand ResourceLoader was a bit of a trailblazer in this field and we created it way before any of these bundling tools exist.</div><div><br><div>From what I can see webpack and many other bundlers now have good solutions that mirror ResourceLoader's functionality, for example including CSS/templates  inside JS files. From my understand of webpacking if you need to care about i18n you need a bundle for every language? I guess this is something ResourceLoader arguably does a little better/more convenient - as the compile is handled on first request, not as a build step.</div><div><br></div><div>One thing I don't like about ResourceLoader over other bundlers is the inability to import files a la Node (<a href="https://phabricator.wikimedia.org/T133462">https://phabricator.wikimedia.org/T133462</a>).</div><div><br></div><div>When I built Weekapedia [1] (MobileFrontend rebuilt as a web app), most of my friction came from the i18n challenges - I had to generate a RTL css stylesheet and manage the logic for switching between versions. I don't think this is because it's hard to do in Webpack - I just think there's a big paradigm switch in that you now have to worry about how your tooling solves this. How do you ship the bare minimum message keys? There might be tooling I'm not aware of, tooling we could improve or tooling we could write with ResourceLoader as the basis of inspiration.</div><div><br></div><div>I actually think it would be a really interesting POC to see what this would look like. If nothing else, I think it would be good to talk about the problems it solves on <a href="https://www.mediawiki.org/wiki/ResourceLoader">https://www.mediawiki.org/wiki/ResourceLoader</a> so others understand it. I have noticed many frontend devs who are new to our ecosystem spend a lot of time getting there head around why we use ResourceLoader and I think it would be great to document. This might be a good spring board for packaging ResourceLoader up as a composer module that other PHP based projects can use....?</div><div><br></div><div>[1] <a href="https://github.com/jdlrobson/weekipedia">https://github.com/jdlrobson/weekipedia</a></div><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, May 2, 2017 at 8:43 AM Joaquin Oltra Hernandez <<a href="mailto:jhernandez@wikimedia.org">jhernandez@wikimedia.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I read this article where a twitter engineer explains their migration from their custom made front-end bundling tooling to use webpack, with the good and the bad they found along the way, and it seemed interesting enough to share.</div><div><br></div><div><a href="https://alunny.com/articles/webpack-on-twitter-com/" style="font-size:16.25px" target="_blank">https://alunny.com/articles/webpack-on-twitter-com/</a><br></div><div><br></div><div>I was wondering, would a move like that be worth or even possible for MediaWiki?</div><div><br></div><div>I thought it could be interesting to chat about the specifics of our ecosystem in the context of this sort of tooling migration.</div></div>
_______________________________________________<br>
Engineering mailing list<br>
<a href="mailto:Engineering@lists.wikimedia.org" target="_blank">Engineering@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/engineering" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/engineering</a><br>
</blockquote></div>