Evaluating LLM Front-End Capabilities: From Page Generation to 3D Interaction

1. Introduction: When LLMs Begin to Understand “Vision and Space”

Over the past year, discussions of LLMs in code generation have mostly focused on quantifiable areas such as back-end logic, algorithm problems, and script automation. Front-end development has long been regarded as an auxiliary capability—something models “can write but not well.” That has changed noticeably with the latest round of model iterations.

This article does not discuss version numbers from any particular model vendor, nor does it promote any specific commercial product. Instead, it approaches a more universal technical question from the practical perspective of a front-end developer: Do current LLMs already possess front-end generation capabilities that can be engineered? Specifically, this covers five dimensions: page aesthetics, spatial understanding, 3D modeling, lighting and shadow effects, and agent collaboration.

Through hands-on testing and code review, this article attempts to answer a more fundamental question: Are LLMs merely “syntax completion tools,” or have they come close to being an “engineering collaborator” capable of understanding design intent and performing spatial reasoning?

---

2. Designing the Evaluation Dimensions: What Counts as “Good Front-End Generation”

Before starting the actual evaluation, we need to define the criteria. An evaluation system that only asks “does the code run” cannot measure the real value of front-end generation. This article evaluates along the following five dimensions:

Dimension	Evaluation Focus	Engineering Significance
Aesthetics and Layout	Visual hierarchy, spacing control, color coordination, responsive behavior	Determines whether generated pages can go directly into design review
Spatial Understanding	Element hierarchy, coordinate relationships, perspective relationships, occlusion logic	Affects structural correctness of complex UI and 3D scenes
3D Modeling	Geometry composition, material mapping, mesh structure rationality	Relates to the usability of WebGL/Three.js projects
Lighting and Shadow Effects	Light source positions, shadow directions, reflection and refraction rationality	Determines whether visual effects reach “demo-grade” quality
Agent Collaboration	Task decomposition, step planning, intermediate artifact management, self-correction	Determines whether the model can serve as an “execution unit” in a development workflow rather than a “one-shot Q&A”

These five dimensions are not isolated. An excellent front-end generation result is typically a combination of aesthetics, spatial understanding, and engineering implementation capability.

---

3. Page Generation in Practice: From Natural Language to Maintainable Code

3.1 Test Task Design

To evaluate page generation capability, three tasks with progressive difficulty were designed:

1. Basic layout task: Generate a “data dashboard” homepage with a top navigation bar, sidebar, key metric cards, and a chart area.
2. Visual enhancement task: On top of the basic layout, add a dark theme, gradient backgrounds, glassmorphism effects, and smooth transition animations.
3. Responsive constraint task: Further require the page to use a stacked layout on mobile, automatically collapse the sidebar, and maintain interactive accessibility.

3.2 Output Analysis

In terms of generation quality, the model’s code output performed well in the following areas:

Structural clarity: HTML semantic tags are used reasonably. Elements such as <header>, <nav>, <main>, and <aside> are used in a way that basically conforms to standards, rather than piling up <div> everywhere. This shows the model has absorbed a large number of semantic HTML practices.

CSS organization: Style code uses CSS custom properties to centrally manage theme colors, spacing, and border-radius variables, avoiding magic numbers scattered throughout. For example:

:root {
  --bg-primary: #0f1117;
  --bg-card: rgba(255, 255, 255, 0.06);
  --text-primary: #e8eaed;
  --radius-lg: 16px;
  --spacing-md: 1rem;
}

This approach is close to the coding habits of a mid-level front-end engineer, rather than simply stacking styles.

Visual completeness: The dark theme’s color scheme is harmonious, and the overlay of gradient backgrounds with glassmorphism cards does not produce obvious visual noise. Spacing between cards is well controlled, and the visual hierarchy is clear.

3.3 Exposed Weaknesses

In the responsive constraint task, some noteworthy issues emerged:

• Breakpoint choices are conservative: The media query breakpoints the model defaults to are concentrated at 768px and 1024px, and handling of intermediate sizes (such as the tablet landscape range of 820px–912px) is not granular enough.
• Missing interaction details: The mobile sidebar “auto-collapse” is implemented as a simple display: none, lacking slide-out animation and overlay management—still short of “accessibility compliant.”
• Insufficient maintainability considerations: As page complexity increases, the CSS file begins to show repeated style blocks, without proactively extracting common classes or using a more structured organization.

These weaknesses indicate that the model is good at generating code that “looks great,” but at the engineering maintenance level, human intervention is still required.

---

4. Spatial Understanding and 3D Modeling: Beyond “Drawing It Out”

4.1 3D Scene Generation Capability

3D modeling tasks test the model’s spatial reasoning ability more than 2D page generation. In the test, the model was asked to generate a “sci-fi style spacecraft cabin interior scene” containing a control console, seats, observation windows, and floating display panels.

From the generated results, the model demonstrated capabilities beyond expectations in the following areas:

Spatial layout rationality: The placement of objects inside the cabin follows basic physical logic—the console is in front of the observation window, the seats face the console, and the floating panels are distributed on both sides of the operator’s line of sight. The relative positional relationships between these elements are reasonable, indicating the model truly “understands” the scene rather than merely stacking geometries.

Geometry composition capability: The console is not a single cube but is composed of multiple geometries—a base, an angled operation surface, and beveled edge pieces. This approach of “building complex structures from primitives” is consistent with how humans model with WebGL libraries.

Material and texture mapping: The reflection parameters of metal surfaces, the transparency and refraction of observation window glass, and the color temperature differences of cabin light sources are all assigned different material properties, rather than using a uniform default material.

4.2 Synergy with 2D Pages

A more interesting finding: when asked to embed an interactive 2D information panel in the same scene, the model was able to correctly project HTML/CSS rendering results as a texture onto a plane in 3D space. This involves coordinate mapping between 2D DOM and 3D scenes and integration of the rendering pipeline—a rather tricky part of real projects.

This capability means: LLMs can already effectively organize code for a hybrid “2D UI + 3D scene” rendering architecture, rather than generating each independently and simply pasting them together.

---

5. Lighting and Shadow Effects: From “Having Shadows” to “Shadows Are Correct”

Lighting and shadow effects are the area where front-end visual generation most easily reveals weaknesses. A scene with an incorrectly positioned light source or contradictory shadow directions will feel off even if the model is exquisite.

The test designed a scene: a floating complex geometry illuminated by three light sources of different color temperatures, required to produce correct shadows.

The model’s generated code passed in the following areas:

• Consistency between light source positions and shadow directions: The main light source shines from the upper left, and all object shadows point to the lower right, with shadow length inversely proportional to light source height—consistent with perspective laws.
• Multi-light source superposition logic: The superposition calculation of three light sources (cool main light, warm fill light, top rim light) is correct, without simple addition causing overexposure.
• Light transmission handling for transparent materials: The brightness attenuation calculation of semi-transparent geometries in shadow areas is reasonable, without the common error of “transparent objects casting fully black shadows.”

These details typically require developers to have some graphics fundamentals to handle correctly in traditional front-end development, and the model has internalized this knowledge into its code generation process.

---

6. Agent Collaboration Capability: From “One-Shot Q&A” to “Task Execution”

6.1 Task Decomposition Capability

One noteworthy improvement in this round of model iteration is the maturation of agent behavior patterns. Specifically:

When receiving a complex task (such as “build an admin dashboard homepage with user login, data display, and interactive charts”), the model no longer outputs all code at once but instead:

1. First outputs a task decomposition plan
2. Generates code module by module (layout skeleton → style system → component logic → interaction binding)
3. Self-checks after each step
4. Finally outputs an integration plan

This “plan—execute—check” behavior pattern is closer to a real development workflow than单纯的 code generation.

6.2 Engineering Value Assessment

From an engineering perspective, the value of this capability cannot be ignored:

• Reduced review cost: Step-by-step output allows developers to intervene and correct at intermediate stages, avoiding the time waste of “generate everything at once, go off track, and start over.”
• Enhanced sense of collaboration: The model’s behavior pattern becomes more like “pair programming” rather than a “code vending machine.”
• But boundaries remain: When the task span is too large (e.g., involving front-end, back-end, and deployment configuration simultaneously), the model’s planning ability drops significantly, and it easily falls into a situation of “seeming organized but actually losing context.”

---

7. How Developers Can Effectively Leverage These Capabilities

Based on the above hands-on testing, here are several actionable practical recommendations:

7.1 Prompt Strategy

Effective approach: Split the task description into a three-part structure: “context + constraints + acceptance criteria.” For example:

Context: You are building a homepage for a data analytics platform.
Constraints: Use CSS Grid for layout, support dark theme, and all interactive elements must have hover/focus states.
Acceptance criteria: The page layout does not break at 390px, 768px, and 1440px widths; all icon buttons have accessible labels.

Approach to avoid: Directly inputting “make me a nice-looking page.” Such vague instructions cause the model to degrade into a “random style generator.”

7.2 Code Quality Control

Generated code should go through three layers of filtering:

1. Static checks: Are there obvious syntax errors, unclosed tags, or undefined variables?
2. Structural review: Are components overly coupled? Is there a lot of duplicated styling? Is naming semantic?
3. Visual inspection: Render in a real browser and check actual effects at different viewports.

7.3 Human-Machine Division of Labor

At the current stage, the most reasonable division of labor is:

• Model handles: Initial structure scaffolding, visual style exploration, repetitive style writing, 3D scene prototyping.
• Human handles: Design review, performance optimization, accessibility assurance, cross-browser compatibility, and final code integration.

---

8. Conclusion: Philosopher’s Stone, or a More Precise Tool?

Returning to the question from the introduction—is the LLM a “philosopher’s stone”?

From this evaluation, the answer leans toward: It is not an all-powerful object that turns everything into gold, but an engineering tool whose understanding and expressiveness are rapidly improving. It has reached a “usable” or even “good” level in front-end generation, 3D modeling, and lighting effects, but in engineering, maintainability, and complex task collaboration, it still requires developer judgment and intervention.

For front-end developers, what truly deserves attention is not “whether the model has replaced someone,” but how to embed this capability into your own development workflow, so that repetitive creative work is accelerated and energy is reserved for more valuable architectural decisions and experience design.

Tools change, but the ability to judge “what constitutes good engineering output” remains the developer’s core moat.