Hacker News Reader

Comment by dhh | Hacker News Reader

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 whatever they're peddling. Meh.

Yes, it's great to occasional dip into advanced client-side when that's needed. Just like Flash had its legitimate use cases here and there. But for the bulk of the UI interactions we're giving people, it's just not needed (or desired).

View on HN

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 development Pow server. Use all the great tools available in the niches where it makes sense.

But the bulk of Basecamp is exactly the type of application that makes wonderful sense to do in Ruby and Rails. We've been sending down chunks of HTML in response to Ajax requests since we started doing these types of apps in 2005. So far I haven't seen anything to make me reconsider that approach for the majority cases.

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

Matt, I don't think there's all that much difference in money spent (you still need to buy servers either way and you still need to cache even if you return JSON). We crank out functionality faster when it can be done server-side because the development experience is better and because Ruby still beats even CoffeeScript (although not as thoroughly as it used to beat vanilla JavaScript) for productivity.

I find the complexity needed in having MVCs on both client and server side to be the main problem. Especially since much of what applications like Basecamp are not all that heavy on the UI-interaction. A few bits are, like a calendar, so we use it there.

But obviously you can make it work either way. Just like Facebook manages to make PHP work. And some crazy kids still use Java. You should pick a development environment and style that fits your brain and your sensibilities. If you think client-side development is lovely, then by all means, go to town. Some people even think JavaScript is still as well as Ruby and that you don't even need CoffeeScript -- peace be with them.

I'd be curious as to how much benefit could be derived by moving the business logic in the server side MVC to the database in the form of triggers, stored procedures etc. Seems like that's the really natural place for some of the functionality, such as validation, that can't be implemented safely client-side.

DHH,

Thanks for the reply. Look forward to using Basecamp NEXT (we use all the 37 signals products here) and seeing the evolution of your process as you continue.

-- Matt

In terms of client-side MVC vs server-side renderings, the ratio is more like 90/10 or 95/5.

DHH, I think you misunderstood here; I believe Jeremy's referring to the blog post where you said Basecamp Next had almost as many lines of CoffeeScript as lines of Ruby. I think that's where the 50/50 number came from.

I'm less curious about the performance here than I am about the maintainability. I saw a tweet where somebody said he'd done things the same way and encountered a maintenance nightmare -- he mentioned nested caching and pjax specifically -- but without context or detail, I'm taking that with a grain of salt. I think disregarding it completely would be a mistake too, though.

It's also kind of tautological that DHH is going to have a more pleasant experience developing in Rails than he is in other frameworks. ;-)

On 50/50, yes, we write lots of JavaScript for Ajax. We've done that since 2005 with Tada list. The debate here is over whether going client-side MVC for everything is a pleasant experience. I contend that it is not.

The maintainability story with pjax+caching is exactly the same as its always been with a Rails app. We just celebrated 8 years with Basecamp. That's a pretty good run.

You can write shit, unmaintainable code in anything, but to point at pjax and granular key-based caching schemes as somehow specifically prone to this? What? That doesn't make any sense to me.

We also had a swanky in-house client-side MVC framework cooking with Cinco. We used it once for Basecamp Mobile and while it was a good experience and the end result was great, it did little to sway my thinking on client-side MVC being a step forward in programming happiness (one of the key things I evaluate platforms by).

Again, it's perfectly fine to have a different opinion. I don't like the aesthetics nor the sensibilities of Python code much, but I certainly respect that people can make cool shit with it and even that they might enjoy the process.

The hoopla here is over the terribly flawed notion that client-side MVC is somehow The Future of web development and if you don't follow that pattern, you're living in The Past. Ha.

"You can write shit, unmaintainable code in anything, but to point at pjax and granular key-based caching schemes as somehow specifically prone to this? What? That doesn't make any sense to me."

To take things to the extreme, if you chose to write Basecamp Next in pure x86 assembly (for speed, of course), I think we'd all agree that the code would be much more prone to maintainability problems. Similarly, it is plausible that choosing to write Basecamp Next entirely with pjax+backend MVC+granular key-based caching could be more prone to maintainability problems. Not that I have any particular reason to believe it will, but we're wondering if there are any particular reasons you believe it won't?

Because neither of those elements have any bearing on maintainability beyond what is customary for a Rails application. The wonders of pjax is that it doesn't require you to change your application style and structure at all, so it has zero impact on maintainability.

The granular caching scheme is similarly just a fragment caching setup using key-based expiration. Nothing new here, just that we used it to full effect.

So you're free to claim that writing Ruby on Rails applications are somehow inherently hard to maintain, but you'd be fighting against 8+ years of evidence to the contrary. Versus, you know, a very short amount of comparable evidence for JavaScript MVC applications based on current, recent frameworks.

I'd like to hear more about this, ideally in a blog post or two. I think a lot of people were waiting for Cinco's release, certainly I was, because we wanted to see what you'd do with it. The fact that you have Basecamp Next running without it certainly says something, but I'd be a lot more interested to find out what the specific tradeoffs were.

I'd argue server side performs much faster than client side.

app that feels like a web page, not just a single-page JS app

I think this is a key point and is one reason that server-side approaches will be relevant for a long time to come. Some applications, such as Gmail and Pivotal Tracker, feel a lot like desktop apps, and heavy use of client-side code is a necessity in these cases. But many—I'd argue the vast majority—of web applications produce a better user experience when they feel like ordinary web pages. I don't see that changing any time soon.

yeah, I agree. actually I don't know if I'd agree on the "vast majority" part, but the question of "is client-side MVC The Future?" can get kind of silly and messianic, while the question of "is client-side MVC A Future?" is undoubtedly yes.

there's a lot you can do browser-side these days which would be insanely masochistic without client-side MVC, but that doesn't change the fact that lots of very useful apps run on the ordinary web pages model.

I think that is kind of a strawman.

Neither flash, flex or silverlight are being pushed these days for these kind of services.

Like the new design and with that I don't mean so much how it looks but more how it looks like it's going to feel using it.

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

Who's bashing what? The author simply described some caching techniques and got a tsunami of hatred from JavaScript, ahem, fans in response.

I think in most cases it will be more than 100ms. Much more than that. Just latency to basecamphq.com is 350ms from here (Europe.)

OP is measuring page render time on the server. Network latency is variable, and there isn't much one can do to fix it.

What does the user care if the time is spent rendering, transmitting or baking cookies?

I am not sure what point you are trying to make.

1. Controlling how long page render takes at the server is under the developer control.

2. The size of network load is under developer control.

3. Client side optimization are under developer control.

OP is saying 1 is low; 2 is low(not much difference between html load and json load); and 3 is low as there isn't much going on at client side.

Other than that:

1. User network is slow, hence leading to large load times.

Go bake potatoes - can't help.

2. User is located at a distant location from the server.

If the user is part of a market which the company sees as profitable, the server can be mirrored.

Or else you can go bake potatoes.

Well the point is that by doing rendering on the client side you get most of the latency issues out of the way on first load and actually have a lot more control over its effects on the user even after that (e.g. you have the option of syncing with the server in the background).

Whether the data is sent via HTML or JSON it will still incur the network latency.

DHH - if you guys keep working so hard on your custom platform one day you just might be able to reproduce the client-side JSON+JavaScript stack!

Keep up the hard work!

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.

And you work for "Mozilla Labs"? As a volunteer, or do they go ahead and hire nerds with no manners and silly notions about entitlement and technology?

Reply on news.ycombinator.com