[deleted]
That is not even close to what is being described in the article.
[deleted]
How Basecamp Next got to be so damn fast without using much client-side UI
11–20 of 135 posts
Re: How Basecamp Next got to be so damn fast without using much client-side UI
#12Hmm, 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…
Programming enjoyment is, of course, subjective, but for your team the enjoyment is ruby, understood :)
What browsers are you getting the 50-100ms numbers? Similar results on mobile (with a 3G connection)?
Re: How Basecamp Next got to be so damn fast without using much client-side UI
#13Hmm, 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…
Exactly what I thought. But you have to remember that 37 is the quintessential Rails shop - client-side logic is not their sweet spot.
So it's only natural that for their flagship product they'd rather keep pushing the limits of their comfort zone rather than go all out client-side, no matter how natural that choice might be for a "web app".
Re: How Basecamp Next got to be so damn fast without using much client-side UI
#14Re: How Basecamp Next got to be so damn fast without using much client-side UI
#15Interesting. We've just had a discussion in our team about moving as much as possible to the client becasue... developers enjoy writing CoffeeScript!
Re: How Basecamp Next got to be so damn fast without using much client-side UI
#16Earlier quoted context omitted.
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…
Programming enjoyment is, of course, subjective, but for your team the enjoyment is ruby, understood :) What browsers are you getting the 50-100ms numbers? Similar results on mobile (with a 3G connection)?
50-100ms is the time it takes to generate the response on the server. On top of that you have to add the ping time between you and server and whatever other network overhead there is.
That's why it's great to be closer to 50ms so you'll stay under 100ms even with the network overhead.
Re: How Basecamp Next got to be so damn fast without using much client-side UI
#17Hmm, 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…
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.
Re: How Basecamp Next got to be so damn fast without using much client-side UI
#18This is very similar to what Google+ does with Closure Templates.
Re: How Basecamp Next got to be so damn fast without using much client-side UI
#19I have to say, reading this made my day. I've been feeling such a push towards client-side templates lately, that I felt like it was just me that didn't get it. I really don't understand what's so compelling - unless those exact same actions are actually (YAGNI) used as endpoints of a web service. render :partial => '..' is such an sweet, simple and natural paradigm to web programming.
Re: How Basecamp Next got to be so damn fast without using much client-side UI
#20Hmm, 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.
Well, it's really stacker + pushState + MAX cache.
But why would there be a performance penalty? Doesn't this result in the client doing _less_ work all around? Less work than the multi-page approach...and less work from the client-side templating approach, no?