questions about 1.0.0 (not 0.10.0)

[Positive07]

Which is exactly the road taken before, but one of the major problems with this is that you're splitting the codebase. I have no intention of supporting a javascript framework as well, and, as has been the case in the past, if someone does end up maintaining it, it's a bunch of annoying, boring work I can't fault anyone for that wants to drop it as soon as possible .

Yeah this were my exact thoughts haha... but yeah if someone does it we cant be against it!!

The "best" thing about the android and iOS ports is that they are the same source code as love proper, and it means very little time has to be spent keeping the ports in line with the desktop version.

That is why I will get my hands on LÖVELY (that Chrome extension that existed some time ago and allowed you to play the game from Chrome... that was pretty awesome, also would get us an extra platform, ChromeOS!), this should be pretty straight forward port, the worst parts would be window management (not that complex, but I will have to write some code for this) and filesystem access (Should probably look at how LÖVELY did it). But anyway should still be pretty much the same code.

Now emscriptem is obviously a solution for that, if you can get it to work, and as it is fully compatible with GLES2, which the love codebase will support for 0.10.0 (right, slime?), it should be easier to get it going. Maybe then someone could look at getting it running?

The problem as I said before with emscripten is that it is basically an LLVM compiler, and then JavaScript becomes the LLVM backend... So you would be running LÖVE inside the browser and then LÖVE would be running the Lua code inside of it and doing lots of expensive operations, so basically there is no way this would be faster than having the Lua code be JavaScript code and having it interacting with JavaScript code that handles the expensive stuff... The only benefit of emscripten is being able to use the same codebase

[s-ol]

Now emscriptem is obviously a solution for that, if you can get it to work, and as it is fully compatible with GLES2, which the love codebase will support for 0.10.0 (right, slime?), it should be easier to get it going. Maybe then someone could look at getting it running?

The problem as I said before with emscripten is that it is basically an LLVM compiler, and then JavaScript becomes the LLVM backend... So you would be running LÖVE inside the browser and then LÖVE would be running the Lua code inside of it and doing lots of expensive operations, so basically there is no way this would be faster than having the Lua code be JavaScript code and having it interacting with JavaScript code that handles the expensive stuff... The only benefit of emscripten is being able to use the same codebase

Did you ever try Punchdrunk? it runs compiled Lua(-jit) code in a Moonshine-VM that runs on JavaScript (CoffeScript). It is actually working fairly well, but the API is not 100% ported (or portable for that matter).

[bartbes]

The only benefit of emscripten is being able to use the same codebase

It is actually working fairly well, but the API is not 100% ported (or portable for that matter).

And it's a very big, very important benefit.

The problem as I said before with emscripten is that it is basically an LLVM compiler, and then JavaScript becomes the LLVM backend... So you would be running LÖVE inside the browser and then LÖVE would be running the Lua code inside of it and doing lots of expensive operations, so basically there is no way this would be faster than having the Lua code be JavaScript code and having it interacting with JavaScript code that handles the expensive stuff...

Well, no, it can't be faster, but then anything using the same codebase can't be faster than itself. I'm not sure of the exact impact of this, but I know javascript engines are really fast these days, especially when it comes to asm.js, if someone does really care about a web port, this would be a thing to try.

You are also, perhaps falsely, assuming that a lua to js compiler would be both accurate (as in, practically indistinguishable from a "real" lua implementation) and fast.

[jjmafiae]

Well, no, it can't be faster, but then anything using the same codebase can't be faster than itself. I'm not sure of the exact impact of this, but I know javascript engines are really fast these days, especially when it comes to asm.js, if someone does really care about a web port, this would be a thing to try.

You are also, perhaps falsely, assuming that a lua to js compiler would be both accurate (as in, practically indistinguishable from a "real" lua implementation) and fast.

according to a benchmark of various programming languages I found a while ago Javascript is the fastest language for most calculations and operations.

[Positive07]

Well, no, it can't be faster, but then anything using the same codebase can't be faster than itself. I'm not sure of the exact impact of this, but I know javascript engines are really fast these days, especially when it comes to asm.js, if someone does really care about a web port, this would be a thing to try.

I think you may be misunderstanding what I said, I didnt compare emscripten vs native LÖVE, just said that compiling LÖVE with emscripten and having it read an process lua files may not be as fast as having lua code compiled to javascript because well there is no code processing and stuff there.

Of course using the same codebase is really important but is it more important than a good performance I wonder? even more when it wont be officially maintained either way.

You are also, perhaps falsely, assuming that a lua to js compiler would be both accurate (as in, practically indistinguishable from a "real" lua implementation) and fast.

I think I said that was a problem somewhere before, but if it is possible to compile c, c++ there should be an accurate compiler (or at least it should be possible) and yeah it should be faster than javascript code executing lua code.

Did you ever try Punchdrunk? it runs compiled Lua(-jit) code in a Moonshine-VM that runs on JavaScript (CoffeScript). It is actually working fairly well, but the API is not 100% ported (or portable for that matter).

Nice! I'll investigate, And if it is as you say then it should be way closer to what I assume would be the best approach to the Web port "issue"

[szensk]

according to a benchmark of various programming languages I found a while ago Javascript is the fastest language for most calculations and operations.

Faster than C or C++? In micro-benchmarks, V8 is about 4x slower than C++ and execution time is much more variable. Micro-benchmarks are the areas that compilers like V8 do best. The static nature of most the algorithms allows the optimizer to hoist variables, eliminate sub-expressions, fold constants, sink allocations, narrow doubles to integers, and remove bounds checking all while avoiding the garbage collector. Many optimizations are less likely to be possible in more typical real world code. For good performance in dynamic languages, you typically write highly static code that ends up looking like a hideous version C. The statically-typed language compilers can do many of these optimizations in more general cases, hence their more consistent performance. Pathological cases in V8 are just painful (falling back to the interpreter).

Back on topic:
I feel it should be called 1.0.0 only when it is expected to be forward compatible. That is: no more removing functions or changing signatures of existing functions, basically only changing the implementation and adding new functions. Any non-backward compatible API change would should cause a major version bump unless it is fixing incorrect behavior.