It does not work out of box because webassembly cannot directly access local file system due to security reason. But I think we can use some api to talk to JavaScript. It's just an early experiment, more work needs to be done.
webasm do not have access to the OS, one need to specialise TeXmacs to work better in the browser. For the moment this is just an early experiment which shows some hope.
It is one thing to port software, initially created in a different language, to webassembly. The benefit is obvious, because it can now be distributed over web.
For VSCode, the first question to ask would be, why is it built with web technologies in the first place.
VSCode was build with web technologies because this allows the “Remote” feature to work – by using a client and server internally, you can put the server on a different device and transparently develop on that device as long as there is a suitable method of forwarding internet traffic. (This was the intent for the IDE from the beginning.)
It starts to follow as soon as one of the participants are using VSCode in their browser.
It's perfect for example for programming lesson. A way to provide the students with a fully working environment available immediately via 1 click on a link, guaranteed to work on any platform - even iPads.
No, I mean that remoting doesn't depend on Web technologies. (Not even the VSCode remoting implementation does, AFAIK.) So it doesn't follow from "VSCode does remoting" that VSCode is built on that stack.
I get what you mean. I am saying remoting becomes much more useful if the client automatically works on every platform including tablets and even mobile phones.
That's not true. It was essentially forked from Atom which was built as a desktop application first. It just so happens that Electron makes it easy to run just about anywhere and web tech is arguably the easiest to use for building UIs
When Erich Gamma joined the Visual Studio team in 2011, he set on creating a coding platform for the web, starting with the Monaco editor. This was followed by efforts to bring an IDE to the browser such as Monaco Workbench and Visual Studio Online IDE. However, those didn't attract many users, so the team decided to pivot to the desktop with Project Ticino using Electron by GitHub, and thus born VSCode as we know today. Arguably, this pivot has been wildly successful, from which blossomed many nice technology such as LSP, RDP, and remote coding. It is only natural that they now work on bringing VSCode back to the browser, completing the most transformative revolution in code editor for the past 10 years.
Bold of you to assume that I am an Atom fan. My understanding was the Atom happened then Electron was extracted as the core then VS Code was built on top of that to fill the gap. Given that VS Code only moved in to the browser very recently, it didn't make sense to me to claim it was built for the web.
I really want native apps to be as simple to work with for UIs but it's just not. Qt is great but still more cumbersome and I'm not aware of anything better that gets you close to the development speed and flexibility given by HTML and CSS.
Very honestly: please let me know if there is anything. I really would love to build more native apps without fighting the UI system
What do you mean, fighting the UI system? Non-native looking UI elements? If that's the case, I have to agree with you, actually. For web-like desktop GUIs, web technologies seem to be the fastest vehicles, unless someone releases an updated Display PostScript…
Other than that, I've had way faster dev experiences in Delphi, Cocoa, SmallTalk and Tk. Mostly because you don't have to reinvent the wheel.
That is exactly what I mean. There's benefits to using native UI elements but they really limit your creativity. It's also difficult if you're building something for multiple platforms but you want to make sure that you have a consistent experience.
Possibly the most insightful and accurate talk I've seen regarding the web stack, and it's from 2014 - that's eight years ago! I keep on coming back to it year after year. Even the names used, "asm.js" and "wasm", are mostly the same.
https://github.com/XmacsLabs/mogan/pull/373
We just make it compile based on mgubi's work. And haven't started further work.
It seems the TeXmacs documents are already rendered in a nice way. But most functionality is still not available.