I gather this is js-bundler, but ideally it would only be loaded once. 9K gzipped per file * bundles == a bit of waste.

Minified I guess it would go down much smaller of course.

It's bootstraping code - js-modules etc.

Not a problem imo (definitely not a bug - we love creating JIRA noise on this project ) as it will be tiny on the wire and is better that each bundle has its own copy of this stuff - I can go into the reasons why if we want. We could minify it .... getting rid of the comments alone would probably get rid of about 700 lines.

Tom FENNELLY ok - currently its 90K (minified would be probably 9K) gzipped, and Ben Walding personally counts every single bit from his servers.

I think he pays by the bit.

OK closing out.

no body likes ben.

9K is the gzipped size of the overhead, x10 resources = 90K.

at least that is what he told me.

Okay .... if Ben says it then I'm sure it's accurate !!

There are tradeoffs here and I'd not be in favour of moving these things outside the bundles. If it's a problem then we need to think of other solutions. I want this bootstrap code to be part of the bundle because it's the one thing that the bundle should be able to rely on to be consistent forever (from the time it was built)

You're lucky this is a public JIRA or I'd tell you what I really thought of your lack of care and respect for the contributing community you have.
</career-of-contributing-to-oss>

I wouldn't take that Mic !!

Ben Walding don't you have a hill climb to ride and get left behind on?

but more seriously, WHEN we have minification, it should only be 1K overhead per bundle max. probably less (given most of it is nice comments). The overhead of an extra round trip for an externalised bundle would swamp that

(and then we get into discussions on asset chains that bundle it all in to main page load, or not, and then http2, or not etc etc).

What we really need: is servers all over the world so we don't have to worry. DONE.

Conside isomorphic-fetch

1139 lines of boiler plate
480 lines of actual code

But you go ahead and mark this WON'T FIX because your operations team will provision an extra 4 servers to deliver all that boilerplate around the world.

You're probably right though, the inefficiency of the boilerplate will be swamped by general inefficiencies in Michael's proof-of-concept code that stays in production for 6 years.

Hypothetically.

Ben Walding its perfectly fine for modules to inline the js they want into their own code, and not have an external bundle at all for small things like that (although it means there are N versions of those objects loaded into the browser, which may or may not be worse), but then there wouldn't be the overhead ratio.

More sensibly...

I agree there's no point optimising away those lines if they're going to be bundled up together later on. In the grand scheme of things - worrying about those extra lines of code/comments at the moment doesn't really matter when there's plenty of other stuff to deal with.

Ultimately you have many avenues for performance enhancement - bundle, deduplicate / minify, compress, cache

Michael Neale

although it means there are N versions of those objects loaded into the browser, which may or may not be worse

It's not a problem when they are all inside their own bundle. Each of those bundles are wrapped in an IIFE, so these things are isolated/scoped inside it.

Ben Walding

In the grand scheme of things - worrying about those extra lines of code/comments at the moment doesn't really matter when there's plenty of other stuff to deal with.

My sentiments exactly ... I'm more than happy to spend time optimising things like this after we have all the bigger fish fried.

BTW ... I've no problem with this ticket being left open. The only point I made was that I didn't consider it to be a "bug" because it's done this way intentionally and for a good reason, but that's just chat.