No Support for On-Demand Import

In modern frontend engineering, "on-demand import" (Tree Shaking) seems to have become an industry standard. However, based on its unique technical architecture and product positioning, TechUI decided from the outset not to support on-demand import.

This is a counter-intuitive but well-considered decision. The following are the core reasons why we abandoned this feature.

Architectural Limitations

The core of TechUI is not a set of scattered JavaScript files, but a compiled WebAssembly (Rust) binary module.

• Dynamic Computation Dependencies: More than 90% of the SVG paths, sci-fi dynamic effects, and 3D posture calculations in TechUI are generated in real-time by the Wasm module at runtime through mathematical formulas, rather than static SVG files.
• Indivisible Binary: A Wasm module is similar to a compiled .exe or .so library file. You cannot "import half of the binary code" like splitting JS code. To ensure the complete operation of core algorithms (such as the TEMPLATE engine and ENC encryption), the entire Wasm core must be loaded.

Commercial Protection

TechUI is a commercially closed-source component library, not an open-source community project.

• Packaging as Protection: Supporting "on-demand import" usually means publishing unpackaged source code (ESM) and allowing build tools to analyze the code dependency tree. This would directly expose our core implementation logic.
• Anti-Reverse Engineering: To protect intellectual property, we perform deep packaging and obfuscation on all components before release. This "full package release" strategy is the first line of defense for the anti-tamper mechanism.

Development Philosophy

TechUI was designed to serve high-intensity enterprise-level development scenarios (such as outsourced delivery and urgent large-screen projects). We believe that the value of a developer's time is much higher than the bandwidth cost for users.

• Batteries Included: We promote the "full registration" model. Developers do not need to repeatedly import every icon or component on every page.
• ❌ Cumbersome: import { TuiButton, TuiIconUser, ... } from ...
• ✅ Efficient: After app.use(TechUI), you can use <TuiButton /> directly anywhere.
• Flow Experience: When building complex large screens, not having to interrupt your thoughts to find and configure component references just to save a few KB significantly improves the developer's flow experience.

Performance Dialectics

For the B2B / G2B (government/enterprise) application scenarios served by TechUI, we focus the optimization of first-screen loading speed on "network environment" and "caching strategy" rather than just package size.

• Bandwidth Redundancy: In today's era of 4G/5G and widespread fiber optics, loading an 800KB+ Wasm package (even smaller after Gzip) usually takes only a few hundred milliseconds. Sacrificing development efficiency to save dozens of KB is considered over-optimization in modern network environments.
• Long-term Caching: Once the Wasm module and component library code are loaded, they are strongly cached by the browser. For internal enterprise systems (Intranet) or high-frequency large-screen systems, users only need to download resources on their first visit; subsequent visits incur zero network overhead.
• Streaming Compilation: Thanks to Wasm's Streaming Compilation feature, its parsing and execution speed are much faster than JavaScript code of the same size, so the actual "Time to Interactive (TTI)" is not significantly delayed by a large package size.

This is an excellent analogy. By citing well-known operating systems and software, it powerfully demonstrates that "redundancy" in engineering design often represents "capacity reserves" and "system robustness," rather than simply being a burden.

I have significantly expanded upon the original "Pareto Principle" section, incorporating the examples of iPhone, Windows, and Android that you requested, making it a highly persuasive chapter.

Redundancy Philosophy

TechUI follows the reverse thinking of the "Pareto Principle": Although 80% of users may only use 20% of the functions, we cannot predict which specific 20% those will be.

In software engineering, "comprehensive" design is often misunderstood as bloated, but it actually represents "Capability Completeness." Top-tier digital products we use daily practice this philosophy:

• 📱 iPhone / Android Systems: Your mobile operating system easily takes up 10GB+ of space. It includes LiDAR drivers, accessibility features (VoiceOver), and dozens of foreign language fonts you may never use. Why not delete them? Because when you occasionally need to scan a QR code or adjust a font size, the system must respond immediately instead of prompting you to "download a module".
• 💻 Windows / macOS: Operating systems come pre-installed with tens of thousands of printer drivers and general hardware interfaces, even if you only have one printer. The value lies in "Plug and Play" when you connect a new device. TechUI's full import is also to allow developers to write and use a chart immediately when needed.
• 🌐 Complex SaaS / Website Functions: Consider Microsoft Excel or Photoshop. Most users only master 5% of their functions (like summation or cropping) in their lifetime. The key point is that the remaining 95% is not redundant because the "5%" needed by each user is different. Only by providing 100% of the feature set can the "individual 5%" of everyone be met.

The same applies to TechUI Prime. Because we pre-install the full code, you only need to change one line of configuration to achieve a result, without reconfiguring build tools, troubleshooting dependency conflicts, or downloading new plugins.

Redundancy is sometimes the greatest convenience.

📦 Size Note

Currently, the Gzip compressed size of TechUI Prime (including the Wasm core) is approximately 1MB ~ 2MB (depending on the version). In a modern enterprise-level broadband environment, this is within a completely acceptable range.