As far as I can tell, it's written with PHP serverside, Javascript (jQuery JMVC) and HTML/CSS. The actual music player is a hidden flash widget, but the song selection, playback, and entire interface is in HTML/CSS not Adobe flash as previously. (And the adobe flash version had horrible performance on linux).
Hi, I'm one of the developers. You are correct. We have a PHP backend, actually the same one that we were using with the flash frontend, and are using jQuery with JMVC, and slickgrid for the huge lists of things. The invisible flash widget provides both music playback and serves as a proxy for getting around some of javascript's crossdomain restrictions (like the fact that you can't make https ajax requests on a page served on http) and talking to third-party services like facebook and last.fm which have perfectly nice crossdomain.xml files.
Feel free to ask me any questions, though I don't know details on a lot of the deep workings of the backend - I'm an Actionscript/Javascript dev.
Oh and thank you so much for not submitting this as 'Grooveshark switches to HTML5'!! Because it's not. We're not doing anything you couldn't do years ago, except maybe that JS performance wouldn't have been fast enough for such a heavy app.
No Problem.
I think seen the widget before on make your own player page (which I've used because the old flash frontend was so very unstable on linux).
And - the switches to HTML5 part - I would only post that if you somehow worked out how to use the html5 <audio> tag, but that has many drawbacks.
Thanks so much for the work on the frontend - It's one of the few online music streaming services now that is decently fast and doesn't eat resources on linux.
It's not the exact same widget, but it does use the same classes. All our flash playback, in the old flash app, the new invisible player, the even tinier invisible player on the widgets.grooveshark.com page, and the actual widgets on said page are compiled with the same core playback classes.
Great job. Having done something similar for a prototype (using JS to control Flash players), I must say that it takes a great deal of work to get it all nicely. I'm assuming that you're using ExternalInterface to communicate with the player?
Also, is there any reason why you guys didn't replace the Flash with HTML 5's <audio> tag for browsers that can support it? Security issues maybe?
I've been writing Grooveshark's players since the beginning, so I'd pretty much consider myself at an expert at getting flash to communicate with other moving pieces by this point.
We've gone through some pretty crazy revisions, including one (ancient) version, back when the actual playback was performed by a locally installed client application written in java, yet the actual playback controls were located on the website in a small flash widget. That involved the use of the script-tag hack (I think nowadays most people call that JSONP) in javascript to confirm that the local client was running, ExternalInterface to tell flash that it was safe to attempt to load the crossdomain.xml file from the local client (it would quite stubbornly refuse to try again after a failure), and then an XMLSocket connection between the local client and the flash widget on the page in order to pass back and forth user commands and the current playback state.
It actually worked surprisingly well, but I'm really glad we've since moved to centralized server streaming. The current version is just as you said, an invisible flash widget that syncs to the javascript on the page via ExternalInterface.
How do I keep it from timing me out and stopping playback after a few minutes? With the fully flash version, it only did that if I went truly idle - with this version, if I leave it running in another tab while I work I periodically have to tab over and click the "I'm still here!" button.
As a fellow ActionScript developer, I congratulate you and the rest of grooveshark frontend team on doing a brilliant job with the flash UI. I always point people to Grooveshark, for an example flash based UI (and also remind myself, its not that the tool that matters, its the craftsman.)
I had actually just assumed this was all HTML (and thus HTML5) because of the previous html.grooveshark.com subdomain. Doh! Great job and thank you for the great work!
Perhaps eventually. It's something we've looked into, but we have some content security concerns. Obviously it's not impossible to rip our content with flash streaming, but it is more difficult than something that can be written with an <audio> tag.
Someone could easily steal my car's stereo even if I lock the doors, by using a slim jim/lockpick (downloader tool) or smashing my window (rip audio straight from the sound card). There's no way to 100% stop determined people from stealing my stereo, just like there's no 100% way to stop determined people from ripping our content. But that doesn't mean I leave my car unlocked.
Also right now we use the flash piece as a proxy for making service calls that would be otherwise significantly more difficult/impossible through javascript's crossdomain restrictions.
Could you at least make the flash object visible somewhere so that we could un-Flashblock it? (Anyway we can always whitelist in each computer we use it, but it would be nice)
This is one of the major limitations of the HTML5 + Javascript stack, and one that will have to be solved before we see even more widespread use on services like Hulu or Netflix.
It might not say it is encrypted, but I doubt the publishers/who ever they have deals with to stay legal would allow them to transfer copyrighted materials in the clear.
