Running JSweet in the browser + Code for the compilation server

[tomitrescak]

Hello, just bumped into your amazing project and was wondering about a possibility of packing the transpiler into applet and running it in the browser. We have built a system for our students that teaches them Java. This system runs in the browser and uses our own transpiler from java to typescript and then we use MS's typescript to javascript compiler. This process is quite tedious and error prone, moreover our transpiler is not very robust.

I was wondering if it would be possible to pack your transpiler into applet and run it on the page to do transpilation on client side? If so, how do you reckon we should approach that?

Thanks!

[tomitrescak]

More I play with the capabilities of this project, more amazed I am. If we could run this in the browser, that would be amazing. Students work only with basic java and the base library provided by us. So no difficult configuration would be necessary, only the most needed candies.

[EDIT] - I see an issue that most of the current functionality is File based, when for what we need it would be more "in-memory"

Also ... do you think it would be possible to convert the whole project into javascript and run it natively in the browser ? As I said, I need only core java functionalty.

[renaudpawlak]

Hi Thomas! It is cool that you have developed a similar transpiler (in JS if I understand). Our choice was to rely on a robust Java parser (javac). That's why we developed JSweet in Java. Running JSweet in a browser is so far "achieved" through a web service used by our sandbox (http://sandbox.jsweet.org/transpile, which is public and you can use it if you want). We developed this sandbox for our own needs and so far it is not Open Source, but actually, if people are interested, we could make it Open Source. That would probably be a good idea because people would be able to set up their own complication server with their own environment (candies). FYI, I am a former teacher in France and a colleague of mine is currently using the JSweet web service to teach Java to students in a Web browser (same idea as yours).

Regarding entirely running JSweet client-side, that's another story ;) I would not follow the Applet lead mainly because applets will be soon deprecated: https://blogs.oracle.com/java-platform-group/entry/moving_to_a_plugin_free.

IMO, we have two ways to do it.

1. We run JSweet in the browser using a Java VM that can run in a browser. For example the one of https://dukescript.com/ (note that VM-based technologies are very different from JSweet, but I will not elaborate here). In theory it would be possible, but I am afraid of the performances.... I have never tried it so I cannot tell yet.
2. We compile JSweet with JSweet and generate a JavaScript bundle (as you suggested). That would be my favorite option but it requires to get the source code of javac and compile it with JSweet. It is most probable that some libraries will be missing. We can then also compile them with JSweet, or create a bridge (i.e. a JSweet implementation of that library using an existing JS library that does something similar... a wrapper if you prefer).

In any case, both solutions require some work and I think that it would be more realistic for now to Open Source the JSweet sandbox so that people can tune it for their own use.

[renaudpawlak]

merged with #125

[tomitrescak]

Hi, thanks for your reply! I've spent pretty much the whole day trying to understand the complexity of bringing this into the browser. And you are right, the biggest effort is in rewriting and recompiling the javac classes. The sources are online so that is not a big issue, it's just quite a lot of work. If you will release the sandbox I will really appreciate that.

Concerning the sandbox, there are couple things that pop in my head, that should not be too difficult to do, but I do not know where to start:

The compilation process is a bit "slow" due to calling the tsc process from the disk. Yet, tsc can work in the browser, si I do not need the JS. As a result, is it possible to compile only to TS and without using disk files? Just specifying string, returning TS string. I tried with in-memory file system but I did not get very far.

Thanks!

[renaudpawlak]

The sources are online so that is not a big issue, it's just quite a lot of work. If you will release the sandbox I will really appreciate that.

I'll do my best to make it quick :)

The compilation process is a bit "slow" due to calling the tsc process from the disk. Yet, tsc can work in the browser, si I do not need the JS. As a result, is it possible to compile only to TS and without using disk files? Just specifying string, returning TS string. I tried with in-memory file system but I did not get very far.

Hum... that's a neat idea. You are totally right, the JSweet performance bottleneck so far is running tsc as a command (you must see it as a temporay hack and will be removed eventually). In the context of the sandbox, I am pretty sure that your idea is good and feasible, i.e. just return the TS code and use an in-browser tsc to finish up the compilation. You would need to have the candies d.ts files, but that's not a big issue since they are publicly available.

That said, I would rather take some time looking on how to optimize the JSweet compilation process (rather than optimizing the sandbox only). I would like to achieve something similar to Palantir's excellent TypeScript plugin: https://github.com/palantir/eclipse-typescript. What they do it that they start a Node.js process with tsc and use it as a compilation server. They call it through a Web Service layer. Of course, it is much faster than what JSweet is currently doing and it would speed up JSweet compilation time by x3 or even more! On the paper it would be simple to switch to that technique, but, as usual, it requires some work ;)

[tomitrescak]

@renaudpawlak I have the code that accepts TS code as script and outputS compiled JS along with all the errors. This runs natively in the browser. You can pretty much take that code and throw it in the Nashorn (https://dzone.com/articles/how-java-8-handles-javascript) and run it in memory without Node.js. But maybe there will be some issue, but as far as I see it, there should be none.

[renaudpawlak]

Right. That's also a good way to do it. It was also suggested to use a bridge to V8: see issue #5.
Is your code available in Open Source? That could be a good start for implementing this.

[renaudpawlak]

It looks that running TypeScript with Nashorn is not as straightforward as we could think it should be... microsoft/TypeScript#1789. J2V8 may be simplier...

[tomitrescak]

Shame about Nashorn. Anyways, the compiler is open-source available here: https://www.npmjs.com/package/typescript-compiler

That package is not mine but works flawlesly on server. All I did is a slight modification to make it run in browser (I preload lib.d.ts via AJAX call and serve it from the request instead of the disk).

[renaudpawlak]

Hi Thomas, like we talked about it, I open sourced the sandbox and the server: https://github.com/cincheo/jsweet-http-server. I hope you will like it. Don't hesitate to ask if something is unclear.

[tomitrescak]

Sweet! ;) Thanks a lot!

[renaudpawlak]

FI, in-browser support is not doable in the short-term. Many other things to deal with first. Also, I have tried J2V8 for perfs and I think that it will work very well. No time so far, but that's will eventually be happening :)