Livewire Window Size Laravel Package

Product Decisions This Supports

• Server-side responsive rendering vs. CSS-only hiding: Enables decisions to render different Blade markup, components, or data based on viewport size, rather than shipping everything and hiding it with media queries. This matters for mobile payload reduction, conditional navigation, and device-appropriate content density.
• Feature scoping for mobile-heavy workflows: Useful for deciding whether dashboards, tables, filters, or desktop-only widgets should be conditionally rendered server-side on small screens instead of merely hidden. Helps validate whether mobile users need a reduced feature set or a fully responsive equivalent.
• Build vs. buy for viewport-aware Blade helpers: The package is small and MIT-licensed, so the real decision is whether to adopt a lightweight dependency versus implementing a few Alpine/Livewire directives in-house. With low stars, zero dependents, and a single maintainer, treat it as a tactical utility, not strategic infrastructure — and note that the in-house alternative is a few dozen lines of code, which is a strong argument for building given the maturity signals below.
• Roadmap experiments with low switching cost: Because it requires Livewire and AlpineJS, it is only viable if those are already core to the stack. In that case it enables low-effort experiments such as breakpoint-specific onboarding, conditional ad slots, or alternate mobile layouts without a frontend rewrite.
• A/B and personalization groundwork: Viewport-aware server rendering can support layout experiments where the server chooses a variant for a breakpoint, though it should not replace proper analytics, consent, or experimentation tooling.
• Use cases: mobile-optimized lists, desktop-only data visualizations, breakpoint-specific CTAs, conditional heavy widgets, and progressive enhancement where the initial render can safely default to a sensible baseline.

When to Consider This Package

• Consider it when: the product is a Laravel app already using Livewire and AlpineJS; the team needs Blade directives or PHP helpers that choose server-rendered content by window size; CSS-only hiding is insufficient because payload, queries, or component trees should differ by breakpoint; and the team accepts a small, low-maturity dependency or is willing to vendor/fork it.
• Version hygiene is now a gating criterion: release 4.0.1 fixed two defects that made core API effectively non-functional — mountHasBreakpoints() read a non-existent config key (livewire-window-size.breakpoints) so breakpoints were always [], and getBreakpoint() declared : array while returning an int, throwing a TypeError on every call. Pin to 4.0.1 or later, and disregard any prior spike or benchmark run on 4.0.0 — those results measured a broken component.
• Treat the 4.0.1 fix as a maturity signal, not a green light: both bugs were the kind any single test would have caught. Assume minimal test coverage upstream, budget for a smoke test of the breakpoint config and getBreakpoint() return value in your own suite, and plan to vendor the package if it becomes load-bearing.
• Consider it for internal tools and low-risk surfaces first: admin dashboards, authenticated app shells, and non-SEO-critical pages are better initial candidates than public marketing pages or checkout flows.
• Look elsewhere when: the stack is not Livewire/Alpine; the requirement is basic responsive layout, which should remain CSS; content must render identically without JavaScript; SEO-critical content must not vary by client viewport; or the team needs enterprise support, broad adoption evidence, and a maintained release cadence. With zero dependents and a single maintainer, production-critical adoption should include code review, tests, and a fallback plan.
• Be cautious with: SSR/hydration mismatches, no-JS users, caching layers that serve one viewport variant to all users, and using window size as a proxy for device capability. Prefer CSS srcset/media queries for images and layout where possible.

How to Pitch It (Stakeholders)

• Executive summary: This is a low-cost, MIT-licensed Laravel utility that lets the server choose content based on browser window size when using Livewire and AlpineJS. It can reduce mobile payload and enable breakpoint-specific experiences without a frontend rewrite. The 4.0.1 release is a bug-fix patch that restores the package's core API to working order — prior to it, breakpoint detection returned empty and the main accessor threw a type error on every call. That is good news for functionality but a caution on maturity: the defects were basic and shipped in a major version. Approve it as a scoped experiment on low-risk surfaces, pinned to 4.0.1+, not as platform-critical infrastructure.
• Engineering summary: It provides Blade directives and PHP helpers for viewport-aware server rendering, avoiding CSS-only hiding for cases where markup or data should differ by breakpoint. Integration cost is low only if Livewire and Alpine are already present. 4.0.1 corrects the breakpoints.window-width config lookup and changes getBreakpoint() to return int; anyone who worked around the old broken behavior (empty breakpoint arrays, catching the TypeError, or type-hinting the array return) must revisit that code before upgrading. Add tests covering breakpoint resolution, the int return type, hydration, and caching, and be prepared to vendor or replace it. Do not use it as a substitute for responsive CSS, srcset, or no-JS-safe rendering.