nickfisher

Search is in the header. Is that not what you are looking for?

Performance is definitely the biggest problem with fat client applications. As Twitter found out, by crowdsourcing your hardware, you lose a lot of control of the user experience. If you have a 'traditional' web application and it's running slow, it's really easy to by a couple of new servers and the problem is fixed. We can't buy everyone a new computer (sorry!) and force them to use a recent version of Chrome, so it's a challenge.

In the places where we can control the performance, we do that very carefully: CDN loading of all assets, intelligent caching techniques, and of course, finding and removing bottlenecks in the code.

@jarcoal, would you mind letting me know some of your details which might affect performance (which country you're in, what browser, what speed is your computer)? Email me directly at fisher at soundcloud if you'd prefer not to share here. Thanks.

>What support does SoundCloud's new single-page interface have for IE8 and IE9?

For IE9: some. Backbone automatically detects pushState availability and fallsback to a hashbang system allowing the SPA to work.

For IE <= 8: none.

> Is there any data on how much SoundCloud's transition to a single-page interface decreased latency during navigation relative to the traditional page-loading model?

Not yet, but that would definitely be a metric we'll be collecting. We're still working very hard on increasing the performance, so it'd be a moving value right now.

> I tried to sign up for the beta but the party was full

No worries -- you're in the queue and we're gradually expanding the rollout, so you'll get an email soon. For everyone else, you can join the beta by signing in at http://next.soundcloud.com

This approach does actually address a lot of the complaints:

- Boilerplate is greatly reduced (though still present) - Way less error-prone since you're not relying on keeping two separate lists of dependencies in same the order

But, it still does require rewriting before use (to add the module name), so I don't see a huge win here either way.

I'll also point out that this "sugared" syntax was added to requirejs after we started developing. If it were there at the start, perhaps we would have used that instead.

yeah, that was something we struggled with when designing this architecture. The problem is that you don't necessarily know which subviews can be held onto and which are no longer needed, so the only way to generically handle the situation is to destroy all subviews when a parent view needs to be rerendered. This sound horrible and inefficient, I know, but our way to deal with it has been to be very careful about what triggers a rerender.

Views state exactly which attributes on their model should trigger the rerender when they change, and no others. If you have a very high level view which has a sizeable tree of subviews underneath it, then its subviews will probably be the ones actually displaying data and that it will essentially just be a 'composite' view and will never rerender.

Views which bind to collections (eg: Lists) have special logic for adding and removing subviews without rerendering all of them.

That's not a bad idea actually -- I might look into that. With only one subview, it ends up with the same amount of handlers, so the benefit would only be seen in list-like views with repeated subviews, right?

The source is in sanely separated and named modules in individual files which are concatentated into one for production. We actually concatenate into 4 different files according to how often the source changes (to work best with caching), but yeah, the concept is the same.

Definitely. There already have been some changes since I wrote the post this week, but they'll have to wait until the next exciting instalment. :)

Hi Carlos,

It was definitely something we thought about, and even discussed with the devs from Twitter. Twitter has a very different use-case to SoundCloud. When you follow a link to Twitter, it's usually to read a single tweet (or maybe a handful), and that's it. SoundCloud is visited by someone who is already willing to invest at least a couple of minutes to listen to a tune, and is much more likely to explore the site. Therefore, the value of making further navigation of the site fast (via client-side rendering, etc) is weighted differently at SoundCloud than at Twitter.

You're quite right -- Next is nowhere near complete, and still very much a beta. We're working on the "release early, iterate often" approach. (See http://www.codinghorror.com/blog/2009/12/version-1-sucks-but... http://successfulsoftware.net/2007/08/07/if-you-arent-embarr...)

The main reason is quite obviously for feedback. SoundCloud is a community-driven site, and we want to get really early feedback about features, design, etc. Another part of the feedback is exactly what's happening here with sharing our techniques and seeing the results. Hopefully the outcome of this blog post is that some other people will learn something, but also that some people will point out things so that we ourselves can learn.

> there are many bugs, most features are not implemented,

We're definitely aware of the features not yet implemented, but if you find bugs (or are really missing a particular feature), please do use the feedback form to let us know!

Cheers, Nick

Hi Rudas,

>what were the arguments for/against implementing this functionality from within the templates and not from some place else

It is still quite possible for parent views to construct subviews and insert them into its own DOM at any time, but due to the nature of our views, many of them are UI components, and so it made sense to be able to define both the subview as well as its position at the same time. It makes writing a view with subviews very easy. You simply use the Handlebars helper exactly where you want that view and the rest is taken care of for you.

>You would bind the events on the list (just once, for all items) and find a way to know on which item the event was triggered.

Yes, that's a very common approach to handing DOM events, but it ran against our belief that views should be independent. If a view can only work in a particular situation (eg: nested inside a list which handles its events), then that creates hard dependencies between those two views and you can quickly get into a mess. Event delegation is definitely used in Next, but only at a per-view level. It is a sacrifice (I would posit that it's a minor sacrifice), but the benefits are highly independent and reusable views. We do take advantage of this, too: for example, if you look at the waveform in the player, and the miniature waveform in the header which shows your currently-playing sound (visible in the screenshot), that is the exact same view. Because they handle everything themselves, there was absolute minimum work needed to add that feature.

Thanks for the feedback and the interest, Nick.

Note that I'm just talking about our particular project: YMMV, and using event delegation in higher level views for your own project might provide bigger wins in terms of performance or maintainability.