One ecosystem,
one philosophy

Why BasisCore isn't a "product"

The most common mistake when looking at BasisCore is to line it up next to WordPress, Next.js, or another CMS and compare them. That comparison is misleading — because before BasisCore is a product, it is a grammar: a way of talking to the web, in which the developer declares what instead of writing how.

When you write this:

<basis core="dbsource" source="basiscore" name="db" lid="1" catid="65934">
 <member type="list" name="blogpage" propertyid="97888,7244" />
</basis>

<basis core="print" datamembername="db.blogpage">
 <face filter="prp_97888 = 'video'">
 <p>@title</p>
 </face>
</basis>

…there is no build step. No compiler, no transpiler. The browser itself is the runtime. Data arrives, is filtered and queried on the client (with something like alasql), and the template is filled. This is a philosophical decision, not merely a technical one — and the entire personality of the ecosystem flows from it.

Five lines of thought

Five threads of thinking form the backbone of BasisCore.

1 · The web as a language, not as a build

For two decades the mainstream of modern JavaScript has moved toward heavy toolchains: npm, Webpack/Vite, compile, bundle, and a vast dependency graph. BasisCore moves in exactly the opposite direction. The <basis> grammar tries to return development to where it began: declarative HTML the browser understands directly. This isn't nostalgia; it's a bet that declarative simplicity is more durable in the long run than toolchain complexity.

2 · The client at the center

Using alasql to query in the browser, filter="prp_… = '…'" at the <face> level, and the $bc.setSource() model for reactivity — all show that BasisCore pushes the weight of computation toward the client. The server is a data source; the browser is the render engine and even the query engine. This gives the architecture great independence from the server — but, as we'll see, it also moves the trust boundary.

3 · Distributed and edge-first

The cdn.json pattern plus a dynamic <base href> is an important architectural signature: a single switch point that, by changing one line, moves all static assets from one CDN to another. Alongside BasisCore Edge (the Docker container serving /server/trust/… endpoints), a picture emerges of a deliberately distributed architecture that refuses to be tied to a single host.

4 · Composability and modularity

From core="call" file="header.inc" at the page level to the Section Switcher and the three-layer Context API design in BasisPanel, the recurring pattern is breaking the system into independent, swappable pieces. This is the same logic that lets a team mount a v3 skin onto existing code without touching the TypeScript.

5 · Ecosystem coherence

The naming isn't accidental: BasisCore, BasisPanel, BasisTrust, BasisToken, BasisFly, BasisCore Edge. It builds a shared vocabulary. The Trust layer unifies authentication, the CDN unifies assets, and the <basis> grammar unifies how things are built. Coherence is the ecosystem's gravity — and it's exactly where the third question, independence or capture, is born.

Strategy — own the grammar, not the product

The strategy embedded in BasisCore fits in one sentence: instead of selling a product, establish a grammar.

This is the same platform game WordPress played with its hooks and themes, or Rails with its conventions. Once a grammar takes hold, the network effect begins: every developer who learns <basis core="print"> has made a cognitive investment in the ecosystem; every site built with the grammar is another unit of software mass; and every shared module raises the value of the whole.

The key difference from closed platforms is that the source is available to those who want it. That is a heavy strategic choice, not a side decision — and it changes the entire nature of how companies relate to the ecosystem.

Which companies is it for?

BasisCore wasn't built for everyone, and being honest about that raises its value rather than lowering it.

Can simplicity be a cause of insecurity?

The short answer: simplicity is not the cause of insecurity. But BasisCore's simplicity makes the trust boundary visible — and visibility must not be confused with vulnerability.

Let's be precise. When data arrives at the client via dbsource and is then filtered in the browser with filter="prp_97888 = 'video'", two facts are simultaneously true. First, it's a beautiful simplicity; the display logic stays declarative and readable. Second, the trust boundary has moved into the browser. And here lies the only real danger: if a developer relies on a client-side filter for access control, they have built a vulnerability. The <face> filter is a display tool, not a security boundary. Any data sent to the client has been sent — even if it isn't shown.

But note this is not a framework flaw; it's a misuse pattern. The correct rule is simple: authorization must be enforced on the server, inside the same dbsource. What reaches the client must already be data the user is entitled to see; the client filter is for user experience, not protection.

The subtler point: more complex frameworks often hide this boundary and lull developers into assuming "it must be secured somewhere." BasisCore does the opposite — it shows the boundary honestly. So the conclusion: simplicity doesn't create the risk; it returns responsibility to its proper place. The danger is not in the tool, but in the developer's over-trust of the client layer.

Independence or capture? The ecosystem's core tension

This is the deepest question, and it deserves the most honest answer. Does owning a dedicated web service, a dedicated network, dedicated software, and dedicated names keep companies inside a dynamic ecosystem — or does it take their independence?

To answer, we must accept that "dependency" is not one monolithic thing. It has layers:

1. L1Code and rights. Here, open source solves the problem. The company owns the code, can self-host, fork, and in the worst case continue independently. This is the fundamental difference from a closed SaaS: if the closed provider leaves, you've left too.
2. L2Knowledge and skill. The <basis> grammar is a specialized dialect. A team working with it has made a cognitive investment, and its hiring pool is narrower than React's. This is a kind of gravity.
3. L3Infrastructure. cdn.basiscore.net, BasisCore Edge, and /server/trust create operational gravity. Even when code is open, migrating off these has a cost.
4. L4Data model and conventions. How catid, properties, and naming conventions are structured forms a mental shape that takes effort to leave.

Now the honest verdict: open source turns "lock-in" into "gravity." That distinction is everything. Under lock-in, the company can't leave. Under gravity, the company can leave — but leaving costs in proportion to how deep it went. This is true of every powerful ecosystem — Rails, WordPress, even React. There is no leverage without a little gravity; leverage and gravity are two sides of one coin.

So BasisCore doesn't "take" independence; it trades it: a degree of autonomy in exchange for the compounded leverage of a platform. And because the source is open, the company always holds the option to exit — and that option is the difference between a partnership and a captivity.

But there's a strategic recommendation inside this. For BasisCore to stay a "dynamic ecosystem" and not become a "cage," that exit option must be kept real at every layer, not just the code:

• Data portability. The data model should be documented and standard enough that exporting out of the system is easy.
• A documented protocol. The <basis> grammar and Trust conventions must not stay arcane; full documentation turns the grammar from "scarce knowledge" into a "learnable standard" and keeps the skill-layer gravity healthy.
• Infrastructure plurality. Tellingly, cdn.json already has this philosophy in its DNA — switching CDN with one line means no single host owns you. Extend the same principle to Edge and Trust.
• A talent pipeline. Training and docs dissolve skill scarcity and break dependence on a single supplier of people.

The more open these four layers stay, the more the ecosystem becomes "dynamic" and the less it becomes "captor."

BasisCore's strategic identity

If the whole ecosystem had to be summed up as a single bet, it would be this:

The three questions are really three sides of one triangle. The target market is whoever finds this trade — control and ownership in exchange for adopting a bespoke grammar — worthwhile. Simplicity is what makes the trade attractive while honestly returning the responsibility for security to the server. And independence is a promise that holds only as far as open source actually translates into the ability to exit at every layer.

BasisCore, at its best, is neither a product nor a cage. It is a shared language that gathers companies into one constellation — while leaving the key to the door in their own pocket.