{$comment}
{$name} ``` In the first paragraph, `$comment` is rendered as HTML text. The link assigns `$profileUrl` to the `href` attribute and `$name` to ordinary displayed content. In the script block, `$name` is assigned to a JavaScript variable. The README says that Latte recognizes these contexts and applies the corresponding sets of rules automatically. This mechanism differs from relying on one generic output filter at every template location. The stated benefit is fewer manual decisions about escaping, particularly when the same type of value appears in different HTML contexts. That does not make templates immune to every application-level security mistake. The README does not document content-security-policy configuration, trusted input handling, raw output, JavaScript serialization limits, or security implications for custom template filters. Its documented scope is context selection and escaping. ## How Forms Combine CSRF, Browser Rules, and Server Validation Nette Forms is described as CSRF-protected, validated in the browser, and validated again on the server from one form definition. The README supplies a PHP example that creates text, email, password, and submit controls: ```php $form = new Nette\Forms\Form; $form->addText('name', 'Name:') ->setRequired(); $form->addEmail('email', 'E-mail:'); $form->addPassword('password', 'Password:') ->addRule($form::MinLength, 'Use at least %d characters', 8); $form->addSubmit('send', 'Sign up'); ``` The `name` control is marked as required. The `email` control applies the form's email rule, while the `password` control applies a minimum-length rule with a message requiring at least eight characters. A `send` button completes the visible form definition. The important design claim is not merely that the form has validation controls. The README says the same definition supports browser validation and server-side validation, and that Forms supplies CSRF protection. Reusing one definition can prevent those sides from drifting into separate validation systems. However, the example does not show submission handling, rendering, route configuration, database persistence, or user creation. A developer following the complete Quick Start would need the linked tutorial for those application-level steps. ## HTTP Request Filtering and Tracy Failure Diagnostics The README says the HTTP layer rejects forged cross-origin requests using `Sec-Fetch` headers. These headers describe browser request metadata that can help a server distinguish requests made by a page from other kinds of requests. The README states that this behavior does not require an application-level opt-in. It presents request filtering as part of Nette's default framework behavior rather than as a separate integration. Tracy addresses developer diagnostics rather than request acceptance. According to the README, it can show an exception, the source code surrounding the failure, local variable values, SQL queries that ran, and a link that opens the offending line in an editor. This diagnostic context can shorten the path from a server error to the relevant operation. It also explains why Tracy can exist outside the wider framework. Tracy is explicitly described as a standalone library with no ties to the rest of Nette. That makes it a plausible component for a PHP application using another framework. It should not, however, be confused with a complete production observability system based on this documentation alone. The README does not document log shipping, alerts, distributed tracing, retention, performance overhead, deployment controls, or production data redaction. It also does not document a rollback procedure for Tracy. ## Starting nette/nette Through the Quick Start Tutorial The README does not publish an installation command in the text provided. It directs readers to the Create Your First Application link and the Nette Quick Start tutorial. Because `composer.json` is listed as a repository entry but its contents are not reproduced in the documentation, a Composer command would risk inventing a package name, constraint, or flag. No installation command is included for that reason. The documented first-use path is the Quick Start tutorial. The README says that it builds a blog with posts coming from a database, a comment form, and user authentication. That sample covers several framework concerns and offers a more informative evaluation than a single route that renders one page. It is intended to show how the pieces fit together in a working application. A developer can still make one decision from the README before following the tutorial: determine whether the project needs the full family or one library. A blog combining templates, forms, database access, and authentication aligns with the metapackage's purpose. A plugin that only needs one component should follow the README's advice to require that library rather than install everything. The tutorial itself contains the application files and setup commands needed to run the example, but those details are not reproduced in this repository README. ## Standalone Nette Libraries Versus the Full Metapackage The clearest alternative described by the README is not another named PHP framework. It is the adoption model built from Nette's standalone libraries. Instead of installing nette/nette, a project can require an individual component such as Latte, Forms, Database, Http, Security, Routing, or Utils. This changes the dependency boundary. The project receives only the component connected to its task rather than the complete list of framework libraries. The trade-off is integration responsibility. A full application can use the coordinated pieces and begin with the Quick Start tutorial. A standalone library can fit an existing WordPress, Symfony, or legacy codebase without adopting the rest of Nette. The README does not claim that every combination is pre-integrated, so an application using separate components may have to connect request handling, forms, templates, dependencies, and database access itself. Project history affects the choice. New applications can evaluate the complete framework and decide whether its defaults match their architecture. Existing applications may gain more from one component that solves a specific problem. Repository size alone is not evidence of quality, but the dependency difference is concrete: nette/nette installs all listed libraries at once, while standalone adoption limits the installation to the chosen component. ## Maintenance Evidence, Selective Upgrades, and License Review The repository is not archived, and its last push was on 2026-08-04. That records recent repository activity, but it does not establish a release schedule, support policy, or maintenance status for every individual Nette library. The listed releases are v3.1.0 from 2021-01-05, v2.3.11 from 2021-01-05, and v2.2.14 from 2020-10-07. The README does not explain the relationship between those releases and the later repository push. The README says every major version has a migration guide and each library is versioned separately. That supports selective upgrades. It can also mean that an application must review changes across multiple components rather than reason about one framework release as a single unit. The README does not document dependency constraint coordination, breaking-change schedules, security-fix distribution, or a framework-wide support window. Repository metadata identifies the license as a custom license that GitHub cannot classify. The repository includes `license.md`, but its exact terms are not quoted in the README. Teams must inspect that file before deciding how the package fits their distribution and compliance process. This article does not interpret those terms. The concrete upgrade cost is review of component-specific migration guides and their licenses, not an assumption that the recent repository push makes every library change automatically. ## Conclusion Adopt nette/nette when a new PHP application is intended to use Nette as a complete framework and you can accept a dependency set larger than strictly required. Do not choose this metapackage for an application that needs only one component or cannot maintain a broad Composer dependency list. Verify the component boundaries, migration guides, and the custom LICENSE file before adopting it. ## FAQ ### What is nette/nette? nette/nette is a Composer metapackage for the Nette Framework. It installs the listed Nette libraries together, while the libraries are also available as standalone components. ### How do I install nette/nette? The README does not provide an installation command. It links to the Nette Quick Start tutorial and describes this repository as a metapackage that installs all libraries at once. ### Should I use nette/nette or install only one Nette library? Use the metapackage when the application is intended to use the framework as a complete set. The README recommends requiring only the libraries actually used by applications that need narrower components. ## Sources - [Issues](https://github.com/nette/nette/issues) - [nette/nette on GitHub](https://github.com/nette/nette) - [Project website](https://nette.org) - [README](https://github.com/nette/nette/blob/master/README.md) - [Releases](https://github.com/nette/nette/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nette-nette