sergimansilla

It would be nice if they moved development to Github. Easier to take a first glance and contribute to the code.

Yeah, reminds me of http://sergimansilla.com/blog/swipeselection-in-an-afternoon.... Development of new features (and bugfixing) in the core of Firefox OS is bliss.

Indeed. Now that I have it it is SO intuitive and fast, one wonders why no phone makers have gotten creative about the cursor placement/selection UX.

The applications can, through Firefox for Android. That means that if you use WebAPIs that access phone internals, it will work just fine.

Cloud9 IDE has static JavaScript Analysis integrated in the editor. https://c9.io/

Well put. It still puzzles me that promises and/or CPS don't have a greater adoption in the JavaScript community. I guess that what happens is that the concept of a callback is a very easy to understand one, but a system becomes more complicated and cumbersome (exponentially, I would say) with every new callback that is added to it. The real problem comes when creating big async applications in JavaScript based entirely in callbacks, as it is the norm now specially in NodeJS projects. Using callbacks to build complex applications is a sure way to un-maintainability.

Did you ask for help in our support page or on Github issues? We try to be very responsive. What problem are you having exactly?

Um, 'new data structure'? You have to be kidding. This is implemented in practically every single functional programming language. Also, this was already done in JavaScript: https://github.com/Gozala/streamer and looks surprisingly similar to your library. As you can see, streams in JavaScript are nothing new.

Just a small correction, Bespin evolved into Ace (which Akshell uses as their code editor), which was created by the guys that created Cloud9 (Ajax.org). Cloud9 is the actual IDE that uses Ace as its code editor.

Find ace here: http://ace.ajax.org and Cloud9 here: http://c9.io

It will happen, but there are many languages out there, each with its own runtimes, debuggers, etc. We are first focusing on making the IDE solid and stable, and then we will focus on what people want. In fact, thanks to the work done by the Mono guys C#/F# shouldn't be difficult to get working, but for now there are more important hings to do.

We just launched, and we are trying to squash every bug we run into. Could you be more specific about the 'buggy' part you mention? Some particulars about it would really help us to make it better, we would really appreciate it!

The platform code is private, but you can always run the IDE locally, or on your own open-source webserver.

Thanks for the heads up, we are fixing it right now!

It doesn't yet, but it will be supported very soon, we are working on it!

Works over here on Chrome 10 but thanks for reporting, we will try to reproduce your environment and fix it!

We are working on it. We aim to support all the major languages and their popular frameworks soon. For now you have syntax highlighting for Ruby and more languages, which combined with GitHub integration already makes it a sweet platform to develop on.

This post is incredibly vague, and it is missing the point. First of all, it doesn't explain the huge lack of standards in IE9 that Paul Roget mentions. And second, it forgets that IE has a really awful record on making browsers (IE has been the biggest drag on the web being more usable and modern for the last 10 years).

At least Paul's post gives a tangible and definition of what 'modern' means in form of checklist points that are easy to prove true or false just by looking at the browser implementation. How do you measure 'modern', Microsoft? You will have to do better than saying it is 'faster' and that provides 'rich, immersive experiences'.

Mozilla hasn't stopped pushing the web to its boundaries and making a big effort to put standards first during all these years. And there is no doubt that the new Firefox will be a much better browser than the new IE (check out the beta).

Also, where is the strict mode in IE9?

EE (ok, and W3Schools) was the main reason I started using Chrome's 'Personal Blocklist' extension. I am loving it.

The problem with that is that MIDI is a very strong standard, as bad as the format itself might be. Every single synth or keyboard out there exports to MIDI, and most of the time ONLY to MIDI.

Also, the MIDI format is not slow to generate or to read, it is actually designed for speed (and may other perks) and any implementation of it would be very likely faster than any other format you could come up with. Of course, you would still have to deal with its complications and the many particularities and edge-cases it has.

That sounds like fun, can't wait to hear about it! Keep an eye on updates to the library, and if you run into bugs (you will) don't hesitate to nag me, or even solve them :)

I agree, latency is way too important in that scenario. I made that as an experiment, I never thought of it as a professional tool.

I am curious about your Boss DR-110 emulation in HTML5, are you going to publish it somewhere?

Mozilla is working on an Audio Data API, and hopefully it will become the standard in the future. Take a look: https://wiki.mozilla.org/Audio_Data_API