Grooveshark's new Javascript/HTML interface
listen.grooveshark.com
listen.grooveshark.com
That being said, I always thought their Flash app was amazingly slick and polished, so it's a tough act to follow I suppose.
EDIT: Plus if they are going to go this far with HTML5 it'd be awesome if they could cut the Flash cord entirely. Not sure if that's technically possible though.
On Ubuntu 10.04 x64 Flash is pretty stable for me, except when I've got 40 Firefox tabs open (yes I'm seeing a therapist about that) and then try to run some Flash app that's more complex than a mere Youtube video. No more popping htop to manually kill nspluginwrapper that's in some kind of infinite loop ftw.
Besides that, it's awesome, even better than before.
Hat-tip to Gruber for the idea http://daringfireball.net/2010/11/flash_free_and_cheating_wi....
Update: Come on there's no reason to downvote this. At least explain why you're downvoting this, for example, Opera killed your puppy.
What is unfortunately happening is rather than testing to see if the site will work in Opera, developers just exclude it. They've made lots of progress over the past few years to get their browser up to snuff. I just recently switched to Opera after Chrome started lagging during the 1.6 update.
Idealy, developers could target one set of standards and their product would be functional across all browsers that implement them. In general, the bigger browsers all act relatively the same (not IE) when standards-compliant code is used, so if what works for them doesn't in Opera, then that's a problem.
It's not the developers' jobs to make their sites work with Opera (especially when it works in IE, Chrome, Firefox, and Safari). It is Opera's job to make sure they render sites comparably to other leading browsers.
If that means they rip out their rendering engine and replace it with Webkit, so be it.
Coding wrong and passing the problem to the browser is just mean
BTW, different rendering engines, assure no monopoly, innovation and competence, which is always good.
Go through them and let me know if you still believe that Opera doesn't try hard enough. The problem is that being standards complaint is harder than it soudns. A lot of the nitty gritties aren't explained in standards and diff browsers implement them in diff ways. While developers explicitely implement patches for Fx and IE, they generally ignore Opera. And that's why so many websites don't work in Opera.
And that's wrong, css attributes whose drafts aren't final yet should not be labeled as such by Opera.
The only reason to support Opera is personal good feelings toward Opera. The userbase is insignificant, Opera doesn't further any given political goal as they aren't open-source and they are several more-popular open-source browsers in the market that are tested against. So what's the point of supporting Opera other than just liking Opera and wanting it to be usable with your site? Not that there's anything wrong with that, but rarely is it a cost-efficient procedure.
It's frustrating since I just recently switched to Opera and personally find that it performs great, it feels better to me than Chrome, and overall I really like it. The biggest issue I've experienced and the biggest hurdle Opera has is the wholesale exclusion many sites partake in, usually via a if(opera){ //don't support}, rather than feature testing.
But then again, maybe they _did_ test it in Opera and saw it didn't work, but couldn't justify fixing it from a cost perspective. So, would you rather have the thing just be all broken or have a sign saying "This is broken in your browser, sorry"?
That being said, Opera is a nice browser and has gotten better and better with time. I of course encourage projects that can and should to support opera, but there are plenty of reasons not to support it and in most of those cases they're right not to do so.
I've tried it in Opera, and it's perfectly usable apart from some weird scrolling issues where you can scroll the whole site off the page, and sometimes Opera doesn't seem to want to redraw some items in the songlists without scrolling a bit.
Just click the "Let's take a chance" button when the browser compatibility lightbox opens and the site will let you in.
"We've tested the new Grooveshark in modern versions of Firefox, Chrome, Internet Explorer, and Safari.
It looks like you aren't using one of these browsers."
I guess ask them, but to me that reads like "Recent versions of these browsers have been tested. You aren't using something we have tested on."
Good job, though, Grooveshark folk! I love the updates so far.
edit: just tried the site in Firefox ; can't even get the sign-in form to react. :(
Seems OK in Chrome, but at least the Flash version worked in FF for me.
We tested pretty extensively in Firefox, but there's always things that can go wrong. Also if you think you have any info that will help us fix it, hit up the Contact Us link at the bottom of http://help.grooveshark.com/
So, on the one had, the trouble is at my end, but on the other hand most sites have no trouble with my add-on arrangements, so there's something that's at least a little sensitive in the GS scripting.
1. Last.fm scrobbler 2. Lyrics plugin (same as winamp has) 3. put 'now playing' list at the right sidebar 3. make 'now playing' list thinner. etc.
Shhhh... Don't make them regret doing it. :)
How was JVMC? Was it very useful using the MVC format in your JS, did you end up using it mainly for classes or did you do the whole MVC format?
Why JMVC over something like Backbone?
A write up on this in a blog would be awesome.
Was Javascript templating useful? It seems to be me that it would be very slow (though faster than doing async request to servers I suppose).
As a project lead at my last job I championed jmvc for a new project. We had mostly good results but there was always a couple developers who were against it (and who IMO worked to undermine it).
We were building a very ajax-heavy UI for an Ad network. Think.. Adwords UI meets MailChimp UI.
In our case, my biggest worry was how easy it is to write spaghetti JS. A classic example is a page with several JS includes and they all are binding to the same event (or to different events on the same element). You're in one file working and you have funny results and you only then discover the event handlers in the other file and then you have to refactor the whole mess. We actually had that a lot in a previous project.
Also, 2 things jmvc did that excited me:
1. Easier JS unit tests. 2. Fixtures! You can build and test the JS without relying on the server to send you the json you need.
I wish you guys the best of luck and thank you sincerely for continuing to innovate.
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.
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.
As for the audio tag, see one of my other comments, here: http://news.ycombinator.com/item?id=1968640
Im a lead senior flex/flash dev in the UK, building apps for ferrari, mercedes, banking finance etc.
I've used Grooveshark for many years now.
I'm interested to know why Grooveshark switched to the html js front end as a business decision?
I actually have an Rdio account, because I have a curious bias towards web sites with sexier names/subconsciously believe I am judged by the names of web sites I use. When I joined I had the impression that Rdio would only let me listen to unlimited songs if I paid you money. Now I see that's not the case, so I'll give your service a go.
First thing I don't like is that you don't give me a big search bar. I'm not paying you money. I don't want to log in. I even resent Grooveshark's making me log in to share songs, that's how lazy I am. (I do have a Grooveshark account, which I rarely use.) So the fact that your front page looks more like a product than like an easy service, that scares me away.
I think the two most common-looking site designs are: search bars and product pages. Product pages are universally ugly and I run away from them actively. Search bars I will type in something and see if the engine meets my whims. So Grooveshark's front page sells more.
Rdio fails the Cardiacs test: http://www.rdio.com/#/search/cardiacs/ returns nothing, whereas Grooveshark gives me almost their full catalogue. Cardiacs is my general test of band obscurity: If you have them you're bound to have most of what I want, and if you don't then I trust you less. (You both fail my Victoria Pipe Police Band test, which is pretty sad, because I request my fervent demand for pipe music be sated. >:( )
When I go to a band's page, I get something that looks like informational bullshit. Which is nice — I use Last.fm for my band-related nonsense — but when I want a music player I want small entries that show me as much music as possible. If I search a band I want three albums on my screen simultaneously. Grooveshark gives me a LOT of music, and fast.
But here's the clincher:
When I go to play music, you ask me to sign in or register. BAM! I'm looking for a new site. I don't like giving out my email address. I don't like picking new secure passwords. I will only do it if I think you're worth the effort.
Right now I use three sites to listen to music. I use Grooveshark, or I use Bandcamp, or I use TheSixtyOne. Occasionally I use Pandora but that's WAY rare. Grooveshark's for general music hunting; Bandcamp is for searching for and buying music, and listening to musicians I know use it (like Sufjan Stevens); TheSixtyOne is when I want to explore random music. Each one is designed specifically to mimic my usage pattern. They look the way I want them to look.
Rdio looks like a college design project. (I'm not saying it looks bad. I go to a design college.) While it's pretty, it's not very functional — you have a lot of design choices that go against the way I'm trying to use the site. Kind of like when search engines make gangly content-crammed designs that stop me from actually finding what I'm searching for. I'm going to stick to the stripped-down tool that does what I want when I want it.
If you want to compete with Grooveshark, go slimmer, more efficient, and sexier. Make it easier for me to find the music I want than Grooveshark, easier to share, easier to — anything. If you don't, I have no reason to even contemplate switching. The good news is that I'm not loyal to Grooveshark beyond my affection for its design; because I don't have an account or use more features, I'm not entrenched. If you do something convincing I'd consider moving over.
Feel free to discuss this more with me, either here or in email. I love discussing design philosophy.
And if you work there - shame on you.
They in essence encourage you to upload copyrighted works so you can access your music anywhere, and from a first glance at the interface it's not even excessively clear that you're sharing your music with others by uploading (as opposed to it being a private library).
This of course is all further complicated by the fact that they apparently have licenses with some labels, and not others. I would presumably be able to legally upload some music, but not all (I guess YouTube actually has the same issue there).
Add to this the fact that the RIAA has shown it doesn't mind suing end users at all, and I wouldn't upload anything to Grooveshark. Incidentally I also wouldn't upload anything copyrighted to YouTube.