Slashdot Mirror
JavaScript Decoder Plays MP3s Without Flash
An anonymous reader writes "The introduction of HTML5 and super-fast JavaScript engines to the latest web browsers has brought with it a wealth of new functionality. The focus seems to have been put on the ability to play video in a browser without Flash, or making games. But a project born out of a Music Hackday in Berlin is just as exciting. It's called jsmad and is a pure JavaScript decoder that allows you to play MP3s in a browser without Flash. So, for example, a music artist could create a website and upload songs for visitors to listen to without need of any plug-ins. Alternatively, why not have an MP3 jukebox that can play songs off your hard drive or Dropbox folder just by loading a website? You can try out the decoder by visiting the jsmad.org website where there is a sample song, on the same site you can browse for your own local file to play. Be warned, it only works in Firefox 4+ at the moment, but Chrome support is coming and already works in some cases."
Another reader tips news of a JavaScript PDF viewer.
Actually, my subject makes me seem more excited than I am. I regret any misunderstanding.
Carry on.
Humor from a Genetically Molested Mind
Now if only the pr0n industry would hurry up and get with the program.
Fuck Ajit Pai
I'd say that getting rid of the Acrobat plugin is far more interesting.
No sig today...
How to play mp3s in your browser using HTML5:
<audio src="song.mp3">
What, me worry?
it'd be kind of nice to be able to stream music to my Kindle, which for obvious reasons doesn't have Flash, but does have a rudimentary web browser that's based on WebKit.
Hail Eris, full of mischief...
E pluribus sanguinem
Chrome (and I'm pretty sure Firefox too) already supports MP3s without plugins, that's the purpose of the audio HTML5 tag. What is the benefit of this that the audio tag doesn't offer?
It does work indeed, but the sound is pretty jerky while the browser is loading other websites... Maybe a bug (or feature?) in the FF4 JS scheduler.
We've had this kind of functionality for a long time. I don't mean through flash, but there has always been some client-side software that decodes and plays back audio files, usually by one plugin or another. A javascript player basically follows the same model of loading some code on the client machine that does the playing. The only difference here is that it's being done using slightly different facilities.
MP3 is patented so I'm guessing Mozilla and Opera won't pay the license fees for it..
anyone?
And we're there.
No it hasn't. We're talking about a pure JavaScript decoder.
I'm writing a browser in JavaScript that will run on itself !!!
It's more like "no longer agonizingly slow" due to herculean (and well-appreciated) efforts to optimize a language that was just not written for speed. You might as well say you upped the voltage to your Prius and say now it's a "super-fast hybrid" -- people that prioritize speed don't buy hybrids and people that buy hybrids obviously didn't consider speed to be a priority.
This is not a criticism, it's just a statement of fact. Even the fastest javascript engines don't even remotely compete with modern interpreted languages (Java, C#), let alone actual bare-metal code (C and friends). Both have their place depending on what you are doing. Having a natively written plugin handle MP3 decoding with a well-defined API seems to me far more logical than expending effort to write it in javascript, especially when it doesn't even run across all browsers yet.
Then again, that's just my $0.02, and as much as I don't think it's a great use of effort, it's damn cool!
In the future there will be a slashdot posting about a Javascript script being able to post comments to stories on slashdot from a browser without needing a human to be present at the keyboard. When this happens, there will be remarks made about the change in the quality of comments. Some one will welcome the new Javascript comment posting overlords, etc.
Arguably, with the existence of tools like the "Google web toolkit" and its analogs, which let you do the writing in some other language and then convert it to javascript for deployment in-browser, I suspect that javascript's sins against developers will become somewhat less relevant. Admittedly, it almost certainly isn't what you would design if you were asked to design a platform-independent intermediate representation for complex programs; but it is pretty much the only platform-independent intermediate representation for complex programs that you can be fairly sure that any idiot can "install" just by typing something into a browser bar...
It would have been nice if something better had been standardized; but your options pretty much break down into "javascript" or "assorted architecturally superior; but single-platform and/or deeply fucked in the code quality plugins".
I think this was posted due to /.'s obsession with everything mp3.
t
javascript's sins against developers will become somewhat less relevant.
Or do you mean: "developer's sins against javascript"?
Just because there is a history of poor programers does not make the language any less interesting/powerful.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
We have already have html5 h.264 video players for more than a year. Why is it news that from now on we can not only play videos (with sound, probably in mp3 format), but even sound without video?
your options pretty much break down into "javascript" or "assorted architecturally superior; but single-platform and/or deeply fucked in the code quality plugins".
You'd think Java would be filling this role, but it isn't.
The fix is coming: https://twitter.com/#!/nddrylliog/status/81798532717228032
err...that tweet says:
Stuck in my hotel with no SSH access, cannot bring http://jsmad.org/ back up. Going to Starbucks.
Wrong kind of fix.
And once agan, just like with H.264, they wouldn't have to pay any license fees if they just used the OS's own media API instead of trying to support specific codecs themselves.
Modern OSs provide such an API for playing audio and video, and some (ie. Mac OS and Windows) even provide licensed proprietary codecs... not to mention that OS-provided codecs often work with things like video drivers to provide hardware acceleration that is transparent to applications. For example, VLC, while awesome, uses a huge amount of my CPU to play 1080p H.264 video, since it's software decoding (possibly with some generic "hardware assist"). On the other hand, Windows Media Player, which uses Microsoft's DirectShow codec which takes advantage of my GeForce card's full H.264 decoding, uses 1% of my CPU to play the same video.
Browsers already make use of other OS-specific features, and this would make the whole codec licensing thing a non-issue for the browser makers, and for the vast majority of users. They need to stop trying to reinvent the wheel. The OS provides services to applications... browsers should use them.
My guess: yet another person complaining about how JavaScript doesn't use their specific pet paradigms.
I am an expert with javascript at this point, and I can do amazing things with it. But that does not mean that it does not suck. No good IDE's, debugging and validation are a pain. The worst part of all is that its GUI is tied the crapfest that is the modern web browser running any one of a number of almost but not quite entirely unalike implementations of the HTML DOM.
A multi-platform browser tightly coupling itself so that a certain subset of the users can't use some of the features. What a good idea.
This nonsense may inexplicably result in feverish night terrors among those in Redmond, but the rest of us - the best of the best?
Not impressed. Not interested. Don't care. Never will...
Redmond? ITYM San Jose
Intron: the portion of DNA which expresses nothing useful.
Languages are not slow. Algorithms are slow. Execution environments are slow. There is nothing fundamental about JavaScript that makes it slow. Until recently, browsers executed it inefficiently and with few optimizations.
HTML5 browsers already have support for audio file playback, depending on the browser. For example, Chrome can play MP3 and Ogg Vorbis files. Firefox 4 can play Ogg Vorbis but not MP3 due to licensing issues. Safari can do MP3 natively; Ogg Vorbis requires extensions from Xiph.org that are easily installable.
This will allow unthinking people another way to implement one of the things listed in every bad practices top ten list for the past decade: websites that make noise.
My guess would be that native plug-ins will always be more efficient on power than java script interpreted code. Not sure where exactly flash lies in that spectrum. It's a power hog compared to most apps but but my guess is flash has a lot of high level functionality running natively (audio and video) with just the command and control being in the flash language.
Some drink at the fountain of knowledge. Others just gargle.
Can somebody please remind me why we moved from Java applets to Javascript applets?
It can't be just a matter of tight browser-VM integration or GPLiness.
Why are we coding the whole thing all over again?
There is this thing called conditional compilation, ya know. Let alone environment-aware code paths.
Don't blame me, I voted for Baltar.
Anything that can phase out the necessity for Flash is welcome news in the web dev community.
So, yeah. Posting snooty Slashdot criticisms as AC is pretty cool too.
/* No Comment */
No, the problem is that the "standard" has barely changed since Javascript was introduced many years ago. The base language, ECMAScript, is shared with Actionscript (Flash's coding language). Except JS still looks like Actionscript from ten years ago. This comes down to the intractability of the standards committee to move forward with any large design changes due to various corporate dissenters, as well as between the ECMAScript committee and W3C. I mean, the first update since *1999* was in 2009, and that was a very, very, very watered down update (based on the few things the committee could agree on) intended to show everyone they'd made progress, but seemed more like the Bring Out Your Dead sketch. More or less, the ECMAScript committee is the software version of the UN. Now they're planning for another update, but they've already said they won't be adding classes or the things that would pull it out of the software dark ages, and there's no release date.
After that internal meltdown, Adobe pulled a Cartman and continued on with Actionscript development. And who can blame them? ECMAScript/Javascript is a disaster. There's many JS apologists out there who think that Javascript is like some kind of totally expressive free jazz ensemble, and that everyone else *just doesn't get it*, man. The real fact is, most of these Javascript developers have only ever worked in Javascript (or PHP...tomato, tomato) and don't see the performance/efficiency gains of moving to a language with modern features. It doesn't help that browsers are putting nitrous and rocket packs on what is effectively a '78 Pinto; it tends to mask the fact that the language is a hurtling fireball of death. Hey, I sympathize with JS developers. They've been working with the same screwdriver for 12 years. You get used to the tool. Actionscript developers went through the same thing with the intro of AS 3.0, when it moved to a strictly-typed environment with many new language features. But you know, Adobe had the cojones to do that and risked pissing off its developers. Unlike the ECMAScript standards committee.
And so here we are sadly, with a language that has becoming the de facto web language, that hasn't changed much at all in 12 years. A language mostly unsuitable for OOP development. A language that's a pain to debug. A language lacking basic, basic features. It's a '78 Pinto with some racing stripes and a jet engine strapped to the top. But it's totally paid off!
It's always been enough to "do" things traditionally done with C/C++. The problem is that it does it one or two orders of magnitude slower.
Great. But do we really need a story for each and every piece of software written? Secondly, having used this decoder it is no where near as performant as a traditional decoder written in C and assembly optimization. It stutters quite badly.
Except that this does absolutely jack and shit to phase out flash for almost anyone. How many people are saying to themselves "Well I'd only get rid of flash but I need a flash-based mp3 decoder!!". Anyone who is going to want to play mp3s on their computer are ether going to use a media player installed on the system rather than using a browser player to play mp3 files off of their hard drive.
I was worried about the cpu consumption of this and it only took between 7 and 13 % of one q6600 core on firefox 7.0a1 nightly
Jehovah be praised, Oracle was not selected
It's cool that somebody got this working. That said, looking at this sort of things further enforces my belief that we're all barking up the wrong tree by going with JS+html as client side development environment of the future. Compared to a Silverlight solution, the JS player is 3.5 times larger (535kb vs 154kb), uses about 3.6 times as much CPU power (25% vs 7%), and has to have significant modifications to work in multiple browsers. Not really progress.
Hikery.net - The best hiking site ever. Made by yours truly.
go away host file troll
Jehovah be praised, Oracle was not selected
It's useless on my work laptop running FF4.
The sound is so choppy it's essentially noise, and it causes my FF4 memory footprint to triple. This is on a 1.6GHz Pentium M with 1GB of RAM..
Just another example of our wonderful ability to come up with ways to waste immense amounts of computational power. It's completely ludicrous to write a decoder in such a high level interpreted language.. I was playing mp3's on p200's, and whoever did this managed to waste so much time executing bloat that a 1.6GHz cpu can't plow through it in real time. This thing would probably take 2 weeks to play the 1st minute of a song on a p200.
Yep, we can write an mp3 decoder in javascript. But, should that really be our goal?
AutoCad runs on OS X!
It doesn't mean much now, it's built for the future.
Bleeding edge Javascript "compilers" are now fast enough to run some elementary code.
Great, how about they move to real programming languages and compilers instead?
I don't want to need a supercomputer to run Javascript code that would run as fine with a proper programming language on a computer from 1980.
Modern OSs provide such an API for playing audio and video, and some (ie. Mac OS and Windows) even provide licensed proprietary codecs... not to mention that OS-provided codecs often work with things like video drivers to provide hardware acceleration that is transparent to applications.
Canonical licenses both MP3 audio and H.264 video for its OEM partners: which may help to explain why the Ubuntu Linux PC has some presence and visibility on retail shelves.
Licensed Companies, AVC/H.264 Licensees
I would almost go out on a limb and say it does do whatever paradigm they are looking for if they actually tried... but I don't consider myself an expert so I won't go that far. Sure, things like multiprocessing aren't there unless you consider that a feature of individual browser/sandboxes. The only limitations I can think of right now involve said sandboxes, but most core programming strategies that I'm aware of can be done in JavaScript. Some of the syntactical sugar and performance may not be there, but that doesn't mean it can't do it.
Also, I'm not sure that's what he meant.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
1. combine this with Amazon Cloud Drive or Google Music and no, you won't need a system player or local MP3s.
Or you could use the already present music player in Google Music that will probably be far better performing than this Javascript turd that stutters to high hell.
2. MP3 playback requirement is prevalent all over the web, though thankfully it's becoming less common.
But how many of them are actually using a flash mp3 player over an embedded player using the system codecs? Seriously, almost no one is sticking to flash for mp3 playback so this will do fuck all to eliminate the flash plugin.
Maybe, but that doesn't mean the GP is wrong. The design of JavaScript borders on absurdity. It's a terrible language.
And so on.
As someone who programs regularly in half a dozen languages and knows way more than that, in my opinion, JavaScript is the absolute worst of the non-esoteric modern scripting languages. I would much rather code in Perl, and I've grown to really despise Perl over the years, so that's saying something.
Heck, I'd just about pick BF or whitespace over JS. That said, as an output target for LLVM, I'm okay with it.
Check out my sci-fi/humor trilogy at PatriotsBooks.
That subset of users you mention encompass less than 1% of these browser users. Windows, OS X and iOS, Android, Windows Phone 7, even most major Linux distros all come with either build in software decoders or in the case of portable devices come with either software decoders or built-in ASICs for decoding. You would have to be using some obscure Linux distro or willfully choose to not install the codecs needed to make this possible. Such a group of people are statistically irrelevant.
Normal MP3 decoders result in some uncompressed samples that can be sent to the sound hardware through an API provided by the OS?
What API is the Javascript using to output the sound?
I know HTML 5 has a canvas tag that can be used to draw on a surface. Is there something analogous provided for sound?
Um... pandora isn't exactly unpopular, and uses flash to play music to many many people.
IMHO, the roadblock to moving away from flash isn't that local media players were hard to work with or something like that... it's because pandora can lock down the stream more using flash. If it were javascript delivered to the client to play the stream, it'd make it easier to hack, and come at a performance hit compared to flash, and would lack all the other goodies flash gives them.
For any service were I can get access to the mp3's (cloud drive included), I'd much rather use my local media player and have it support that as a data provider.
I agree with where you ended up ("Except that this does absolutely jack and shit to phase out flash for almost anyone"), but not with how you arrived at that conclusion. There are loads of good uses for a web based media player (or media player controller), but this is unlikely to have a substantial impact on any of those for many other reasons.
Yea, because the browser doesn't already do that in hundreds of places in order to perform as fast as possible.
If you're using a firefox backed by Cairo, you're most certainly using OS specific extensions or using an OS with no features worth talking too.
The browser is the shim between the presentation layer of the native OS and the web. Its very job is to provide the native hooks in uniform way so that web pages are rendered.
You have to be tightly coupled with the OSes native features if you want your web browser to work. How do you intend to draw to the screen? You realize that Firefox uses OS specific APIs for doing its IO right? Its not like it uses kpoll for sockets on Windows or OSX. The browsers job is to provide a common interface between the OS and the web so that the web can be experienced on the OS.
Your app won't be doing any graphics or sound without being tightly coupled to the OS, even if you're using some API like OGL and OAL, they are still tightly coupled with the OS, you're just ignoring that fact for the sake of your point of view.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Now javascript based popup ads can run an MP3 of a woman loudly faking an orgasm or a guy screaming "PUNCH THE MONKEY". Maybe we'll even get the fake cell phone ringing sounds like radio commercials just to really make life wonderful.
More frustrating than that, to me, is that while I would love to find a solution that works for those less-than-1% group, I don't think I own any machines that don't come with hardware decoders for all of these things.
Still, it is nice to have another option. This works surprisingly well -- Firefox uses ~40% of an 800 mhz CPU. Chrome used ~20%, but didn't actually play, so it's not quite the same. What we need now is better detection/negotiation, so I can use native HTML5 audio on sane browsers and fall back to hacks like this when they aren't supported.
Don't thank God, thank a doctor!
I can only assume you are either full of it, or running it on a very old system with an outdated browser.
Considering for comparison that this decoder barely registers more than a few % above idle on my CPU monitor apart an occasional singe spike on one of the cores, and definitely does not stutter. This is on my three year old PC.
I don't know what his objection to hosts files is, but mine is this:
O(n)
What's cool about this is that at least for audio, it's actually efficient enough that we can stop caring about whether browsers support a given codec. Maybe use <audio> when supported, fall back to pure JS when it isn't.
All that without relying on any plugins, which means the entire process can sit inside the same sandbox browsers have been building for years.
What we had before this required users to download and install software, and give it full rights to the machine, in order to play back media. It's similar superficially, I suppose, but it has massive practical differences.
Don't thank God, thank a doctor!
Try <audio>, if they don't have MP3 support, fall back to this.
Before this, the fallback would've been Flash, which sucks.
Don't thank God, thank a doctor!
I remember my 486 DX4 100MHz only barely being able to play MP3s. My entire computer would freeze up for the duration of the song though it played flawlessly. I'm not 30 yet and I feel old. Damnit.
how is babby formed?
If you're going to bother signing your posts AC "apk" why don't you just create an account? Honestly, it baffles me.
how is babby formed?
It uses the same symbol for addition and string concatenation, leading to the necessity of ugly hacks like parseInt() that could just as easily be done transparently if the two (conceptually dissimilar) operations had separate symbols.
IMHO, using the same symbol for string concatenation and addition is actually a fairly logical choice that many modern languages implement. The problem is that it allows you to concatenate a string and a number by just converting the number to a string. So 'blah' + 11 gives you 'blah11'. The problem, of course is that if you have input that you expect to be a number but is actually a string representation of a number you may not get what you are expecting ('1' + 1 = '11').
It forces you to pay attention to your data. I hate that. :)
Oh...I forgot to add that I agree with the rest of your post. JavaScript just feels annoyingly hacked together. Working with it is getting better all the time, though, and if we continue to see it used for so many things that were not envisioned when it was created, I expect we will see it modernized...at least I hope so.
Oh, that's easy. You're using IE8. Try getting a proper browser.
Languages are not slow. Algorithms are slow. Execution environments are slow. There is nothing fundamental about JavaScript that makes it slow. Until recently, browsers executed it inefficiently and with few optimizations.
Languages impose constraints that require the execution environment to do more work for a given algorithm written in one language rather than another. Consider the following algorithm in C:
const int N = 1000000;
int someNumbers[N] = GetArrayOfIntsWithLength(N);
int sum = 0;
for(int i = 0; i \LessThan N; ++i)
sum += i;
If you implement this in Java instead of C, it turns out that the call to operator[] must, according to the language constraints, check to see if the value is within the range [0,size) for that array. The JVM may not skip that check and still be compliant Java. So in the end, the algorithm cannot really run as fast on Java because the are simply more operations to be done (to wit, checking that (i > 0 && i \LessThan N) must be done once per iteration.
Now that's not much a slowdown but let's suppose we go a further level up and write it in python (trick question, python already has a 'sum' builtin, also that builtin effectively uses the C version) then it becomes even slower. Each time through the loop, the interpreter must check the types on both sides of the '+=' to make sure they are still ints. Why? Because I can override the int::operator-left-addition to return a string. Now we look up int::operator-left-addition(int) and call that function, passing the two references. That function 'unboxes' the ints (copies them from the heap onto the stack), performs the addition and then creates a new int object on the heap to store the result. Why a new object, because ints in Python are absolutely immutable -- in python, A += B is actually semantic sugar for A = A + B. After we are done with this reference, the old 'sum' object has its reference count decremented and is garbage collected, releasing the memory it held on the heap.
So by the time you are done adding up your numbers in Python, the interpreter has done a massive amount of work that the C version didn't, through no fault of the algorithm and only because of language design choices. Optimizing around those choices is a lot harder than writing a language optimizing for speed in the first instance. On the other hand, I love Python and use it extensively where I think it's appropriate, which is for many non-performance intensive tasks.
Listen to something with an opening speech over silence, like "Eve of the War" (Track 1, Disc 1) from "Jeff Wayne's Musical Version of War of the Worlds", or the bass-heavy opening to "Angel" from Massive Attack's "Mezzanine". You can hear some odd ringing/distortion type effects. Chances are this can be corrected, but I also noticed in the code a fair amount of loop unrolling and table flattening to increase speed. A nice touch, but it does tend to bloat the download a little. Admittedly, it's only text (Which, of course, is highly compressible), but still.
The closest thing it has to actual classes feels like a crudely bolted on hack (like Perl, but with even less syntax support).
In some senses, this is a good thing. The fact that you don't need specific syntax to declare a new kind of object is quite liberating. I can define new object kinds by manipulating old ones, or by the more traditional ruote of declaring a constructor function. You're quite able to set up functions that produce new object kinds when you call them. All this makes the environment very flexible. Yes, there is the down side that certain simple tasks become a little harder, and a certain amount of boilerplate code becomes necessary to achieve them. You can't have everything,.
It uses the same symbol for addition and string concatenation, leading to the necessity of ugly hacks like parseInt() that could just as easily be done transparently if the two (conceptually dissimilar) operations had separate symbols.
Turning a string into a number is an information-losing transformation. In my book, such transformations should never occur automatically, so parseInt() is IMO better than automatic conversion.
Most of the commonly built-in JavaScript APIs abuse developers by forcing them to use callbacks because JavaScript has no notion of blocking calls and doing work in other threads at the same time.
This is an issue with the design of the web browser object model, not javascript itself. To be frank, allowing multithreaded web pages would be a nightmare for browser developers, and is not something I would have expected in any reasonable timeframe. The fact that it is supported (sort-of) by HTML5 came as quite a shock to me.
Worse, most JS APIs (e.g. XHR) don't provide any extra parameters for passing context data through them to your callback. This forces you to do such awful hacks as hiding program data in the DOM tree and building generated helper functions on the fly for every freaking call. Such design makes the use of those functions very, very cumbersome, to say the least.
This is only an issue because you're doing it wrong. JS supports closures, which means you do not need a parameter to pass context data to your callback. You do it like this:
function setCallbacks(object, context) // code that uses context
{
object.callback = function () {
};
}
Or like this:
function bindMethod (fn, object)
{
var boundFn = fn;
var boundObject = object;
var outerargs = arguments;
return function () {
var newargs = Array (outerargs.length - 2 + arguments.length);
for (var i = 0; i < outerargs.length - 2; i ++)
newargs[i] = outerargs[i + 2];
for (var i = 0; i < arguments.length; i ++)
newargs[i + outerargs.length - 2] = arguments[i];
return boundFn.apply (object, newargs);
}
}
object.callback = bindMethod(context.method, context, "additional parameters go here");
This turns the object callback into an invocation like context.method(context, "additional parameters go here", [parameters that would normally be passed to the callback).
JavaScript is actually a very fine language. It is a fully object language (unlike Java), it allows class prototypes (like Ruby), it has first-class functions, closures, exceptions, etc ... many features you'd find in modern dynamic weakly typed languages.
The actual issues with JavaScript are the lack of tools (modern IDE with completion, debugger, testing) and the browser environment you usually have to work with. But you can't really blame the language itself for that.
No, there are many things wrong with Javascript. Just a sample:
1. The == operator. What. The. Hell. (Yes I know about ===; that's beside the point).
2. No true arrays. They are actually maps/associative arrays. (And that's the only thing you get.)
3. No typing. E.g. you can't have a 16 bit int, or an array of bytes.
4. No real integers. Bitwise operations are done by converting from doubles to int, and then back again.
5. Way too much implicit conversion (the stupid '1'+'1' -> '11', but '1'-'1' -> 0 thing).
6. No data hiding of any kind. Everything is public (unless you use crazy hacks). You can't even be sure third party code hasn't modified your classes.
7. Implicit semicolon. It's just a bad error-prone idea. (And I have *no* idea why Go made the same mistake.)
8. No support for proper modules. You basically have to put everything in one file, which wouldn't be so bad if the IDEs didn't all suck.
9. It's basically impossible to reason about performance, partly because of the new-fangled tracing/JIT engines, and partly because the spec doesn' make any
guarantees about complexity.
I'm not saying it doesn't have nice features, it just has a lot of ugly "let's make this easy for noobs" mis-features that actually fuck everything up, which is a shame.
How about compared to having a client side CODEC library in the browser and just adding a one liner to your HTML code?
Seriously my first thought was after all this effort to standardise video CODECs in browsers so HTML could natively display video was WTF! Playing music in a webpage was something that worked fine in the early 90s and now suddenly we're talking about Silverlight, or writing a native coder in Javascript?
Exactly my thoughts.
Also, since Chrome supports all browsers, Safari only MP3, Opera and Firefox only ogg, all you need to support all browsers is MP3, and the audio tag.
That means, the entirety of this functionality is already in the browser, and all you need is 2 file formats, and there's automatic failover with multiple source tags in the audio tag.
Of course, it's still a nice hack and POC of what can be acomplished in JS, but pretending it has real life uses as the article does is just plain stupid.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
hello? We are in 2011. All browsers support the audio tag. All you need is to dual-encode your files in MP3 and OGG to support Chrome, Firefox, Opera, Safari and Explorer. If you are like me, You'll only encode in ogg, which will work in Chrome, Opera and Firefox. Explorer/Safari represents Mac/Windows, so fuck them.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
Grooveshark has already been rewritten in HTML5 ages ago. It doesn't work on Android/iPhone because they want to profit from app sales.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
The closest thing it has to actual classes feels like a crudely bolted on hack (like Perl, but with even less syntax support).
Most of the commonly built-in JavaScript APIs abuse developers by forcing them to use callbacks because JavaScript has no notion of blocking calls and doing work in other threads at the same time.
Worse, most JS APIs (e.g. XHR) don't provide any extra parameters for passing context data through them to your callback. This forces you to do such awful hacks as hiding program data in the DOM tree and building generated helper functions on the fly for every freaking call. Such design makes the use of those functions very, very cumbersome, to say the least.
Yep, as I thought: complaining over the lack of pet paradigms and refusing to learn new ones. You in particular also seem to prefer syntactic handholding to dynamism: an odd case since the arguments you make sound like those of someone who favors PHP. Rather than learn prototype-based OO and closures, you prefer more rigid, static techniques.
It uses the same symbol for addition and string concatenation, leading to the necessity of ugly hacks like parseInt() that could just as easily be done transparently if the two (conceptually dissimilar) operations had separate symbols.
Here you mostly have a point, though I'm not sure how much benefit changing to a dot really gains.
It is good that we can now play MP3 in FF. I remember being stunned when I found FF could only play WAV!
Why is this paired with the chrome image? It's not about chrome, and chrome isn't even mentioned until the second half of the last sentence. If there isn't a suitable image, the firefox one would make more sense as it's the browser that the decoder actually works in.
Anybody want a peanut?
Real closures are great. What passes for closures in JavaScript (defining a function by gluing strings together or using global variables to work around the fact that there is no good way to store any arbitrary data in the constructed function so that it will be available when the function calls it) is not.
Contrast blocks in Objective-C with the disaster that is constructed functions in JavaScript, and there's just no comparison. Don't get me wrong, blocks aren't perfect, either—I wish I could trivially make static (permanent function-local) variables into block variables—but it's a lot better than the clumsy hack that JavaScript programmers are forced to use to approximate a proper closure.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Does this actually work? Every time I've tried to access a variable in the enclosing context, I've had problems with it being undefined. That said, it has been a few years since I tried it. Maybe the browsers were just buggy as all **** back then.
Check out my sci-fi/humor trilogy at PatriotsBooks.
I retract that comment. I've just been informed that something that I thought didn't work actually does. Not sure why it wasn't working for me in certain cases, but since I can't actually find any of my code where closures didn't make local variables available to the enclosing function, I'm going to assume that either I was doing something else wrong or it was a browser bug. *shrugs*
Check out my sci-fi/humor trilogy at PatriotsBooks.
No the language hasn't changed much. People just didn't know what was possible.
Most of the programmers thought it was just a simple language with a lot of bad parts.
Turns out, it is actually a very flexible and effective language and you can avoid the bad parts.
Read a book like "JavaScript the good parts" or watch a video [0][1] Douglas Crockford in it, he wrote that book and the JSON-specification.
[0] http://developer.yahoo.com/yui/theater/
[1] http://www.livestream.com/etsy/video?clipId=pla_1463e546-47ed-4a93-b59a-bd52b236e8b8
New things are always on the horizon
I think Microsoft, Adobe and other vendors are really busy trying to change that.
New things are always on the horizon
I wouldn't call the solutions to 6. crazy hacks, it is just closures.
New things are always on the horizon
JS != Java, so...
I am not devoid of humor.
it sounds more to me like you were talking about the create_function() function in PHP, which actually does work pretty much like you described. PHP recently got closures (with some warts, like having to explicitly specify which variables are made available to the function being specified), but for a long time create_function() was the closest thing it had.
I'm not sure what you mean by #8.
JavaScript is run in order of inclusion. If I create two JS files and in the first I type:
function test() {
this.value = 'hello';
}
In the second I type:
var tester = new test();
alert(tester.value);
It will alert 'hello.' I do not have to have that code in the same file.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
Only a tiny fraction of AutoCAD does, their most basic configuration. All those packages that AutoCAD is actually bought for, are Windows-only.
Contrary to the popular belief, there indeed is no God.