How Basecamp Next got to be so damn fast without using much client-side UI
1–10 of 135 posts
Re: How Basecamp Next got to be so damn fast without using much client-side UI
#2Cross posted from a comment by DHH on this post
>> We use nodejs for local development via Sam’s Pow server, but there’s no nodejs in Basecamp Next itself. It’s all Ruby on Rails. We’re running the default stack using Rails 3.2+, MySQL 5.5, Memcached, a tad of Redis (mostly for Resque), ERB , test/unit, CoffeeScript, Sass, and whatever else is in the default box you get with Rails.
Re: How Basecamp Next got to be so damn fast without using much client-side UI
#3Hmm, degraded development experience of doing everything on the client?
Bit of a bizarre claim there given the state of templating these days. Sounds more of a prejudice than an actual problem.
Also json tends to be much lighter than HTML and if you're taking an optimistic view of updates you can assume the action's been a success and even immediately update the display without waiting for the server to create some simple HTML, so it's arguably a worse user experience due to the lag.
Re: How Basecamp Next got to be so damn fast without using much client-side UI
#4[deleted]
Re: How Basecamp Next got to be so damn fast without using much client-side UI
#5Hmm, degraded development experience of doing everything on the client? Bit of a bizarre claim there given the state of templating these days. Sounds more of a prejudice than an actual problem. Also json tends to be much lighter than HTML and if you're taking an optimistic view of updates you can assume the action's been a success and even immediately update the display without waiting for the server to create some s…
We've found that the additional overhead of sending HTML vs JSON is negligible in most cases. The additional speed gained by just sending JSON across is not worth the programming enjoyment hit of doing everything client-side.
When you get below 50-100ms per action, things are generally fast enough that this is not a key problem any more. The user cares greatly if you can go from 800ms to 100ms, but not so much if you can go from 100ms to 70ms.
Re: How Basecamp Next got to be so damn fast without using much client-side UI
#6Hmm, degraded development experience of doing everything on the client? Bit of a bizarre claim there given the state of templating these days. Sounds more of a prejudice than an actual problem. Also json tends to be much lighter than HTML and if you're taking an optimistic view of updates you can assume the action's been a success and even immediately update the display without waiting for the server to create some s…
Your comment ignores the next section in the article, detailing how they are caching templates with a high level of granularity, and actively removing template logic that impedes efficient cacheing.
The article goes on to state that delivery times for cached segments of HTML are under 50ms in most cases. While I agree that it would be possible for them to improve the user's perception of the app performance even further via JSON or client-side updates, with the level of performance they described that type of improvement is unnecessary and introduces additional vectors for bugs to creep into production code.
Re: How Basecamp Next got to be so damn fast without using much client-side UI
#7[deleted]
That is not even close to what is being described in the article.
Re: How Basecamp Next got to be so damn fast without using much client-side UI
#8Re: How Basecamp Next got to be so damn fast without using much client-side UI
#9Hmm, degraded development experience of doing everything on the client? Bit of a bizarre claim there given the state of templating these days. Sounds more of a prejudice than an actual problem. Also json tends to be much lighter than HTML and if you're taking an optimistic view of updates you can assume the action's been a success and even immediately update the display without waiting for the server to create some s…
Stacker sounds like AJAX as it was done in 2006, except trigger by pushState. Maybe I'm misunderstanding it though. I'd be curious what the performance penalty is on mobile.
Re: How Basecamp Next got to be so damn fast without using much client-side UI
#10Hmm, degraded development experience of doing everything on the client? Bit of a bizarre claim there given the state of templating these days. Sounds more of a prejudice than an actual problem. Also json tends to be much lighter than HTML and if you're taking an optimistic view of updates you can assume the action's been a success and even immediately update the display without waiting for the server to create some s…
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.