lee__mason's avatar

js bundling vs seperation big app

im working on a pretty big app that works on the model of freemium, the base app will be simple cms, with extensions for all sorts of things from ecommerce, to newsletter system, support, etc.

Going forward it would be nice to get external contribution, which is key to this question.

im aware the current trend is to bundle up all js using webpack or browserify etc. which i agree is a good way forward, however im not sure how this would work in my case and im hoping someone has had a similar situation before.

consider i have database driven pages, and normal routes like login/register etc. which all have there own js.

should i really be loading a mammoth app.js that contains all vue instances on every page?

or should i just build for example login.js / register.js / theme.js as seperate assests and require them kind of like how wordpress enqueues scripts (to account for dependencies).

or a mixture of both, (for example login.js could require common.js and utils.js, and so could register.js etc)

it seems all methods have advantages/disadvantages

  1. bundled mammoth file is simple, 1 cached asset, but could load huge amounts of js not needed on all pages

  2. seperation of concerns, smaller files but means more http request and requires server side dependency and "enqueuing" per page

  3. advantages of both above, BUT say login.js AND theme.js both require common.js to work, wouldnt this mean common.js is bundled in BOTH files? meaning excess js is loaded?

im more of a php guy but understand js pretty well. personal opinion is option 2 the "wordpressy" way. but dont want to spend alot of time now which needs to be refactored later on.

Its a little different to your standard app as i dont know in advance what parts will be used by the end user as they could use some, or all of the services it offers.

0 likes
0 replies

Please or to participate in this conversation.