NOT

From triplescripts.org wiki
Revision as of 16:50, 15 September 2020 by Colby Russell (talk | contribs) (break out content into sections and emphasize that triple scripts differ from cloud-oriented IDEs)

Not a cloud IDE

There have been many attempts to move development into the cloud, and the quality of execution in those efforts has varied. But make no mistake: triple scripts run locally on your computer, just like the compiler binaries from conventional toolchains. Triple scripts are not about moving development to the cloud.

Triple scripts are about exploiting the fact that the browser is ubiquitous and its behavior is consistent enough across vendors that it can be targeted as a general purpose runtime that needs no installation or setup. We believe that because of the nature of the Web and what browsers are meant to be, their capability in running local software in a sandbox has been overlooked as people get sidetracked by the idea of simultaneously moving their computation to the cloud and/or offloading it to someone else.

(Note that while every triple script must at a minimum be able to run in the browser, this is merely part of the baseline that we establish; several considerations have gone into the triple script file format that make sure that a given triple script can run unmodified in other, non-browser environments.)

Not about NodeJS or JavaScript

See This is not JavaScript.

Not a panacea

Triple scripts are not intended to subsume everything in the world. The triple script invariants practically ensure that there are many use problems for which triple scripts cannot be the solution. You will never be able to write a chat client as a triple script, for example, (nor could you write the chat server that the client communicates with as a triple script).

It is a triplescripts.org mantra that Triple scripts are for everyone, but not for all things.

There is an entire industry and multiple markets that are being served by "traditional" fixtures of computing. The triplescripts.org group was explicitly chartered to serve the people and use cases that are otherwise underserved (and overburdened) by the traditional way that software is developed.

If you want to write an app that can do something that is otherwise impossible while at the same time maintaining the triple script invariants, or it's impossible without going against the overall philosophy of the triple scripts ecosystem, then you should of course still write your app—just not as a triple script. Similarly, if you want to write your app in a different language, let's say Clojure, or Haskell, or Rust, or C++, or for NodeJS, particularly because that other language has something that the triple script dialect lacks, then you should probably use those languages. (But in each case, you should still consider using a triple script for your build tooling.)

Cookies help us deliver our services. By using our services, you agree to our use of cookies.