Exercise 2: A Philosophy, Not a Fourth Data Point — Possible Solution
====================================================================

HOW IMPORTMAP RESOLVES A MODULE WITHOUT A BUNDLER
------------------------------
Per this chapter, config/importmap.rb pins module names to real file URLs, and javascript_importmap_tags renders that mapping into a browser-native <script type="importmap"> block. The browser's own native ES module support reads that map and resolves each bare module name directly to its file, with no build step running in development or production to produce that mapping.

WHY THIS IS A PHILOSOPHICAL POSITION, NOT JUST A FOURTH SPECTRUM ENTRY
------------------------------
Per this chapter, Next.js's bundler is mandatory with no way around it, Django ships no pipeline to opt into at all, and Laravel pre-wires an optional but real bundler that's expected to be used. Each of those is a different amount of bundling. Rails' own Importmap default isn't a different amount - it's a deliberate attempt to avoid needing a bundler in the first place for an application that doesn't need a large client-side framework, treating reaching for Node/npm as a conscious escalation rather than a default assumption. That's a difference in starting philosophy, not just another point measured on the same "how much bundling" scale the other three sit on.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains the mechanics of how Importmap resolves modules via the browser's native ES module support with no build step, and correctly distinguishes this as a deliberate philosophical choice to avoid bundling entirely, rather than simply another position along the same spectrum the other three frameworks occupy.