quinnirill

> It's a funny world. Each of us is looking at the other library thinking there's too much magic involved. :-)

Heh - I think what feels like magic is the syntax that Trine is presuming, which admittedly might seem magical before trying it out. :) The library itself is just a collection of very primitive methods (with the exception of partial()).

> Ramda is [considering a technique][1] that would significantly reduce call stacks.

That's good to hear! But what I'd really like to see is something that would make the stack trace have a reference to the function definition site, e.g. if I have an error like

    var getIds = map(prop("id"));
    var ids = getIds([{ id: 1 }, null, { id: 2 }]);

the stack trace would also show the definition site of getIds. This is what I get when I compose functions just using the vanilla JS syntax:

    function getIds (items) {
      return items.map(function (item) {
        return item.id; // the stack trace will point here, and I can also add a breakpoint here without it stopping on every unrelated prop() call
      });
    }

Like I mentioned on several occasions here, I'm hoping for JS to get simpler unbound function syntax, which would work well with Trine, and still have the aforementioned benefits:

    let getIds = -> this::map(-> this.id);

> Best of luck!

Thank you, and likewise! <3

With Trine this would be

    function process () {
      return this
        ::filter(isOk)
        ::map(toOtherType)
        ::flatten();
    }

and then later:

    groupsOfItems::map(process);

Granted, the `flatten` function is not in the Trine yet, somehow forgot that from the initial release.

Trine can actually already do this particular example:

    sum = reduce::partial(add, 0);
    [1,10,20]::sum();

(Disclosure, Trine author here, and also admittedly very inspired by Ramda.)

I actually used Ramda quite extensively a while back, because I was convinced it was the right way. However, a while after looking at stack traces that lead to Ramda and not even myself understanding my where each parameter in my own code goes, I decided to stop using it and also dropped these features from Trine. Trine has partial, and that's as far as magic goes, in fact I wanted to make it as far from magical as possible. I think plain old functions are the best form of function composition, albeit I'd love for the syntax to be terser. They're easy to read and easy to reason about, also easy to reorder, no need for higher order functions that go in the middle.

Well, the no CS background and shady Haskell tutorials parts were correct; My highest formal education is high school. ;) But this was done on my free time, and I don't really identify myself as a rockstar developer. Sounds pretty arrogant to me.

And also because it has prevented the language itself from standardizing some features, e.g. String.prototype.contains had to be renamed to includes because shipping it as contains would have broken sites that use mootools.

Yes, sorry, thin arrow, not single - `() -> this.foo()` for function expressions and possibly even `let/const fn () -> this.foo()` for declarations.

Right on the point. I'm still hoping for that to get in at some point. :)

This is to avoid multiple versions of Trine required by libraries (or the application itself requiring a different version of babel-runtime) causing the different versions of `babel-runtime` to be included multiple times, which would be a problem especially for browser applications. Trine itself is very small, but if each module introduces a dependency to babel-runtime, it would be another case of "npm downloads the whole internet". :/

Ramda actually uses data as the last parameter usually, whereas lodash has it as the first.

However, I agree, the readme doesn't quite show the full power of Trine. Trine has `partial`, which allows you to do partial application as so: `parseInt::partial(_)`, that would create a function that acts as parseInt but only takes one argument. This is in sync with the partial application syntax proposal: https://gist.github.com/anonymous/5c4f6ea07ad3017d61be

The rest of the functional goodness, such as autocurrying are still undecided upon because in my personal experience autocurrying in JS is awkward and leads to bugs that are hard to debug. I'm also considering compose and a combination of compose and partial (e.g. apply a function to a parameter at a certain place), but again subjectively, composing functions like that has reduced the readability of codebases. JS already has first class functions which allows composition pretty easily, the only problem is that it's overtly verbose - I'm still hoping to see the single arrow function land in JS some day. :)

I'm just talking about design goals - the original assembly was introduced so that people wouldn't have to remember the numeric instructions of the processor. The instruction sets have been legacy even before that, with slight improvements occasionally, but at least the target audience was people in the beginning. With asm.js the target has been compilers to begin with. With most assembly dialects the instructions have a clear purpose, where as with asm.js you have arcane rules on what makes what stay as an integer, etc., enough so that I think most of the group of sane people would prefer writing against traditional assembly dialects than asm.js.

Maybe that's a good thing, at least then the goal is that people who care about performance don't write JS. But I'd prefer to just have the compile target as numbers then since you can't read the result anyway.

I liked the "original" assembly more, at least it was designed for helping humans to write and read code.

EDIT: That said, this is good news, in a sense.

> * Often you actually need pixel-perfection in display, which SVG isn't really built for (hence the S) and you'll just end up drawing 1-pixel wide lines in SVG form.

Actually you might find it interesting that SVG supports media queries so you can include multiple presentations of an image for different sizes and even make special cases of some sizes and go for pixel perfection for them. The thing that makes your argument(s) stand true is that SVG support is horrendous (even Inkscape doesn't let you leverage many of SVG's powerful features, e.g. media queries, and worse yet, bloats your SVGs with meaningless cruft).

If implementing every effect out there by yourself becomes tedious, you might wanna give audiolib.js a shot: https://github.com/jussi-kalliokoski/audiolib.js , it's an audio effects library I've been building for 2 years now. :)

That's unlikely, mobile device lifecycles are way shorter than those of desktop computers. Even native game developers often don't target mobile devices that are outdated.

Current mobile browsers, yes, very much so.

But I think Chrome for Android 4 (which I believe will replace stock Android browser eventually), IE10 for Windows 8 phones / tablets, and Firefox on B2G will change this. I've seen B2G already running mobile web games smoothly on Android hardware.

> There is, as far as I can tell, no way which you can cause a sound to play (programmatically)

I suggest you give my audiolib.js ( https://github.com/jussi-kalliokoski/audiolib.js ) and sink.js ( https://github.com/jussi-kalliokoski/sink.js ) a shot, they're designed to abstract away the differences between the "competing" Audio APIs, allowing you programmatic access to as deep as the sample level and providing abstractions such as filters, reverbs, delays, etc. For browsers with no Advanced Audio API, there's an inferior fallback using the <audio> elements.

> On the other hand, there are platforms like Java or Flash (or Unity, so I've heard), where you can write once and expect it to work identically everywhere (even on out of date browsers). That must be nice.

I've heard good things about Unity, and it seems to be a great toolkit for game development. However, write once, works everywhere is a pipedream, really. Even for something as simple as a document website, taking all the possible input methods and screen resolutions, etc. into account is hard work. This is where the mentioned technologies fall short and the web stack shines. If you really need to care about that, it's up to you.

I agree with your sentiments about the B and C to great extent. Also the performance of imagedata is absurdly bad. The interpolation issue is, well... I think I'll write another blog post soon, about how ZOH interpolation may sometimes be the best quality option.

Make sure to make a fuzz about it when it's ready to be played, I sure have to give it a shot!

> I was hoping for a more technical article

Sorry to disappoint, there are a lot of more technical articles out there, I wanted to look at this more from the perspective of the process of making games than a more detailed technical overview.

> the core techs for HTML5 gaming aren't quite from what I can tell. WebGL and the Audio APIs in particular seem on shaky ground for the moment... it seems there are still rather major security and performance problems to deal with.

The alleged WebGL security issues are mostly solved now. WebGL has about as much security issues as anything to deal with graphics, a computer can crash because of CSS 3D transitions almost as much as it can because of WebGL.

As for Audio APIs, open security issues are mostly to do with user permissions. The worst thing you can do currently is break the ears of the user and make the application unresponsive. You can do as much without audio APIs: var a = new Audio(); a.src = 'noise.mp3'; a.play; while(1);

As for the maturity of the APIs, WebGL offers most of the capabilities of OpenGL, except for a few quirks like Texture1D not being supported, more strict limits in construct sizes and referencing arrays (for some types you need to use constant value indices, unlike in normal OpenGL).

Audio APIs are in a weird spot now, we have two proposals, one from Google and one from Mozilla. Both have their virtues, and they offer solutions to a bit different problems. But at W3C Audio WG we are working on making these things better, so that eventually we'll get audio APIs across all browsers.

> Most worrying however is the utter lack of any non-TCP networking in the browser, not even at the specification-proposal stages. Any sort of real time multiplayer really kinda needs UDP to work efficiently. P2P is also fairly important for certain applications and is in a similar state.

This is indeed a huge weak spot, but it's hard to achieve securely. Making solid APIs for P2P connections, spanning more use cases than video streams would unleash open a galore of new doors, so I do hope WebRTC will bring forth a good solution.

Phones need serious improvement to run these kinds of games anyway, we're probably looking at at least half the time it's going to take for these games to run with the web technology stack on the mobile to get it running even natively on the mobile. So for mobile, the wait is on, no matter what.

It's going to take a while, but our toolkits need sharpening as well, so I'm not expecting a non-trivial web game to emerge very soon. But the platform is growing in the right direction.

You got me interested, what kind of a game are you working on? Sounds like my kind of a game.

I will always bet on JS as well.

The games you're talking about here, however fall in to the category of casual games described in the article. So for more featured games, we'll have to wait a bit longer and mature the platform as we go, but eventually we'll get there.

Good point about the same code base. I forgot to mention this in the article, but the reason the programmers say "HELL NO" is that maintaining two different code bases is a nightmare. (Semi-)automatic porting is easier and cheaper.

But that might shift in the future, we might be looking at a time when the only version you need to make is the web version, even for non-casual games.

One of the earlier demos (about a year old and unfinished) : http://niiden.com/orbisyn/ :) has a virtual MIDI keyboard, to which you can connect a MIDI synth if you have Java. It isn't exactly native support, and it's very unpredictable, but it's something that can be used meanwhile.

However, the Device API should allow access to external inputs, such as microphones and MIDI controllers, so it's coming along!

fft.js supports as large buffers as JS can handle, that depends a bit on the browser, but 256k samples will probably work, you might have some trouble in Chrome, if you have too much other stuff in memory as well. Would be cool to see a demo of PADsynth on the web, especially with audiolib.js!!!

Paulstretch would be a perfect addition to the library, it would open whole new doors for example for samplers (whoa, the sample is sustained forever!), of course with some limitations in regards of real time. Send me a message on GitHub, if you decide to take up on the task, I'd be glad to give you a hand with it! :)

Wow, that's very cool! I think you could make a great learning resource for FM synthesis from there, especially if you'd explain how each of those examples are put together!

Yep, I definitely see where you're coming from with this. It was my initial take as well, but as crazy as it is, after some time spent comparing different approaches, turned out that this is the fastest way to do it in JavaScript world, and that is true even up to older browsers such as IE8 (I haven't bothered measuring anything related in browsers older than that, because IE8 is the oldest browser with some way to output generated sound), but especially true with the latest optimizations such as CrankShaft.

However, I should probably set up some public performance tests and compare the instructions these things compile to have some hard data back my claims, I wouldn't exactly trust me just saying it is so, as I have just tested these things on the fly.

But, however, this approach is more modular, and fits more use cases, and that matters even more for me right now, but trust me, I've spent my time optimizing every operation to the point that it doesn't make things harder to use. :)

Ah yes, looking at the source code makes it a bit obscure, because the inheritance patterns are described in the wrappers. But for generators, you can do, for example osc.append(buffer, channelCount);, because generators are by nature multi-channel, but for effects you have to create a multi-channel instance, like flt = audioLib.LP12Filter.createBufferBased(channelCount, sampleRate, cutoff); and then you can use the append function similarily to generators.

This is a design choice to make implementing new effects simple, and the framework providing this extra functionality for you.

Actually, the API allows for both, whichever suits your needs. When doing buffer based processing, you can even add advanced automation, etc.

I agree! And actually you can already do multichannel stuff, but currently that requires you to use either Audio API exclusively, because Chrome supports only 2 channels for javascript processing (but the internal effects are multi-channel), but Firefox supports only javascript processing.