- Is styde/html compatible with Laravel 9, 10, or 11?
- No, not out of the box. The last release was March 2019, so its Composer constraints target roughly Laravel 5.x/6.x and PHP 7.x, and a plain composer require will usually fail dependency resolution on modern stacks. Even when forced in, it boots against removed framework helpers such as array_add, the str_* functions, and camel_case, which no longer exist in PHP 8 and Laravel 9+. Running it on a current version requires a private fork or vendored copy with compatibility patches.
- How do I install styde/html with Composer?
- On a matching legacy stack it is the standard flow: composer require styde/html, then register the package service provider and add the facade alias in config/app.php if auto-discovery does not cover your Laravel version. You may also be able to publish config or view files with the vendor:publish command. On current Laravel and PHP versions, expect resolution errors, so treat installation as a fork-and-vendor exercise rather than an upstream install.
- What does styde/html actually do?
- It is a presentation-layer helper library that generates common HTML and form elements through a fluent, object-oriented PHP API instead of hand-written Blade markup. You get builders for inputs, buttons, form controls, menus, and alert or message components, plus helpers for managing HTML attributes. It has no persistence, no domain logic, and no runtime services, so it is purely a view utility.
- Should I use styde/html or laravelcollective/html?
- They occupy the same niche: both are object-oriented HTML and form builders for Blade-rendered Laravel apps, so installing both is redundant and risks facade alias and global helper collisions. laravelcollective/html has broader adoption, but it carries much the same abandonment profile. For new code, the strongest option is neither — native Laravel Blade components cover most of this ground with zero abandonment risk.
- Are native Laravel Blade components a better choice than styde/html?
- For most modern Laravel projects, yes. Since Laravel 7, anonymous and class-based Blade components deliver reusable, well-escaped HTML with no third-party dependency, no abandoned upstream, and no per-major patch burden. Styde HTML only wins if you specifically want its menu and alert builders and are stuck on a legacy version of the framework. Even then, wrapping it behind your own components keeps the choice reversible.
- Is styde/html still maintained?
- No. Upstream has been dormant since its March 2019 release, has effectively no dependents creating pressure to keep it current, and has no maintainer absorbing new Laravel majors. In practice that means every framework upgrade becomes your patch job. Adopting it without a named owner and a recurring review cadence is technical debt with a scheduled due date.
- Is styde/html safe from XSS?
- Its unescaped and raw HTML helpers create a real XSS surface when they are fed user-controlled input, so review every call site that emits raw output. Test escaping behavior per component with debug mode off and the real exception handler enabled, rather than assuming the builder escapes for you. Because the package is unmaintained, no security advisory pipeline exists, so the review responsibility sits entirely with your team.
- Can I use styde/html with Livewire, Inertia, or an API-first app?
- It is a poor fit. The package is designed for server-rendered Blade monoliths and emits markup from PHP; in Inertia, Livewire, or headless front ends, form markup is owned by the client layer. There is no meaningful role for it when Blade is not producing the HTML. Reserve it for classic full-page Blade rendering only.
- How do I get styde/html working on a newer Laravel version?
- Fork it privately under the MIT license with attribution, or vendor the source directly into your repository, pinned to your Laravel LTS. Then replace removed framework helpers like array_add, str_*, and camel_case with their current Str and Arr equivalents, and fix any service provider or facade mismatches. Add CI with a PHP and Laravel version matrix, plus a security review of the escaping behavior, before letting application code depend on it.
- What breaks when installing styde/html on a modern Laravel app?
- You will typically hit one of three things: Composer refusing to resolve the package's PHP and Laravel constraints, a boot fatal from removed global helpers, or facade and alias collisions if another HTML package is already installed. Register the service provider, facade aliases, Blade directives, and config publishing in a throwaway project before touching real code. Once boot succeeds, render every component type to confirm output and escaping still behave correctly.