Creating something in the scope of Jupiter is not trivial.
You do have a few nodejs/typescript/javascript kernels that work fine, so I don't see the point for rewriting Jupiter in node specifically for any reason.
In any case, maybe creating something for the browser only is easier because JS is native, but still I wouldn't call it "pretty trivial". For this use case (and more) you have projects like
You're overlooking the power that a preconfigured REPL with a persisted canvas integrated with markdown brings to the table.
It is a really powerful toolset, and building your own environment from separate parts is not trivial; so having it preconfigured in a standard way that others can reuse is no small matter.
I prefer online notebooks with a functional-reactive behaviour, such as ObservableHQ (which is JavaScript-based, rather than python); but Jupyter was the first popular one, so it hit hard.
You might be misinterpreting me here. I’m not dismissing the utility. Quite the contrary, I’m saying that it wouldn’t be terribly groundbreaking or challenging to implement compared to some other green field problem. Although at this point I do agree that trivial was the wrong word.
Observable looks cool, but it doesn’t seem portable. It really bums me out that so much of the JS ecosystem is so sheerly commercial in this way. Sometimes I don’t understand why this is like this compared to the Python ecosystem. It’s not that I’m cheap either. I’ll happily pay for things that are properly monetized and provide a good value for my time. This doesn’t seem like it.
You might like tslab. It allows you to have the full notebook experience with either JavaScript or Typescript. My day to day is data analysis. JS/TS runs circles around pandas and you aren’t constrained to vectorized operations. If there were a suitable replacement for matplotlib I would leave python behind altogether.
