Decisions, Decisions

Getting Started





Decisions, Decisions


JavaScript is here to stay. From the server to the desktop, from mobile to IoT, more and more applications depend on JavaScript and skilled JavaScript developers.

Unfortunately, demand for JavaScript skills consistently outpaces supply, a condition that's been true since the dawn of the AJAX/Web2.0 era.

In May of 2006, at one of the earliest JavaScript conferences, keynote speaker Scott Dietzen asked the audience "What's the hardest AJAX problem?" His answer? "Recruiting." Nothing in the past decade has changed that answer, in fact, in many ways the JavaScript recruiting problem is getting worse.

Most modern web frameworks actually increase demand for JavaScripts skills; some go further and add skill requirements for other languages like TypeScript forcing you to hire from an even smaller pool of qualified developers. Choices like these increase cost and risk.

The good news is there's a solution...the same one that allowed the web to grow to almost 5 Billion pages in 25 years. The answer? Authoring in markup, markup augmented by JavaScript, not embedded in it.

The popularity of Angular1's tag-aware design; experiments like Google Polymer; the W3C's WebComponent specification; numerous initiatives point to a future where applications are built in markup, a future that doesn't rely on expensive and elusive JavaScript coders, a future where you can drag, drop, and edit markup-based components to create new applications.

As fate would have it, we also gave a talk at that May 2006 JavaScript conference. In introducing TIBET™ 3.0 we showed how tags backed by object-oriented types essentially turns markup into a powerful macro language, one you can use to create desktop-class web applications with far less code.

TIBET 5.0 represents over a decade of refinement on that early vision - a fully-tooled, fully-supported, full-stack solution that lets you author complex applications primarily in markup.

Is TIBET right for my project?

Does your application require users to log in? Is it a back-office app? A desktop-class app? A RESTful single-page app? One of numerous applications you need to port to the web? Does it rely on XML-based services or data? Are you struggling to staff up?

If you answered 'yes' to one or more of those questions we invite you to install TIBET and apply it to a pilot project. We think you'll love it.

We built TIBET for business applications, applications users run as their primary task, applications whose users often depend on the keyboard and disregard the mouse, applications in service for years, applications with dozens or sometimes hundreds of distinct screens.

TIBET is not a silver bullet; it's not right for every project, nothing is, but we think TIBET can make a significant difference for business-class projects.

If you're exclusively targeting phones we'd recommend you consider frameworks that are focused specifically on mobile development. If you're targeting a broader range of devices such as desktop, laptops, Chromebooks, and tablets TIBET should work effectively and provide a good balance between performance and productivity.

How big is TIBET?

Why do you ask? ;)

Questions about framework size usually arise because accepted web dogma holds that the larger the framework the worse the user experience. Bigger -> Slower -> Worse.

With TIBET we like to make sure we're solving the right problem though, so we dug a bit deeper and "questioned the question" as we like to say.

Instead of assuming TIBET had to be "as small as possible" we asked why small mattered. Not surprisingly we found "small" is usually shorthand for "the application's initial screen needs to load fast enough the user won't hit the back button".

There are a lot of follow-up questions inspired by that answer though, so we dug deeper.

First up, we're loading an application not just a framework so shouldn't the question really be "By using this framework will my final deployment package load faster?"

Well now, that's a different question altogether...one that led us to ask the real question:

How might a framework's design help optimize load times?

Since we're starting with deployment package size is it better to have a large framework and less application-specific code or a tiny framework that requires more application code? What mix?

Is deployment package size really the only factor in load performance? What about HTTP overhead? Smarter caching? Other factors?

What about applications with a login screen? Can you show a login screen while the bulk of the code is loading in the background? How might that work?

What about loading the framework code separately from the application code? How does splitting the load between library and application impact our options?

We took all these implications into account when designing TIBET.

With TIBET we solved the real problem, the problem "smaller" is only one answer to, the problem of how to design a framework to balance initial load time with all the other issues that impact whether a particular framework is right for you. We think you'll be pleased with the result.

How fast does TIBET load?

TIBET uses a unique two-phase loader. TIBET library code loads from appcache in the background and your application-specific code loads on login success. The result is user-perceived load times for the TIBET library approaching 0ms.

Work is underway to optimize application-specific resource loading in a similar fashion, further reducing user-perceived load time and avoiding the trap where you artificially limit your application over worries about load times.

TIBET's unique design also means code loads and parses a single time during application startup regardless of how many times you redraw the UI frame.

As to specific times for the TIBET library...they vary. TIBET's packaging and rollup logic allow you to configure the modules you need, whether you want them to load on startup or at different phases of application execution, how minified they should be, etc.

To give you an answer that's as close to what you're probably asking though, TIBET's "base" package in current form loads sub-second on Safari and Chrome, slightly slower on Firefox. Again, these times happen in parallel with your user entering their login credentials and waiting for server authentication. Furthermore, the library almost always loads from appcache rather than over the wire, reducing HTTP/network overhead dramatically.

If you're working as a developer and loading the entire TIBET library, Sherpa, and test suite you will see startup times closer to the ten-second range. Keep in mind that in this scenario you're a) loading every available type and tag in the TIBET platform to support fully-dynamic development, b) loading a full IDE and all its code and resources, c) loading your application inside that IDE. In this case it's more apples-to-apples to compare TIBET startup times to those for other web development IDEs, not those of web applications.

What platforms does TIBET support?

TIBET Client:

We've engineered TIBET 5.x to focus exclusively on modern HTML5 browsers:

  • Chrome
  • Safari
  • Firefox
  • Edge (future)

TIBET also runs on Electron for use in Desktop application development.

The current version of TIBET runs PhantomJS 2.x for command-line test execution and support of TIBET CLI commands which rely on live reflection metadata. This functionality will be ported to an alternative headless platform in the near future.

TIBET does not currently support Internet Explorer or Edge. We plan to support Edge in a future release contingent on market share and customer demand.

TIBET Sherpa:

TIBET Sherpa is currently released as a Technology Preview. The preview edition is supported only on Google Chrome.

Support for TIBET's other target browsers will ship in stages after completion of the Technology Preview phase.

TIBET Server (and friends):

The TDS, TWS, and CLI are current supported on MacOS and common Linux variants.

TIBET's server-side components are currently being ported to Windows with an early 2018 release target.

Does TIBET integrate with other libs?

Yes, but it's largely unnecessary.

TIBET includes hundreds of function primitives and object-oriented types which work together in a fully-integrated client-side stack, eliminating the need for reverting to a costly and time-consuming à la carte approach to your development.

In addition, TIBET already embeds jquery's Sizzle engine and several other leading libraries such as bluebird, d3, forge, sinon, and syn while maintaining API isolation so we can update, evolve, and integrate new modules without impacting your development APIs over time.

If you feel there's a missing feature we'd encourage you to file a feature request. That way the entire community can benefit from a fully-integrated and supported module.

Does TIBET run on mobile devices?

Yes, provided the device has a compliant HTML5 browser implementation; HOWEVER, we've done no testing or tuning to ensure your mobile experience will be a positive one.

Our focus to this point has been on desktops, laptops, and Chromebook-class hardware, hardware optimized for data entry, not data consumption.

We'll be looking at packaging and tuning for mobile more closely beginning in 2018.

Does TIBET require plugins (Flash etc)?

No. TIBET is 100% Pure JavaScript.

Do I have to use the TIBET Data Server (TDS)?

Production TIBET is 100% server-agnostic, so much so you can run it without any server.

During development the Sherpa™ and TIBET's live patching functionality require the TDS to be running. You can configure the TDS to proxy to your actual server during development or make use of the TDS's simple mock support to decouple frontend and backend development.

Getting Started

How do I install TIBET?

You can install TIBET via either npm or git. For support you should be using npm-based installs. Full instructions for installing TIBET can be found in the TIBET README.

Are there tutorials for TIBET?

The TIBET Quickstart Guide will get you up and running in minutes. You can follow that up with the TIBET Essentials Guide to dig deeper into TIBET.

TIBET-related videos are available on the TIBET JS Channel.

Where are the API docs?

API documentation for TIBET is generated on-the-fly by the TIBET runtime system. This up-to-the-minute documentation is accessible via both the TIBET CLI and Sherpa. TIBET's tools will also generate API documentation for your application code provided you follow TIBET's coding standards with respect to comment placement and format.

The tibet apropos and :apropos commands let you query for functionality related to one or more terms. These are a good starting point.

tibet apropos <topic>

The tibet reflect and :reflect commands let you focus on a particular object or method, or reflect across the currently loaded code.

tibet reflect [<target>]


Why CouchDB? Why not {{xyz}}?

First, let's point out that TIBET is not limited to use with CouchDB.

You can use TIBET with any HTTP or WebDAV server, and couple that server to any database backend you like. If you're running the TDS it's relatively easy to leverage a number of LevelUP-compatible storage backends for example.

As to why we prefer CouchDB? REST and Replication.

CouchDB has native HTTP support and native JSON data transport. That makes it a perfect high-performance REST data server, the kind of server optimized for a framework like TIBET.

Native HTTP support lets us access CouchDB directly from the client, from the TDS, from the TIBET CLI, from curl, or other HTTP-compatible tools without extra overhead.

CouchDB's replication protocol lets us easily sync data between the client (via pouchdb), the TDS, CouchDB instances, or any other server implementing that protocol.

The CouchDB changes feed lets us support collaborative real-time applications through TIBET's built-in signaling and data binding features and helped us create the TIBET Workflow System.

No other storage product currently offers us that level of power and flexibility.

Can I use TIBET with {{xyz}} instead of CouchDB?


You can use TIBET with any HTTP or WebDAV server, and couple that server to any database backend you like. LevelUP support is easy to integrate to help make with other storage servers easier to manage.

How do I create a TIBET+CouchDB project?

Type the following, replacing {{appname}} with your desired project name:

tibet clone  --dna couch

See the TIBET+CouchDB guide for a complete overview of TIBET+CouchDB.

Do you offer CouchDB support?

Yes and no. We use CouchDB ourselves both with and without TIBET so we have some experience with CouchDB. That said, our support is officially limited to use of TIBET, not CouchDB. If you have a support contract we'll obviously do what we can to help you be successful with your project but we can't offer true support for a product we don't control.


What license does TIBET use?

TIBET is Open Source under the OSI-approved Reciprocal Public License (RPL).

Our decision to use the RPL is based on a common business model in today's Open Source world where your decision to keep source code private comes with a small fee.

GitHub, Travis-CI, Sauce Labs, npm; the Open Source market has numerous pay-for-privacy services. TIBET offers the same choice: public or private? With TIBET you can open source your code or purchase a privacy waiver under a per month, per year, or perpetual agreement.

No waiver is required until you 'Deploy' your code as that term is defined in the RPL. Research and Personal Use are also exempt. You're free to explore or prototype without concern. You only have to start sharing your code when you start deploying your code.

Is TIBET Open Source?

Yes. TIBET's license is approved by the Open Source Initiative (OSI), the organization responsible for maintaining the official definition of the term "Open Source".

Is TIBET free (as in beer) ?

That depends on you. If you open source your code then TIBET is free of cost. If you want to keep source code for a particular application private you can purchase a privacy waiver. See http://www.technicalpursuit.com/license.xhtml.


What kind of support do you offer?

TIBET support plans focus on response time, there are no off-hours or incident limits.

Support is initiated by filing an issue using any GitHub account associated with a support contract. When you sign up for TIBET Support just supply an appropriate GitHub ID and use that account to file issues. The clock starts when your issue is filed.

Is there phone support?

All support is initially triggered via the GitHub issue tracker. We escalate to chat and phone at our discretion to ensure your issue gets resolved as quickly and efficiently as possible.

How do I file a support ticket?

Visit our Issue Tracker.

We recommend searching for existing issues first to avoid duplicates. If you find an existing issue add a comment and any additional detail you can to help us reproduce the problem. Create a new issue if no existing issue seems to fit.

If your user ID matches a supported user ID you'll receive a response in accordance with the terms of your current support contract.


What is your business model?

If you're an enterprise and you're worried about the stability and longevity of the platform and vendor you choose, well, that's good :). We've been in business since 1999 and we're still here, still keeping TIBET fresh, current, and powerful.

We generate revenue in three ways: TIBET support contracts, TIBET privacy waivers, and custom TIBET development. As we bring our Cloud-based services, the Tag Store™ and TIBET Summit™, online we also anticipate revenues from those sources.

Rest assured, we're here to stay.

Why did you call it TIBET?

While discussing names for what would eventually become TIBET, Bill Edney, TIBET's co-author and evangelist, mentioned that China didn't call the region traditionally known as 'Tibet' by that name. He suggested we call our library TIBET in the hope that if it became popular it would continue to bring awareness to the ongoing situation in Tibet.

Note that the product name is always presented in full-caps, e.g. TIBET.

We recommend visiting The International Campaign For Tibet, the Tibet House Trust, and the Tibetan Village Project for information on how you can help Tibet.

The TIBET logo is the word 'Tibet' in Tibetan script.


Contact us for more information or to discuss how we can assist you.