Low Code / No Code

Low Code / No Code

Three code-reduction concepts differentiate TIBET:

We think these concepts change the nature of modern app development.

Before we explain why, let's take a quick look at Low Code / No Code in general.

The Cliffs of…, or The 80/20 Rule revisited.

Low Code / No Code tools have always offered early success. They give good demo.

Teams get quick results with the first 80% and think "We've got this!"

The reality? There's a deep, wide chasm between 80% and DONE.

That last 20% is the custom part, the tricky part, the part that inspired you to build a custom application to begin with. That last 20% is the metaphorical "red zone" of coding.

In the red zone, true no-code tools tend to hit a wall. Once you reach the edge of their feature set there's nowhere to go. You can't code through it, it's a no-code cul-de-sac, a garden of walls.

Most low-code tools fall off a cliff. Once you reach the edge of their feature set you fall from high-level drag-and-drop to low-level code with no layers in between. It can be a long way down.

TIBET is a Low Code solution without walls or cliffs.

Highly-layered and fully-integrated, TIBET eliminates walls and cliffs by inverting the typical 80/20 mix of code-to-markup most modern frameworks impose on development.

The 20/80 Rule(s)

TIBET is built to deliver on what we call our 20/80 rules:

  • no more than 20% of your staff should be creating components,
    the other 80+% should be consuming them as markup.
  • no more than 20% of your application should be written in code,
    the other 80+% should be written primarily in markup.

The 20/80 Rules led us to our three key concepts:

Our focus on these concepts is what differentiates TIBET.

Is there still coding? Absolutely. But it's coding done by a small team producing components the rest of your enterprise can use via pure markup.

By ensuring our component consumption and component creation models leverage markup we were able to eliminate the gap between pre-built and custom components.

Engineering a new breed of IDE allowed us to shift the development focus from code to markup resulting in a dramatic shift in workflow and productivity.

Authoring Pyramid

The Authoring Pyramid

The idea behind TIBET's authoring pyramid is simple: align the skill requirements for TIBET projects with the distribution of UI, application, and framework-level skills in the market.

If there are ~100 HTML/CSS devs for every ~20 mid-level JavaScript devs for every 1-2 JavaScript gurus, your projects should require the same skill distribution. Aligning your tech choices with the hiring pool simplifies project resourcing and reduces risk.

With TIBET, the majority of your team consumes and connects markup-based components; a much smaller group builds components whose consumption model is pure markup. Our team supports yours at the framework level. That's the authoring pyramid in action.

Replacing today's 80/20 code-to-markup mix with TIBET's 20/80 mix scales better.

How did we get to a 20/80 mix? We put markup first, code second.

Markup First

Markup-First Authoring

At last count there were over 6 Billion-with-a-B web pages. Imagine that.

In the last 25 years humanity has collectively authored Billions of pages.

Now imagine if we had to use JavaScript or TypeScript with modules, classes, fat-arrow functions, type hints, Promises. How fast would the web have grown? … Exactly.

Markup came first. JavaScript was added to augment markup, not replace it as the primary authoring format. We built TIBET around that concept.

In TIBET, your application looks more like this:


…and less like this (yes, it's real project code):

/* @flow */
"use strict"

const _ = require("lodash")
const path = require("path")

module.exports = function doSomething(
  proj/*: proj$internalApi*/,
  options/*: {
    code?: string,
)/*: Promise<Object>*/ {
  options = options || {}

Migrating to technologies resembling the latter is, quite frankly, going in the wrong direction. It makes everything: hiring, coding, maintaining, and tooling, more error-prone.

Markup-Driven Tooling

Markup-driven Tooling

Speaking of tools…

TIBET's IDE, the Lama, is a real-time, markup-driven IDE.

What does that mean exactly? A whole lot of awesome!

Outline Mode

Using Lama you can:

1) Create new tags "out of thin air". Drag out a blank tile, drop it, and TIBET renders a placeholder. Using Lama you then teach TIBET how to work with your new tag, how it should look, how it should behave. If code is needed it's structured OO done in method-sized bites, in-situ.

2) Create new tags by grouping existing ones. No coding. No adjusting build files. The new tag is created, imported, and replaces the original tags instantly.

3) Adjust tag behavior in markup. Change its look, feel, controller, event triggering, data bindings, and more directly in markup, reducing the need to access component source code.

The Lama handles these actions and more…with zero reloads.

Most web platforms reload the UI whenever they need to bring in new code, style, or markup. As a result everything flushes and has to be re-parsed, re-fetched, re-rendered. Avoiding side effects and delays requires additional coding and effort.

TIBET's design allows it to bring in new resources without page reloads. TIBET can patch in new code, new style, new tags all without a full reload. The result is fewer side effects, fewer delays, and faster development.

Three code-reduction concepts distinguish TIBET

Three concepts we think change the nature of modern app development:

The authoring pyramid
Markup-first authoring
Markup-driven tooling

With these concepts as guideposts we've created a Low Code / No Code platform without walls or cliffs; a platform that lets you build applications in a whole new way.

We invite you to give TIBET a try. We think you'll be pleasantly surprised.

Try TIBET!The Desktop-to-Cloud Platform™