5 ms·
Is it that hard to just make Lua another W3C standard, enable it in the browsers and make this world a bit better?
by viach 12y ago
Is it that hard to just make Lua another W3C standard, enable it in the browsers and make this world a bit better?
- sigzero 12y agoIt would probably be next to impossible at this point. Javascript is too entrenched.
- innguest 12y agoWould you be opposed if all browsers made Lua available for webpages? It does not seem impossible to me to add functionality to a browser to accept some other language to run. What you're talking about is how hard it would be to convince JS developers to stop using it. But no one is talking about that.
- jlarocco 12y agoI think that's already a feature of HTML, using the language="..." attribute of the script tag. Believe it or not, a long time ago, Javascript was actually the less bad option in web scripting. IE used language="vbscript" to allow web scripting in VBScript, which, AFAIK, was the only other language that became popular for scripting web pages.
- Aldo_MX 12y agoI would be opposed for one main reason: The extra overhead that supporting an additional language implies with hybrid websites (even if you disregard JS completely, external code like advertisements would introduce it). People can claim that the overhead is negligible with today's hardware, but this is not always the case, especially when you are trying to get as much performance as possible for a web-based game engine. We should be working hard to kill Flash and Java completely from the web, substituting them with modern and standard web technologies. I don't mind an obscure corporate website requiring their employees to install Flash or Java, but I do mind being bombarded with "please install Flash with Mc Affee unless you opt-out", because we are too lazy to display video without Flash. A better alternative to have Lua in the browser (at least in my opinion) is to support Mozilla's asm.js initiative, and compile Lua to LLVM/JS.
- swift 12y agoI don't think asm.js is a very good fit for garbage collected languages. You really want to integrate with the browser's existing, native GC instead of implementing your own GC on top of a huge typed buffer in JavaScript.
- lmm 12y ago> The extra overhead that supporting an additional language implies with hybrid websites (even if you disregard JS completely, external code like advertisements would introduce it). People can claim that the overhead is negligible with today's hardware, but this is not always the case, especially when you are trying to get as much performance as possible for a web-based game engine. If you're worried about performance, why are you advocating asm.js? That's always going to be less performant than direct browser support for a language. > We should be working hard to kill Flash and Java completely from the web, substituting them with modern and standard web technologies. The JVM (on which Java is only the most prominent of many languages) is standard and modern. So was Dart. So is Lua.
- Aldo_MX 12y ago> If you're worried about performance, why are you advocating asm.js? That's always going to be less performant than direct browser support for a language. TL;DR: You won't get Lua support in your favorite browser if you don't build web projects with Lua today, and you can only use Lua via asm.js today. non-TL;DR: because of 3 reasons: 1) JS is not going away, and you are not going to convince the main browser vendors to use Lua, this makes Lua via asm.js the only realistic way to use Lua in any browser today. 2) VMs like OdinMonkey use a different strategy when they detect the "use asm" pragma, and this allows Lua via asm.js to run faster than JavaScript, but this only applies to Firefox. 3a) In order to convince browser vendors to take Lua seriously, Lua has to be massively adopted in the web. 3b) In order to help Lua to become massively adopted in the web, it needs to run fast everywhere, not just in Mozilla's browsers. 3c) In order to help Lua to run fast everywhere, the teams behind other JavaScript VMs (V8, JSCore, Chakra, etc.) need to be convinced that the web needs asm.js. 3d) In order to convince the people of other JS VMs, we need to build more projects which use asm.js. -- > > We should be working hard to kill Flash and Java completely from the web, substituting them with modern and standard web technologies. > The JVM (on which Java is only the most prominent of many languages) is standard and modern. So was Dart. So is Lua. The JVM, nor Dart, nor Lua are web standards, also, I expect from you to not be nitpicking my comment, I was referring to the frontend (ie. applets / flash player).
- lucian1900 12y agoIt wouldn't be a big enough improvement to be worth it. It's overall less crazy, but has enough of its own warts.
- Derbasti 12y agoOH YES IT WOULD BE!!!1
- alexpw 12y agoAt the very least, maybe JavaScript can take a page from this release of Lua and finally give us integers.
- bch 12y agoWhether its difficult or not may be besides the point -- Not all languages want to take on the responsibility/burden of being a standard. Not being a standard allows flexibility, in theory.
- ackalker 12y agoWell as for simply supporting Lua in browsers, aside from the obvious Emscripten/ASM.js way, which would work for practically all browsers which support JavaScript, Lua can run as a PNaCl app in Chrome/Chromium, see: https://chrome.google.com/webstore/detail/lua/nkcnhkobblkmiampcmimoemaeffjopph?hl=en https://chrome.google.com/webstore/detail/lua/nkcnhkobblkmia... Of course this is only a proof-of-concept which just runs a Lua REPL in the browser. I wonder if it is possible (and if so, how hard it is) to make the browser run <script language="lua"></script> code.
- justincormack 12y agoYou need to define a DOM interface to do anything useful, which is a fair amount of work.
- daurnimator 12y agolua.vm.js can manipulate javascript objects. the only outstanding issue is tracking garbage (lua closures can leak into javascript). In regards to actually doing the DOM work, craig barnes is doing great work over with lua-gumbo: https://github.com/craigbarnes/lua-gumbo https://github.com/craigbarnes/lua-gumbo
- daurnimator 12y agoIt supports script tags: https://kripken.github.io/lua.vm.js/repl.html https://kripken.github.io/lua.vm.js/repl.html Code that does it: https://github.com/kripken/lua.vm.js/blob/master/src/lua.js#L647 https://github.com/kripken/lua.vm.js/blob/master/src/lua.js#...
- ufo 12y agofwiw, the only reason Lua is a decent language nowadays is that it was able to evolve in a backwards incompatible way. If we had frozen the language back in the 90s like they did with JS then Lua would be super shitty (no lexical scope, coroutines, metatables, etc etc)
- kephra 12y agoThe main reason Lua stayed small, is that its developed as an open source, closed shop software. I'm using my own PHP microframework called DataFace for over 20 years. Nearly no two applications share the same DataFace code, each of them is a little bit different. My current DataFace can create dynamic AJAX forms, but its still less then 1000 lines, because its my open source, closed shop code, where I'm able to cut dead branches, to grow new flowers. I stopped using Turbo Pascal, C++ or TCL, because backwards incompatibility. A language implementation like Turbo Pascal, C++ or TCL is outside of my application scope. Any operating system distribution update could break compilation of my code anytime. It did and I decided for my self to avoid those language. But its a total different case with Lua, or my own DataFace microframework, because those are inside of my application. The Lua interpreter code is not some library coming from operting system distribution, but a shared lib, I ship with my code, and a source code tree within my own application. My old applications do not need to care, if something in Lua 5.3 breaks them. But I can investigate the new features for next application.