Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Go over if we should include an app.js file instead of using the Alpine.js CDN #2026

Closed
Tracked by #1499
caendesilva opened this issue Nov 16, 2024 · 2 comments
Closed
Tracked by #1499

Comments

@caendesilva
Copy link
Member

caendesilva commented Nov 16, 2024

Go over if we should include an app.js file instead of using the Alpine.js CDN (or if we actually need app.js, which is useful mainly for offline sites), or a command/easy way to include it, maybe an easy way to disable the CDN.

@caendesilva caendesilva changed the title Go over if we should include an app.js file instead of using the Alpine.js CDN (or if we actually need app.js (useful mainly for offline sites), or a command/easy way to include it. maybe easy way to disable the cdn) Go over if we should include an app.js file instead of using the Alpine.js CDN Nov 16, 2024
@caendesilva
Copy link
Member Author

caendesilva commented Nov 16, 2024

Claude Sonnet

Currently, the Alpine.js setup is handled in the following ways:

  1. Alpine.js is loaded via CDN in the scripts layout:
{{-- Alpine.js --}}
<script defer src="https://cdn.jsdelivr.net/npm/[email protected]/dist/cdn.min.js" integrity="sha256-gOkV4d9/FmMNEkjOzVlyM2eNAWSUXisT+1RbMTTIgXI=" crossorigin="anonymous"></script>
  1. The app.js file is referenced in multiple places but appears to be mostly empty/unused:
/*
* This is the main JavaScript used by Vite to build the app.js file.
*/
  1. The Vite config is set up to handle both app.css and app.js:
        rollupOptions: {
            input: [
                resolve(__dirname, 'resources/assets/app.js'),
                resolve(__dirname, 'resources/assets/app.css')
            ],
            output: {
                entryFileNames: '[name].js',
                chunkFileNames: '[name].js',
                assetFileNames: '[name].[ext]'
            }
        }

Based on the codebase analysis, here are my recommendations:

  1. Keep the CDN as Default
  • The CDN approach is working well as the default option
  • It's fast, reliable and requires no build step
  • Most users won't need offline capabilities
  1. Add Configuration Option
  • Add a new config option in hyde.php similar to load_app_styles_from_cdn
  • Something like load_alpine_from_cdn (defaulting to true)
  • When false, it would include a local copy of Alpine.js
  1. Provide Local Alternative
  • Create a command to download Alpine.js locally:
php hyde download:alpine
  • This would download Alpine.js to _media/vendor/alpine.js
  • Update the scripts layout to check the config and use local file if CDN is disabled
  1. Update Documentation
    Add a section in the asset management docs explaining the options:
### JavaScript Assets

By default, Hyde loads Alpine.js from a CDN for optimal performance. However, if you need offline capabilities or prefer local assets:

1. Disable the CDN in config/hyde.php:
```php
'load_alpine_from_cdn' => false
  1. Download Alpine.js locally:
php hyde download:alpine

This will serve Alpine.js from your local environment instead of the CDN.


The current app.js file seems unnecessary since:
1. The main JavaScript functionality (dark mode toggle) is already included inline
2. Alpine.js handles most interactive features
3. No other significant JavaScript appears to be needed in the core framework

Therefore, I recommend:
1. Keep the CDN as the default
2. Add configuration options for local hosting
3. Remove the empty app.js file unless specific JavaScript features are needed
4. Update documentation to clarify these choices

@caendesilva
Copy link
Member Author

I think having the Alpine CDN is nice. We don't have enough scripts to need to bundle them together. Offline usage can be handled by the user if they need it. Not within the 99% use case. Instead, see #2027

@caendesilva caendesilva closed this as not planned Won't fix, can't repro, duplicate, stale Nov 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant