Try TeXmacs in your Browser via WebAssembly (Mogan Fork of TeXmacs) | Hacker News Reader

Try TeXmacs in your Browser via WebAssembly (Mogan Fork of TeXmacs)

yufeng-shen.github.io

85 pointsamichail32 comments

Open articleView on HN

Here is the pull request to make Mogan Editor (the fork of GNU TeXmacs) work on Browser via WebAssembly:

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.

There is only one commit for the WASM port. We haven't made it public.

How hard if possible would be enabling open/save?

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.

I'm not familiar with the details. But I do think it is not hard. Because we can save it to github via rest api.

As I explained, there is only one commit for the WASM port. The WASM port just compiles.

Please wait us to make it better!

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.

Try looking at and editing Help => Manual => Mathematical formulas.

Off topic: Why isn’t VS Code using WebAssembly?

Is it due to interoperability with the DOM?

Is that the stated goal of Zed.dev then, to create the next gen “vs code” by developing it in Rust (which can compile to WASM)?

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.

VSC is web because it was created for the web. It was turned into a desktop program later

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

If not easy then certainly most widespread and "common" amongst the current developer population

The work on VSCode began before Atom appeared. This talk by Erich Gamma about the history of VSCode is very interesting: https://learn.microsoft.com/en-us/events/visual-studio-code-...

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.

Huh, my mistake. I guess I misremembered it

RDP is the Windows Remote Desktop Protocol that was in use for decades before VSCode; VSCode's own remoting doesn't use it.

I'd say that, in addition to LSP, the other big thing that came out of VSCode is DAP: https://microsoft.github.io/debug-adapter-protocol.

My bad, you're right. I confused myself thinking RDP means Remote Debugging Protocol.

IIRC It was "web first": See the presentation from Erich Gamma: https://learn.microsoft.com/en-us/events/visual-studio-code-... approx. minute 6.

Sorry but Atom lovers have an habit to distorce facts.

"VS Code an overnight success...10 years in the making with Erich Gamma"

https://learn.microsoft.com/en-us/events/visual-studio-code-...

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.

Edit: faulty memory at it's finest. I was wrong

Sorry about that, it just so happens it is common meme in Atom community to bring this up.

> web tech is arguably the easiest to use for building UIs

...for an ecosystem full of web developers.

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.

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.)

That doesn't follow. Client/server architectures existed long before the Web did.

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.

Obligatory link to Gary Bernhardt's "The Birth and Death of Javascript": https://www.destroyallsoftware.com/talks/the-birth-and-death...

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.

Reply on news.ycombinator.com