4 ms·
Lua is a better language than Javascript in every possible way. I have half-a-mind to hack LuaJIT into Webkit, but I'm afraid that it may be futile at this poin
by jballanc 14y ago
Lua is a better language than Javascript in every possible way. I have half-a-mind to hack LuaJIT into Webkit, but I'm afraid that it may be futile at this point. The biggest shame in all of web development is the "type" attribute on the HTML "script" tag...
- mistercow 14y agoI disagree that Lua is better in every possible way. There are at least a couple of ways in which it is merely equal, yet where improvement would be possible.
- jballanc 14y agoPoint taken... "equal or better" in every possible way. :-)
- TazeTSchnitzel 14y agoPlease hack LuaJIT into WebKit. I was thinking of doing something even more crazy: hack Mono into WebKit!
- gruseom 14y agoI have half-a-mind to hack LuaJIT into Webkit I've been thinking for a while that Lua and especially LuaJIT are so good that there might exist a strategy to do an end run around vendors and get LuaJIT into browsers as (initially) a plug-in. It's possible that there's a killer app waiting to be written that could run well in LuaJIT (but not JS) and that this could drive installation of such a plug-in.
- azakai 14y ago> I've been thinking for a while that Lua and especially LuaJIT are so good that there might exist a strategy to do an end run around vendors and get LuaJIT into browsers as (initially) a plug-in. It's possible that there's a killer app waiting to be written that could run well in LuaJIT (but not JS) and that this could drive installation of such a plug-in. Please don't create yet another plugin. Plugins are bad for the web, they fragment it and if they end up de-facto standards that causes many problems too. > It's possible that there's a killer app waiting to be written that could run well in LuaJIT (but not JS) and that this could drive installation of such a plug-in. If you think there is something that needs improving in the web platform, contributing to that would be the best thing. If you have such a killer app that does not run well enough in current JS engines, you can contribute to one of the three open source JS engines to make it able to run your killer app.
- bsg75 14y agoBut does not fragmentaion drive innovation (mutation -> evolution)? If the only progress that occurs are incremental improvements to existing platforms, then the web is in "maintenance mode".
- azakai 14y agoI agree we need places where innovation can run wild, but also places where there are accepted standards. The web is pretty much our only complete platform that is standards-based. Fragmenting it risks killing it. Remember when sites were "best viewed in IE" and people without Windows basically could not browse the web? > If the only progress that occurs are incremental improvements to existing platforms, then the web is in "maintenance mode". How about WebGL, 10x faster JS than just a few years ago, typed arrays, video and audio tags, WebRTC, etc. etc. ..?
- bsg75 14y ago> How about WebGL, 10x faster JS than just a few years ago, typed arrays, video and audio tags, WebRTC, etc. etc. ..? I was not implying that innovation had ceased. On the contrary, I love seeing stuff like this appear. Even if doomed from the outset to not become standard or widespread, the potential from experimentation is what keeps things interesting.
- deleted 14y ago[deleted]
- gruseom 14y agoIf the web is so moribund that its health relies on convincing individual hackers not to do things they think would be cool, then the web is doomed. I don't think it is; I think your argument is self-defeating. It makes me want to make a LuaJIT plugin more, not less. LuaJIT is seriously cool. If it were merely a question of some minor incremental improvement, such as could be obtained by "contribut[ing] to one of the three open source JS engines", then I agree it wouldn't be worth the fragmentation. But then it wouldn't meet the definition of a "killer app" either. Nor would it be likely to gain traction. It would just be a gnat. What I'm talking about is only interesting if it might be disruptive. I think there's a chance that Lua as both language and implementation is good enough that it might enable things that simply aren't doable (performantly) in other ways. Perhaps I underestimate how many tricks the V8 people have left in their bag. I hope so. But at some point they're going to reach a wall caused by JS's design limitations that simply can't be drilled through. I take the existence of Dart to be a tacit admission of that wall. And what is so amazing about LuaJIT is that it has already proven it does not know that wall. At the same time Lua is so similar semantically to JS that it is not likely to mess with the things that made JS great, so integrating Lua into the web would arguably be a conservative design choice – more conservative, perhaps, than many proposals to "fix" JS by making it more static and proper-like.
- bonch 14y agoLua won't complain about this: function example(x) print(X) end Because of the subtle bugs that can arise from Lua's undefined variable behavior, I prefer Squirrel: local a = {} a.x = 5 // Throws an exception a.x <- 5 // Assigns the value, creating the slot if needed Squirrel also supports JSON syntax for table creation.
- est 14y ago> Lua is a better language than Javascript in every possible way. How about unicode and regexp support?
- jballanc 14y agoSo regexp is easy: the Lua authors assert that their irregular-regular expressions (match library) cover the 80% use case for regular expressions while maintaining excellent performance and avoiding the hell that regexps can all too easily descend into. Based on some of the regexps that I've come across in my time...I'm inclined to agree with their decision. As for unicode, I also rather like their approach: we give you the low level tools, and you are free to implement whatever sort of encoding support you like on top of that. I used Ruby 1.8 when a string was just a bucket-o-bytes, and now I use Ruby 1.9 where every string MUST HAVE AN ENCODING OR ELSE! Based on my experience with both, I'd much rather not have encoding forced on me. That said, it would be nice to see a unicode implementation "blessed" by the core team (but the seem loath to "bless" any libraries).