How Basecamp Next got to be so damn fast without using much client-side UI

Re:How Basecamp Next got to be so damn fast without using mu... by jd on Friday February 17, 2012 @10:11AM (#3603552)

When you have a persistent page (that you update with HTML5 push-state) you suddenly have to worry about issues like memory fragmentation. If you do lots of small updates to build a page from a template + JSON every time the user navigates it's easy to hit some situation where everything starts lagging for no clear reason.

If you simply swap out a large part of the page with some HTML right out of an Ajax request you don't have to worry about any of that.

[ Parent | on HN ]

Re:How Basecamp Next got to be so damn fast without using mu... by arturadib on Friday February 17, 2012 @10:25AM (#3603606)

Let's be fair - poorly designed code causes memory bloat whether you're on the client or on the server-side.

Also, garbage collection efficiency in browsers is a metric of fierce competition among browsers. It's superb already, and it's getting awesomer by the minute. It's a safe choice for the future.

[ Parent | on HN ]

Re:How Basecamp Next got to be so damn fast without using mu... by Joeri on Friday February 17, 2012 @01:09PM (#3604308)

And when you do everything client-side, you have to worry about memory leaks. Where the state is, is where the memory pain is.

[ Parent | on HN ]