Slashdot Mirror

> Scripting languages, basically do not do threading, of any kind, at all. They're too slow to synchronize across threads, which makes invoking threads inside them fruitless

Bullshit. You CAN do asynchronously loading of assets with JavaScript.

From d3wasm

I did a couple of changes to the idTech 4 engine in order to be able to start the game before all the data have been loaded. So, along with the initial 5MB executable download, there is a first 15MB download to fetch only what is necessary to load the game engine and enter the main menu. Then, the remaining ~380MB are fetched asynchronously.

> While you certainly can write an application or game with a scripting language, it will be slow, it will be limited by the operating system's own libraries (eg 32-bit libraries on a 64-bit OS as just one example) and generally require more maintenance than simply writing it in C to begin with.

I prefer C/C++ myself but you don't know what the fuck you are talking about W.R.T games and scripting:

1. You DO realize that there is a WIDE variety of games from "idle games" and simple puzzle games to full blown First Person Shooters right?

Are you telling me the JavaScript implementation of 2048, xkcd Sand Castle Builder, or Cookie Clicker is slow??

2. You DO realize you can "transpile" C/C++ code into JavaScript right, such as Doom 3, using Emscripten right?

Or how about RollerCoaster Tycoon? Here OpenRCT2 was ported to run inside a browser.

> yet GPU's APIs have standardized more or less on just four API's, OpenGL, Direct3D, Vulkan, and WebGL.

FTFY.

WebGL exists to offload rendering to the GPU inside the browser. There are TONS of playable WebGL Games

3. Lastly, Unity can target WebGL

A solution: get Adobe to compile Flash player to asm.js. If they won't do it then ask them why they hate the web.

Not necessarily. Just start with an x86 emulator instead of an OpenRISC emulator.

Really, with Emscripten you can do just about anything. There was a classic Mac emulator posted about a month ago.

Yes, you are completely missing the point.

By now, the whole damn OS API is implemented in browsers. But slower. And shittier. And crippled.

s/browser/shell/g; s/tab bar/task bar/g; and you're done. In fact they already went that far, and called it ChromeOS!

In fact they went even further: The browser is not the new OS, but the new machine .

Don't believe they went too far? Then feast your eyes at THIS: http://jslinux.org/
Yes, that's right! The actual Linux kernel... running on an actual virtual CPU... actually implemented in JavaScript inside your browser!

If you don't think this path is fucked-up, you're fucked-up.

Irrelevant examples are irrelevant.

You use your Web browser to go to a web page and there's a video. How do you play it? Your browser uses some sort of plugin. This is not an example of the "Inner Platform Effect" but simply the most efficient and straight forward way to do it. As for the other examples, yes they are stupid, but irrelevant. All browsers contain a Javascript interpreter and ORBX.js is just another Javascript file. In fact, this *reduces* browser bloat by eliminating the need for a video plugin and instead, just using the Javascript interpreter that already exists in the browser.

Yes, you are completely missing the point.

By now, the whole damn OS API is implemented in browsers. But slower. And shittier. And crippled.

s/browser/shell/g; s/tab bar/task bar/g; and you're done. In fact they already went that far, and called it ChromeOS!

In fact they went even further: The browser is not the new OS, but the new machine .

Don't believe they went too far? Then feast your eyes at THIS: http://jslinux.org/
Yes, that's right! The actual Linux kernel... running on an actual virtual CPU... actually implemented in JavaScript inside your browser!

If you don't think this path is fucked-up, you're fucked-up.

http://emscripten.org/

emscripten can compile C code, or anything that can produce LLVM bitcode, directly into JavaScript, allowing heavyweight code like Ruby/Python/Lua, physics engines, raytracing, FreeType, text-to-speech, etc. to run in a browser. JSLinux emulates the 386 instruction set to the point it can boot a stock Linux kernel, start a terminal, and run ELF executables like the Busybox command-line utilities in a browser (JSLinux's Fabrice Bellard could probably do MAME in JavaScript in his sleep one-handed.) So despite the innovations in Native Client, targeting JavaScript in an HTML5 browser is the way forward. And until Google implements Portable Native Client, NaCl doesn't even give you the ability to run in any Chrome browser, you need an architecture-specific executable. But portable NaCl is just running LLVM bytecode, and emscripten is already turning that into plain JavaScript without requiring a new black box in each web page.

Does anyone know if any of the native apps in ChromeOS/ChromiumOS and Android are written in NaCL or PNaCl? That would make some sense.

NaCl is not, in my view, a replacement for JavaScript, its a tool for certain purposes for which JavaScript is problematic (one might be re-use of substantial legacy code bases that aren't in JavaScript

You definitely do not need NaCl for that. emscripten lets you compile C or C++ into JavaScript (see the demos in that link for examples). There are similar projects for other languages (but C/C++ is the most important case, since you can even compile the C code of CPython and run Python on the web using that).

The example doesn't work. Also even if it did it would be "marking the first such scripting language alternative to JavaScript" only for people who want to restrict their website to Chrome users.

Which is a shame, especially as it is totally avoidable: It is possible to compile Tcl to JavaScript (using Emscripten), which would allow you to script the web using Tcl on any web browser and on any platform.

Disclaimer: I wrote Emscripten, sorry to pimp my own project. But if you are a Tcl hacker and want to compile it to JavaScript, please get in touch, I'd love to help.

Significantly more interesting would be a GTK that draws with PPAPI and runs in NaCl, which would allow you to develop a web app using GTK, deploy it on the web, and run it (safely) within your browser.

I agree that running a GTK app entirely clientside would be very interesting. There is another way to do that: Compile a GTK app from C to JavaScript using Emscripten. (I wrote Emscripten, sorry to plug my own project, but I'd be thrilled if someone used it to do something like this!)