Aerilius is correct. It was rewritten into C++. That way it can be used on all out platforms if needed. (And I wasn’t doing that conversion - I just consulted.)
Personally I prefer extensions to remain extensions in general. They are more flexible to maintain and update. And open an extension provide specialized functionality that does’t apply widely. But there are some which is generic enough to justify adopting into SU itself. SI is one of them.
Crossing fingers that Weld will be integrated in the core as well
I would like to bring back some attention to this thread.
Any updates that could be shared?
In SketchUp for Web, there are some JavaScript objects exposed to the global/window object. They are unfortunately incomplete and do not even make up an “unofficial” API. Some years ago, I was able to draw a face from the JavaScript developer tools. Then I wanted to connect my Space navigator and make the Gamepad Web API events move the camera but SketchUp for Web did not expose any functions for that.
Whenever I looked again into it, nothing has changed unfortunately.
I don’t know what is holding them back, but I don’t think it should be fear about two incompatible extension ecosystems: Once there was a JavaScript API, the existing (Ruby) extensions would not be available for a long time, or developers would create new extensions that won’t ever become available for the legacy (desktop) SketchUp.
But with Web Assembly, the languages can be bridged, basically the language does not matter. Still, having the same interface is what matters, but that’s the whole point of an API?
There is even a ruby-wasm project, so Ruby code can be made available to SketchUp for Web, without that developers actually need to rewrite all their code. And an extension API that can be targeted through WASM could then also become the major supported API for the desktop, replacing the Ruby API while staying compatible.
When can we have it? 
I don’t think we really even need ruby in the web version. Even in SketchUp desktop developers are already required to use JavaScript and html (for UI). I don’t think most developers would grumble about doing everything in JavaScript instead.
Personally I’m not a fan of JavaScript and would really dread the idea of porting, then testing, over 20,000 lines of Ruby code, developed over the last 5 years, to JavaScript. Even if that could be done efficiently, the idea of subsequently maintaining versions in both languages seems completely unfeasible. The development would necessarily diverge and one or other product would probably fall behind. At present it makes more sense to focus on the desktop version because that is where the paying Pro users are.
I can see there may be some benefits to having the same language for processing the model and the UI, so giving a more direct connection and removing the asynchronicity, and opening-up opportunities for more integrated UI elements.
But can JavaScript really replace Ruby for the bulk of the work processing the model? Is it as full-featured as Ruby? (It has always struck me as a rather bodged-together language, but maybe I am not doing it justice as I only do what is necessary for the UI and not any real data processing)
To me, developing for both platforms only seems feasible for either very small plugins or development by larger companies that can afford to have dedicated developers for each version.
What it may do, is force more of the complex plugins to move towards cloud-based processing, so the plugin itself just provides a front-end and more or less the same service can be offered on both platforms.
Anything is better than nothing. I wasn’t a fan of ruby when I first saw it. Looked like Greek to me. I understand it may not be feasible to develop extensions for both platforms. JavaScript would have some limitations especially when dealing with the file system, but that is a browser security thing, and not specific to js.
correct, that is a browser thing.
Javascript is already pretty mature outside the browser, too. See: node.js
Actually, I use JS a lot outside of the browser, to do all sorts of automation, like quickly setting up a webserver, or even “building” my SketchUp extensions (things like combining everything in one file, changing the version numbers, removing some constant definitions from the sources, …)
Regarding reading a file: https://nodejs.dev/learn/reading-files-with-nodejs
const fs = require('fs')
fs.readFile('/Users/joe/test.txt', 'utf8' , (err, data) => {
if (err) {
console.error(err)
return
}
console.log(data)
})
JavaScript is more than 20 times faster than Ruby in certain cases due to its highly optimized engine.
I’ve not seen a way to make Ruby for a web-app compatible with the Ruby we ship with SketchUp. ruby-wasm is built on mruby - which is not the same as your vanilla Ruby. You don’t have all the features and the same stdlib.
There’s also technical challenges with running inside of a browser - which sandbox everything off from the system. you can forget file and system access like you get in the desktop app - that’s all locked down from within a browser.
1:1 compatible API on the web with the existing Ruby API on desktop would be great - but so far we’ve not found any feasible way of doing that.
That might not make too much of a difference for your typical SketchUp extension, as you’re calling into a thin wrapper on top of our C++ code. Most bottlenecks that people are running into is the underlying logic in SketchUp, not in Ruby itself.
Yes and no… an extension will always do more than just calling the sketchup api methods. It will do calculations based on data it gets from the api, iterate enumerables, check if a hash contains a key etc…
In one extension I made I had to calculate for a lot of point3ds if they are very close to each other to detect “touches”. Not too special, you iterate all of them, and iterate again starting at i+1 and see if they (almost) match.
The very same code, in Ruby, took more than 60seconds. While (ok ok, not javascript) making a .net assembly, passing all points to check as a json array (and thus doing serialization in ruby), deserializing that json string in .net and checking for matches, was like 2 to 3 seconds.
In the end I shipped the extension with a .net executable. Now… I do understand that this still might have to do with the sketchup api then, since in ruby I used a Geom::Point3d where in .net I quickly made my own point3d class.
Atm, I am creating something that does write binary files. Also pretty slow in comparison to writing the same file in .net
Not that I do not like ruby though, but for some reason I have always looked for ways to do heavy things in other languages, and shipping that with the extension, giving other issues sometimes 
Yes, I had the same issue in Vertex Tools. However, most extensions we see going through Extension Warehouse reviews are not in this category and do more than well enough in pure Ruby.
I mentioned this because often we see people ask for an API in another language - with the assumption that everything would be faster. Same thing we saw with request for 64bit SketchUp - the expectation of the ask didn’t fit reality.
I agree with that.
Also, please notice that…
…is not my wording, but a quote from the website I linked.
The good news is that C# can already be run on Wasm. There is currently no direct C# to Wasm compiler. However, the current approach is to compile the mono runtime along with CIL assemblies in to Wasm bytecode. This allows for existing C# code to be run on Wasm inside the browser. More detail can be found in the mono-wasm Github repo.
So I’m wondering if C# would be a better development language for the SU4Web platform ?