Not a cloud IDE
There have been many promises about the future of cloud computing, including attempts to move much of software development off programmers' local machines and into the cloud, often including some attempts at Web-based IDEs, but the quality of execution in those efforts has varied. Make no mistake: triple scripts run locally on your computer, like conventional compilers do, even though one of the preconditions for a triple script is the ability to run it in the browser. This is motivated by the ability to treat the browser as a reliable, baseline runtime target, but triple scripts are not about moving development into "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 the general focus on thin clients, browsers' abilities to act as a sandbox for software that is run locally has been overlooked—with programmers getting sidetracked by the idea of simultaneously moving computation to the cloud or even offloading it to someone else entirely. Underpinning the philosophy of triplescripts.org is that computation can be kept on the local machine, but software development strategies be tweaked to target the general purpose runtime that essentially everyone has already adopted, instead of demanding the separate download, installation, and/or maintenance of opinionated runtimes, interpreters, or build toolchains associated with languages like Python, Ruby, Go, Java, C#, Bourne Shell, etc. We have a common, ubiquitous substrate now—so let's put it to use.
(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 a panacea
Triple scripts are not intended to subsume everything in the world. The triple script invariants practically ensure that there are many 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 a client should communicate with as one, either).
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 find that the triple script paradigm is overly restrictive, for example that it is not possible to write the program you want while at the same time maintaining the invariants demand of you as part of your intention to author and distribute triple scripts, or it's impossible without going against the overall philosophy and community values of the triple scripts ecosystem, then you should of course still write your program—just not as a triple script. Similarly, if you want to write your app in (let's say) Clojure, or Haskell, or Rust, or C++, or for NodeJS, particularly because doing so affords you something that the triple script dialect lacks, then you should probably write your program in the tradition considered normal for those communities instead of trying to make triple scripts work for your use case. (But in each case, you should still consider using a triple script for your build tooling.)