We used to have one big monolithic bundle, which worked fine, but it included a lot of code for hidden paths that usually would never be loaded for most users, so I decided to use dynamic loads for each route, a la const ScreenA = await import('./ScreenA'), for all top-level routes. That worked and was painless, but now all modules are being loaded async, not just in dev mode, but also in production builds. That was unintended. I hoped Vite would just split the bundles per route.
Is there any way I can relatively painfree bundle all the tiny modules up into bigger bundles?
Related
I've run into a problem that I'm sure many new/junior web developers are facing. Before I state the problem, it's best if I first list the events that drove me to the "issue".
Step 1 - The Front-End:
I followed tutorials which allowed me to create a Vue project using the vue-cli - I now have a nice front-end ready to go, albeit it is in a way "standalone". It sits in its own directory.
Step 2 - The Back-End:
I move on, I start to look at the back-end. Laravel plays well with Vue so I go with it. Once again I follow tutorials, I create a database and an API. Fantastic.
I now have the barebones core elements for a CRUD application. However, the way the back and front end are connected seems to be convoluted (although this may be due to my inexperience and improper understanding).
Solution 1:
Some tutorials insist that the Vue project is "re-created" within the Laravel directories so Laravel is in charge of rendering the views.
Solution 2:
Others, from what I can tell keep them physically separate and have the front-end interact with Laravels API only.
What are the best practices when it comes to stack architecture? Should we aim to bundle the stack together as proposed in solution 1? Is solution 2 even possible or is that due to my misunderstanding? If it is, how is deployment handled?
From my point of experience, both are correct and the answer depends on what you want to build 😀
First, if you have a simple website and you want to make the front-end of it in vue and it is only this one website, you can put it all together and make the frontend in Vue, which is handled by laravel in the backend and you are done.
Second, the step further, is for this case, that you can have several frontends for your project. Example: You have a website and several (native or universal) apps to display your data. In this case, you can build an API, that handles all the logic, all the business secrets, and this stuff, that no one should know in detail. After that, you are free to build any frontend (Vue, native, plain-HTML), whatever) you like, that's the only purpose is to display the data the API gives back (with some little logic in it, of the cause, but the secret business logic is hidden in the API). You can even outsource the generation of an app, so you build the website frontend in Vue and another one can build an ios-app with swift or an android app with kotlin.
Hope, you get the point, the answer is, as often: it depends 😉
So i have a laravel application that i built and is live using Laravel without Vue.js. Now, finding out about vue.js and its lightweight + numerous additional features for improved user experience, i have decided to include it and rebuild my app into components with much better reactivity.
The only issue is, with my little research, i found out that the main vue element in the resources/js/app.js points to an #app element in views/layouts/app.blade.php which would be fine if perhaps i had an SPA or and MPA that starts from there.
However, in my implementation i have different layout files for both back end and user section of my app, and i don't know how to go about it ( which element to point the vue object to).
Here's what i would like to have though, if possible. I would want a commons.js to have all my common components and imports and perhaps a [page].js for pages where i would need a bit more.
Thanks in advance!
I figured out how to handle this.
The Vue instance created in the app.js doesn't have to be your only instance. In MPA's you will most like have multiple vue instances, perhaps on per page. To keep my code clean, i kept the dependencies common to my whole application in app.js.
For my portals, each portal has a commons.js which containts dependencies specific to the management of my application and hence dont need to be loaded when the user is surfing my up. I set to bundle with webpack and include in all portal pages.
Furthermore, each page has a page.js which is also bundled and included only page specific dependencies (components etc) and a vue instance for each page.
By using this architecture i reduce the JS needed to be loaded to only the necessary on both portal pages and the main app for users.
Hope this helps someone! Happy coding.
I'm using Vue CLI PWA workbox plugin mode.
My app has more than 1000 assets, and precaching them results in very bad performance. Please, check it out:
https://nikudu.com/
Is there a way to precache files more specificly?
For example, precache files by URL.
On url x/y only precache files 1,5,6 and on url x/v precache files 7,8,2.
I have worked with PWAs and Angular, so no experience with Vue. That said, I would suggest to pre-cache only your shell app (hence the minimum static assets/js that you want to present to the user, when accessing the app offline).
For the other images you can use a lazy approach and cache the images only after they have been requested once (but I do not know if this goes against your requirements).
From this point you could even expand your logic to define, which are the most used routes and preload only those images in the background, once the user lands on the app.
If you are interested, I wrote an article about Service Workers and caching strategies independent from Angular, therefore you can use the same concepts in your app too.
I'm planning to create an application with Laravel 5.8 that's going to be visited heavily by people and therefore speed is a priority for me.
I will create a frontend - where people are being redirected to a page - which needs to be as fast as possible - and a backend where I can see the statistics - which doesn't need to be as fast but will be robust.
So I was planning to create 2 separate Laravel projects, one for the frontend and one for the backend.
The reason I'm thinking this way is I don't want the backend files, etc to be slowing down the entire frontend by loading in unnecessary files, packages, routes, etc.
Am I thinking correctly and if speed is my priority, should I separate these 2 projects?
The reason I'm thinking this way is I don't want the backend files, etc to be slowing down the entire frontend by loading in unnecessary files, packages, routes, etc.
They don't.
Laravel only loads (via the Composer auto-loader) most classes when they're used. If your code (controller, view, etc.) doesn't call App\Foo anywhere for a particular request, App\Foo isn't loaded.
If this is your reason for all the extra complexity of two different codebases, don't do it.
I have a lot of experience with YUI2 and I'm getting up to speed on YUI3. The service I'm writing needs HTTPS, but the vanilla YUI experience loads from Yahoo's HTTP-only CDN, which quietly fails in Chrome and loudly fails in modern IE when the browser tries to mix an HTTPS page with HTTP javascript.
My goals are to get all of:
Site uses HTTPS
YUI works in Chrome & IE (so scripts also must be delivered over SSL)
Uses a modern version of YUI 3 (this disqualifies YUI PHP Loader which hasn't been updated to support even YUI 3.4, while 3.8 is "current")
Use roll up combos for speed instead of many JS and CSS files (this disqualifies Google's CDN... if YUI 3 is actually hosted there which I couldn't find.)
Site dynamically loads YUI dependencies (dependencies change regularly as I add functionality, going back to the configurator and saving a new bundle every time is a PITA)
The obvious solution appears to be to give up goal #5 and just self-host combos.
How can I meet all 5 goals?
The easiest way to solve it is to change base URL from
http://yui.yahooapis.com/ to
https://yui-s.yahooapis.com/
Depending upon your server environment, you have a couple of options.
Development
Download the latest YUI library, and upload the yui/build/ folder to your server. The seed file should work fine without modification, though you won't be able to take advantage of combo loading.
Production
Use the YUI Configurator to determine all the files that you will need for each module set, and download them manually from the combo links provided. Rename them to something suitable like yui3.8.0-node-rollup.js and serve these to your users.
Be advised that if you use different module sets for different scripts, you may need to make multiple sets of files from this process, depending upon how you set it up. There is also a question here about concatenating Javascript together, if you are curious.
As an addendum, in my past research, I discovered that pulling external libraries over a secure connection may not be a safe idea.