Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

37signals.com

Post reply on HN
Print view View original

71–80 of 135 posts

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

#71

Post by Joeri »

jd wrote: post #10
mattmanser wrote: post #3

Hmm, 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…

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

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

#72

Post by arijo »

dhh wrote: post #44
jashkenas wrote: post #24

This is all fascinating ... but does it feel like a sustainable approach going forward, or more like a turbo-charged horse and buggy? Developer happiness aside -- there are plenty of folks who like JavaScript just as much as Ruby -- and assuming that we're talking about an non-public-facing app (like Basecamp Next), is there still an argument that can be made in favor of doing your UI on the server side? Even just in…

I'm not sure what qualifies as sustainable or not in your book. We've achieved our speed goals (sub 100ms pages for the most part), our development goals (Ruby, Rails, server side pleasure), and our UI goals (app that feels like a web page, not just a single-page JS app). I'm sure Flash or Silverlight or other RIA people would argue that anything that's not a compiled native experience isn't as flexible or as fast as…

Also, bashing javascript client-side frameworks makes great link bait.

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

#73

Post by danmaz74 »

MatthewPhillips wrote: post #38
latch wrote: post #29

Earlier quoted context omitted.

I don't understand why "it can't possibly be close to as fast"? Is the idea that with client-side templating, you've distributed the rendering? But returning a cached html fragment is the exact same amount of work on the server as returning a cached-json value. Plus, it's less work for the client to drop the already-rendered html into a container than to have to bind the model to the template. I feel like I'm being s…

Don't overlook the bandwidth overhead of html fragments vs. json snippets. That issue is magnified on mobile. Additionally, if you are doing small updates the DOM API is faster than injecting .innerHTML. I think this has changed in recent years and .innerHTML might have caught up for larger nodes. I personally still use the DOM API because it encourages more simplistic layouts.

IIRC, innerHTML is actually faster than the DOM API, if you have to make the same changes...

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

#74

Post by hollerith »

VMG wrote: post #46
latch wrote: post #29

Earlier quoted context omitted.

I don't understand why "it can't possibly be close to as fast"? Is the idea that with client-side templating, you've distributed the rendering? But returning a cached html fragment is the exact same amount of work on the server as returning a cached-json value. Plus, it's less work for the client to drop the already-rendered html into a container than to have to bind the model to the template. I feel like I'm being s…

A small change in state can cause a large change in the view. When the server renders the html, it has to send all the portions of the view that have changed. When rendering client-side, the server only needs to send the portion of the state that changed.

>A small change in state can cause a large change in the view.

It can, but maybe there is a way to write Basecamp so that large changes in view are rare.

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

#76

Post by Joeri »

latch wrote: post #29
jashkenas wrote: post #24

This is all fascinating ... but does it feel like a sustainable approach going forward, or more like a turbo-charged horse and buggy? Developer happiness aside -- there are plenty of folks who like JavaScript just as much as Ruby -- and assuming that we're talking about an non-public-facing app (like Basecamp Next), is there still an argument that can be made in favor of doing your UI on the server side? Even just in…

I don't understand why "it can't possibly be close to as fast"? Is the idea that with client-side templating, you've distributed the rendering? But returning a cached html fragment is the exact same amount of work on the server as returning a cached-json value. Plus, it's less work for the client to drop the already-rendered html into a container than to have to bind the model to the template. I feel like I'm being s…

The big advantage of client-side rendering is that you can break out of the mindset of outputting blobs of html from templates. You can think in terms of ui elements and the business logic that drives their creation and updates. Once in that mindset, you can think about how to prefetch data and store it locally to not have to go to the server for every ui update. If you're doing it right, many actions don't require going to the server at all.

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

#78

Post by smokinn »

arturadib wrote: post #56
dhh wrote: post #55

Earlier quoted context omitted.

Is that supposed to be a slam? I've been working on "custom" platforms for the better part of a decade.

Hence why you're trying at all costs to make it work with things it wasn't designed for?

I'm pretty sure he knows what it's designed for better than you given the fact he's the one who designed it.

Rails was literally lifted out of Basecamp into a standalone framework that works great for CRUD-style apps. You might personally prefer another approach or think this design failed but Rails was definitely designed for this use case.

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

#79

Post by MattRogish »

dhh wrote: post #64
jashkenas wrote: post #62

Earlier quoted context omitted.

By "sustainable" I'm getting at the point that if you're already doing 50/50 Ruby/JavaScript ... it makes you wonder which direction that ratio will tend to go in the future. Will Basecamp Next Next still be rendered as chunks of HTML that are sent over the wire to be inserted into specific spots on the page in 2015? Either way, I'm very much looking forward to using the new version.

In terms of client-side MVC vs server-side renderings, the ration is more like 90/10 or 95/5. We have one major section that's all client-side MVC, which is our calendar. We have one tiny section as well, which is a little invite widget. Everything else is server-side renderings. To me that's like how we in the past used Flash to play sounds in Campfire. Or reimplemented a poller in Erlang. Or use nodejs for the deve…

Hi DHH,

Huge fan of your work. Been in love with Rails since the pre 1.0 days. Our team internally (we have an existing Rails 3 app that we want to improve rendering performance) has been going back and forth with "Rails should emit JSON and render client side" and "We should be smarter about caching and AJAX-ifying our pages".

Your post has given more ammunition to the Rails-only side, so that is really awesome; thanks for that!

There are reasonable arguments on both sides.

For Rails Improvement: * We know Rails * Scaling Rails is a solved problem * You can "just throw money at it"

For JS UI: * We know Javascript (http://www.github.com/toura/mulberry) * Why spend server $$ on boring HTML rendering? * We have better GUI test tools in the framework side (we can unit test our componentized JS GUI much easier than a mashed-together Rails ERB HTML) * We don't have that much money to throw at it, and that's wasteful besides

Presupposing, of course, that the server rendering JSON takes less time than stitching together ERB and the developer toolkit isn't any harder, would you find it more interesting?

Thanks,

-- Matt

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

#80

Post by romaniv »

ColinCampbell wrote: post #48
latch wrote: post #29

Earlier quoted context omitted.

I don't understand why "it can't possibly be close to as fast"? Is the idea that with client-side templating, you've distributed the rendering? But returning a cached html fragment is the exact same amount of work on the server as returning a cached-json value. Plus, it's less work for the client to drop the already-rendered html into a container than to have to bind the model to the template. I feel like I'm being s…

The important thing is that client-side rendering stays on the client and doesn't need to go back to the server. If you have any noticeable latency (read: everything on mobile, desktop clients not close to a server), needing to go back to the server to render will ruin the perceived performance of your app. Well-written applications running on the client can take a change and optimistically render that before the cha…

The important thing is that client-side rendering stays on the client and doesn't need to go back to the server.

It still needs to go back to the server to fetch new data. And it's not like rendering on the client side is instant and free. There are plenty of JS-heavy websites that visibly lag during UI operations because of all the stuff that goes on during "rendering" (in quotes, because it usually includes large chunks of business logic).

Post reply on HN