It’s 2024 and I’m calling it – Server-Side Rendering has officially made a comeback:
in Laravel, where Livewire now has 46.000 installs per day
in Ruby on Rails with Hotwire
in Phoenix with Liveview
in web dev in general with HTMX
Now that “the old has become the new“… maybe it’s time to re-visit another practice we’ve adopted from the Javascript ecosystem. Maybe it’s time to… drop the build step? Crazy, I know! But there’s been a lot of talk about no-build Laravel setups in my bubble. And there’s one place where people invariably get stuck – “If we drop NPM, what do we do about JS dependencies?“. Here’s my answer to that – or at least an important first step.
What if instead of installing our JS dependencies with a package manager like NPM and bundling them… we just load them directly from the URL? You know… similarly to what the founder of NodeJS himself is doing in Deno. He has publicly said NPM has become a mess and created an alternative for the JS ecosystem… why don’t we do the same for the Laravel ecosystem?
If you dream about the simple days when you could just load assets using asset(), try Basset – a better asset helper for Laravel. You just replace asset() with basset() to gain some super-powers:
assets from CDNs are downloaded to /storage and served from there;
vendor assets become possible to load;
non-public assets become possible to load;
it becomes impossible to double-load an asset during a request;
In short, basset() removes the limitations of asset(), allowing you to load any asset you want, safely. That means in addition to this:
<link href=”{{ asset(‘path/to/public/file.css’) }}”>
You can safely do this:
<script src=”{{ basset(storage_path(‘file.js’)) }}”>
<script src=”{{ basset(base_path(‘vendor/org/package/assets/file.js’)) }}”>
<script src=”{{ basset(‘https://cdn.com/path/to/file.js’) }}”>
This is a very simple solution for those who want to load assets “the old easy way” in their Laravel projects, because it solves a few problems with that “old way“:
Don’t want GDPR issues?
✅ Solved – Basset will cache the asset to /storage and serve it from there.
Don’t want to depend on a CDN being up?
✅ Solved – the assets can be cached upon deployment (or on commit).
Don’t want to load an asset twice, if used by multiple components on that page?
✅ Solved – automatically.
Concerned about the performance of loading multiple JS files vs one big bundle?
✅ Solved by HTTP/2, which makes it performant to load multiple Javascript assets on a single page.
Granted, Basset may not be a perfect asset loading solution. At least not for every project. It’s only been around for 12 months, so it’s missing things like importmaps and the like, to make it a 1-to-1 alternative to NPM and Deno’s way. But it has been around for 12 months and has proven its usefulness.
Perhaps… it’s time for us to take another look at how we load assets in our Laravel projects. Maybe we’ll discover the simple way… is a good way. For some projects, at least. I suggest you give Basset a try. After all:
it’s been in production for 1 year already;
it’s maintained by the Backpack team;
it’s got 110.000 downloads already;
it’s under MIT License;
If you have feedback on it, open an issue on Github and tell the team about it. A v2 is due soon enough, and we want to incorporate as much feedback as possible.
The post Basset is an alternative way to load CSS & JS assets appeared first on Laravel News.
Join the Laravel Newsletter to get all the latest Laravel articles like this directly in your inbox.
Source: Read MoreÂ
