Has anyone tried compiling FB from C to JavaScript?

[anonymous1337]

Using ex: https://github.com/kripken/emscripten

Which will utilize ASM.js.

http://kripken.github.io/emscripten-site/

[marcov]

What would be the point of that? Even plain file I/O would not be transferable.

[anonymous1337]

That's assuming what you're interested in is file I/O to begin with. I mean, you could write an entire NES emulator in FreeBASIC and compile that to JS if you wanted (probably).

ASM.js + WebGL sounds like a pretty sweel deal to me, and that'll work in-browser. Beyond that...

If FreeBASIC could compile to desktop/server-side JS, then it could be used in conjunction with V8 or Node to build server or desktop applications as well. In that case, you would have file I/O and all sorts of other neat stuff (read: anything you want), although at least a partial rtlib port to JS would probably be required since your underlying framework would likely be Node...

I'm not sure that's true... After all, Metro apps are JS-based.

At the very least, FreeBASIC could be used to write JavaScript modules which could be imported into other JS projects, whether that's in the browser or on desktop / server.

[marcov]

That's assuming what you're interested in is file I/O to begin with. I mean, you could write an entire NES emulator in FreeBASIC and compile that to JS if you wanted (probably).

ASM.js + WebGL sounds like a pretty sweel deal to me, and that'll work in-browser. Beyond that...

It sounds like a toddler stacking bricks regardless of form to me.

If FreeBASIC could compile to desktop/server-side JS, then it could be used in conjunction with V8 or Node to build server or desktop applications as well. In that case, you would have file I/O and all sorts of other neat stuff (read: anything you want), although at least a partial rtlib port to JS would probably be required since your underlying framework would likely be Node...

This begs the question is WHY?!? (other than slowing down your application by about a factor 80)

Personally, a FB to Malbolge compiler would interest me more. It at least has some academic appeal.

I'm not sure that's true... After all, Metro apps are JS-based.

Most metro apps are C++. Yes, it allows JS, but most are native.

[anonymous1337]

A factor of ... 80?
http://benchmarksgame.alioth.debian.org ... script.php

Not quite :)

Personally, a FB to Malbolge compiler would interest me more. It at least has some academic appeal.

I honestly don't think it matters much. If it isn't "that hard" to do then having that option available isn't going to hurt anything. Why I would want to do it? Have FreeBASIC in the web browser and able to talk to JavaScript. Or have Node modules written in FreeBASIC.

That's good enough for me. I work in web constantly and have no intention of bending over backwards to make things work with FreeBASIC, but if FreeBASIC could work with what I regularly use, that would be seen as both convenient and interesting.

[marcov]

A factor of ... 80?
http://benchmarksgame.alioth.debian.org ... script.php

Not quite :)

that was the original value before the V8 and similar tracing engines compared to C. But keep in mind that those benchmark are mostly single file programs with high locality.

That's good enough for me. I work in web constantly and have no intention of bending over backwards to make things work with FreeBASIC, but if FreeBASIC could work with what I regularly use, that would be seen as both convenient and interesting.

Ask yourself why C and C++ are not already regularly used to generate webapps, and you'll find your answer. You can create a path on the back of a beercoaster, but that doesn't make it workable.

[anonymous1337]

That's good enough for me. I work in web constantly and have no intention of bending over backwards to make things work with FreeBASIC, but if FreeBASIC could work with what I regularly use, that would be seen as both convenient and interesting.

Ask yourself why C and C++ are not already regularly used to generate webapps, and you'll find your answer. You can create a path on the back of a beercoaster, but that doesn't make it workable.

It's honestly just something I'd like to do or see happen, not something I can argue a massive technical, as opposed to preferential benefit for.

I think the lack of threading capabilities in ASM.js is a problem. So is a lack of other general APIs. I don't know what the limitations of using something like enscripten is. One benefit of the JS environment is that it's sandboxed when NPAPI isn't used (it's being widely deprecated anyways).

ASM.js is more like compiled code, so writing raw ASM.js isn't necessarily something you want to do. If you do want JS as the target, for whatever reason, then you'll likely be compiling to ASM.js via some other tool. But it's not likely you'll be writing in JavaScript from the get-go.

So I think the question is whether or not ASM.js and WebGL will catch on. If they do, then "web browser" (which could be an app on a mobile device also) becomes a target. It's currently the most universal target for user-facing applications that there is. I think it's at least worth thinking about, even if not in the context of FreeBASIC -> C -> ASM.js