Exercise 1: The Real Three-Way Bundling Difference — Possible Solution
====================================================================

NEXT.JS
------------------------------
Per this chapter, Next.js bundles CSS as an inseparable part of its own framework build system - the bundler is invisible, baked directly into the framework, with no separate config file most projects ever need to touch.

DJANGO
------------------------------
Per this chapter, Django has no bundler at all - staticfiles simply serves plain files exactly as they sit on disk, with zero processing or bundling concept built in anywhere.

LARAVEL
------------------------------
Per this chapter, Laravel occupies neither extreme - composer create-project installs and pre-configures a real, genuinely separate, independently-maintained tool (Vite), evidenced by vite.config.js existing as its own real, visible file rather than being hidden inside Laravel's own internals.

IS LARAVEL "A BUNDLER" THE SAME WAY NEXT.JS IS?
------------------------------
No. Per this chapter's own central finding, Laravel hands the developer a fully wired-up copy of an independent tool - it doesn't build bundling capability into the framework itself the way Next.js does. Vite remains its own separate project with its own separate configuration file, whereas in Next.js the bundler and the framework are effectively one and the same, with no equivalent separate artifact to point at.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly describes all three positions distinctly, and correctly explains why Laravel is not "a bundler" in the same sense Next.js is - Laravel pre-wires an external tool rather than incorporating bundling as a built-in framework capability.