Boost Efficiency with a Hybrid ProCode & LowCode Development Approach

In the past one to two years low‑code (LowCode) applications have proliferated, from simple tail‑end tools to complex business systems, lowering development barriers but still facing resistance due to component complexity, extensive page logic, and heavy customization.

Combining ProCode and LowCode development is becoming inevitable as organizations pursue cost reduction, layered staffing, and external services.

Current Mixed Development Situation

Most applications treat ProCode and LowCode as completely separate pipelines, with parallel project initialization, development, and deployment. VC components (backend low‑code components) can be published to the low‑code platform, but several problems arise:

Each VC or LowCode component is a separate package, leading to cumbersome and error‑prone package management.

Lack of multi‑branch capability; VC components live outside project management, making coordinated development difficult.

ProCode and LowCode components cannot reference each other, and version management creates additional issues.

One possible optimization is to bundle all VC components together, using LowCode only for simple assembly, but VC packages are costly and lack direct association with applications, especially under concurrent demands.

Ideal Hybrid Development Flow

The ideal flow must address the above challenges by:

Supporting multiple branches that manage both ProCode and LowCode branches.

Providing unified management and integration of pages, modules, and components regardless of development mode.

Offering an integrated build and release process.

Key notes:

The mixed approach treats applications as a single entity, not distinguishing between LowCode and ProCode.

Applications are bound to a GitLab repository, enabling creation of both ProCode and LowCode branches.

During development, pages and components can reference each other freely.

ProCode branches merge via GitLab, LowCode branches merge on the platform.

Final packaging and deployment are unified.

In the short term, a lightweight hybrid model is needed.

Lightweight Hybrid Development Flow

This simplified flow removes two aspects:

No development of ProCode pages.

No ProCode pages or components referencing LowCode components.

Branch merging is performed outside the platform, with ProCode components manually merged before release, while LowCode components merge on the platform.

Page Development Perspective

Current practice keeps ProCode and LowCode applications separate, with clear relationships among pages, modules, and components, but this separation no longer meets business needs such as multi‑application integration in workbench mode and cross‑platform requirements (e.g., DingTalk).

Simple hybrid integration can inject ProCode VC components into LowCode applications, yet direct reuse of project‑level ProCode components in LowCode remains limited.

Enabling ProCode applications to import LowCode modules or components creates a straightforward hybrid model:

This approach solves some integration challenges but still struggles when an application contains diverse page types that require separate ProCode and LowCode solutions or iframe embedding.

Ideal Page Development Solution

The ideal solution should satisfy:

No distinction between ProCode and LowCode applications.

Uniform import mechanisms for both ProCode and LowCode modules/components; they differ only in development mode, not in consumption.

Users decide per page/module/component whether to use ProCode or LowCode.

From a top‑down integration view, applications, pages, modules, and components share the same concepts:

From the platform perspective, any application can have pages built with either ProCode or LowCode.

From the application perspective, all pages expose identical metadata and common capabilities (watermark, data loss prevention, monitoring, etc.), differing only in development mode.

From the page perspective, all modules and components are project‑level components with a unified import method.

From a bottom‑up development view:

All ProCode pages, modules, and components reside in a GitLab repository with branch‑based iteration.

All LowCode pages, modules, and components are maintained on the low‑code platform with versioned releases.

Adopting this unified front‑end strategy dramatically lowers integration costs, enables configuration‑driven and extensible development, reduces expenses, improves efficiency, and facilitates hand‑off to ISVs and partners.

Further Thoughts

Looking ahead, we could eliminate ProCode pages entirely, creating every page on the LowCode platform, decomposing pages into fill‑in‑the‑blank modules with defined inputs (state, mock data) and outputs (UI), and producing pages in a BOM‑like fashion. This would allow different skill levels to develop modules, achieving lower cost and higher quality.

关注 Alibaba F2E 公众号，掌握前端新动向。