Laravel 13 leans heavily on PHP attributes, replacing many class properties with attribute‑style configuration. A common question on the Laravel subreddits is: “Do attributes always improve things, or should we still use plain properties?” As your Admin, I’ll break this down for you so you can see what’s right, what’s optional, and what’s mostly just style—from a learner’s point of view.
The big change in Laravel 13
In earlier Laravel versions, you would configure a queued job like this:
class ProcessPodcast implements ShouldQueue
{
    public $tries = 3;
    public $backoff = [3, 7, 20];
    public $timeout = 120;

    // ...
}

In Laravel 13, the same configuration can be written with attributes:

use Illuminate\Queue\Attributes\Tries;
use Illuminate\Queue\Attributes\Backoff;
use Illuminate\Queue\Attributes\Timeout;

#[Tries(3)]
#[Backoff(3, 7, 20)]
#[Timeout(120)]
class ProcessPodcast implements ShouldQueue
{
    // ...
}

The official Laravel 13 upgrade guide and queues documentation make it clear: these attributes are optional and fully backward‑compatible. You can keep using the old property‑style setup if you prefer; Laravel won’t break your application. So as a learner, you’re not doing anything “wrong” if you stick with properties for now.
When attributes are actually helpful (for you)
According to Laravel’s own docs and community resources, attributes are worth using when they actually improve clarity and structure, not just “look fancy.” Here’s where they shine from a learner’s perspective:
1. Declarative, centralized config
Attributes let you define behavior and metadata right at the class or method level, instead of mixing config far down in a block of public $tries, public $backoff‑style properties. This makes it easier for you to see what a class “does” at a glance.
2. Consistent style across Laravel 13
Laravel 13 now supports attributes for:
Models: #[Fillable], #[Guarded], #[Hidden] instead of $fillable, $guarded, $hidden.
Jobs: #[Tries], #[Backoff], #[Timeout] for queue settings.
Commands, routes, middleware, and observers (where available).
This “attributes‑first” style is meant to unify how you configure Laravel components, as shown in the Laravel 13 release notes and upgrade guide. As an admin, I’d say: once you’re comfortable with Laravel basics, adopting this style makes your code look cleaner and more modern.
3. IDE‑friendly and type‑safe metadata
PHP attributes are normal PHP classes, so they can be type‑hinted, documented, and inspected by your IDE. When you use #[Tries(3)], your editor can cross‑reference the Tries class, show parameters, and help you avoid mistakes. This is especially helpful for you as a learner who’s still getting used to Laravel’s API.
When simple properties are still fine (for you)
There’s a fair point in that Reddit thread: if you’re only replacing a simple configuration property that never changes, attributes can feel like overhead. For example:

public $tries = 3;
public $backoff = [3, 7, 20];
public $timeout = 120;

is straightforward to read, and the value is easy to override or inspect at runtime.
Laravel’s own documentation and ecosystem guides (like the Laravel 13 deep‑dive and Laravel‑Daily’s attributes guide) stress that attributes are not required; the old style still works and is valid for learning or maintenance projects. As your admin, I’d say: if properties feel simpler, use them—no penalty.
Practical advice for you as a learner
If you’re learning Laravel in 2026, here’s a simple rule of thumb I’d suggest:
Use attributes when:
You want to follow Laravel 13’s “best‑practice” style for jobs, models, commands, and routes.
You enjoy writing config close to the class/method definition and want your codebase to look modern and consistent.
Stick with properties when:
You’re still learning and the attribute syntax confuses you.
You’re working on existing code that still uses properties; Laravel does not force you to migrate.
TL;DR for you
Attributes like #[Tries], #[Backoff], and model‑level attributes are optional, modern alternatives to properties in Laravel 13.
Laravel’s own docs and upgrade notes confirm that both styles work; you choose what fits your project and comfort level.
As a beginner, focus first on understanding what the config does (tries, backoff, timeout, scopes, etc.) before worrying whether to write it as a property or an attribute. Once that concept is clear, attributes become a natural next step.