Rethinking Web Frameworks: From Ideal Design to Practical Implementation

Background: The author argues that framework design should start from an ideal vision rather than existing technologies, then evaluate feasibility and compromise, aiming to create truly meaningful frameworks.

The article examines the current state of frontend frameworks (Backbone, Angular, React, Flux, Relay) and contrasts them with full‑stack solutions like Meteor, highlighting trade‑offs between rapid development and enterprise stability.

Desired framework characteristics are listed: a strong, language‑agnostic data‑model layer; reusable code across client and server; decoupled data models that can integrate with any front‑end framework; automatic data synchronization without polling.

var user = new User({id:1}); user.pull(); user.watch();

The author stresses that the data‑model layer should not contain business logic (e.g., login/logout) nor bind to any specific ORM or storage engine.

Data vs. logic: Minimal code should directly reflect the application description (e.g., a blog’s user, post, and tag entities). Pseudo‑code is used to illustrate a pure data description that is independent of storage details.

// data description User : { name : string } Post : { title : string, content : text } Tag : { name : string } // relationships User -[created]-> Post Post -[has]-> Tag

Logic is then expressed as simple class methods, showing how additional features (e.g., @‑mentions) can be layered without breaking the original structure.

class User{ createPost(content, tags=[]){ var post = new Post({content:content}); post.setTags(tags.map(tagName=>new Tag(tagName))); return post; } }

class User{ createPost(content, tags=[]){ var post = new Post({content:content}); post.setTags(tags.map(tagName=>new Tag(tagName))); if(at.scan(content)){ at.getUser(content).forEach(atUser=>{ system.mail(atUser); }); } return post; } }

To achieve high maintainability and extensibility, the author proposes an event‑driven architecture where each business operation is an event listener, allowing clear responsibility separation and easy addition or removal of features.

// emitter is the event hub emitter.on("post.create", function savePost(){...}); emitter.on("post.create", function createTags(){...}, {before:"savePost"}); emitter.on("post.create", function scanSensitiveWords(post){ if(system.scanSensitiveWords(post)){ return new Error("you have sensitive words in post."); } }, {block:all}); emitter.on("post.create", function scanPopTags(){...}); // fire the event emitter.fire("post.create", {...args});

This model makes the call stack correspond directly to the business flow, enabling automatic visualization, testing, and monitoring of the logic.

The discussion then shifts to graph databases (Neo4j) and Cypher, emphasizing pattern‑matching queries as a revolutionary way to describe data without coupling to storage schemas, and linking this idea to GraphQL/Relay for front‑end data fetching.

Cross‑language event systems are explored: a unified event format allows Node.js, Python, Go, etc., to interoperate, facilitating language‑agnostic micro‑services and easier performance tuning.

A prototype implementation is showcased: a React front‑end with a Koa back‑end, a todo application, and various diagrams illustrating the event stacks for creating posts and handling @‑mentions.

In the concluding philosophical note, the author likens flexible software architecture to human cognition, arguing that modeling systems after human reflexes yields adaptable, maintainable code, while acknowledging that frameworks only lower the barrier—they cannot force developers to write good code.