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 (an agent for thin clients delivered as part of the HATEOAS architecture described by Fielding, 2000), browsers' capability in running local software in a sandbox has been overlooked—with programmers getting sidetracked by the idea of simultaneously moving their computation to the cloud or even offloading it to someone else entirely.
(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 JavaScript
The work of the triplescripts.org group is not oriented around promoting JS and certainly not about the NodeJS/NPM ecosystem. In fact, the triple script dialect is not even 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 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.)