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

51–60 of 135 posts

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

#51

Post by bdittmer »

latch wrote: post #19

I 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.

I think you nailed it with "unless those exact same actions are actually (YAGNI) used as endpoints of a web service". I find client side javascript apps compelling because they are simply another consumer of your web service along with any other mobile/third-party/customer apps.

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

#52

Post by arturadib »

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…

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!

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

#53

Post by brunoc »

MatthewPhillips wrote: post #39
ayanb wrote: post #23

Earlier quoted context omitted.

How does this impact if you are aiming to build a JSON API too?

Double work.

Not with Rails, afaik. Assuming the routes are consistent, you simply add a 'respond' for JSON and send the relevant chunk of the model. Easy as pie.

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

#55

Post by dhh »

arturadib wrote: post #52
dhh wrote: post #44

Earlier quoted context omitted.

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…

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.

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

#56

Post by arturadib »

dhh wrote: post #55
arturadib wrote: post #52

Earlier quoted context omitted.

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?

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

#57

Post by alinajaf »

boucher wrote: post #35
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…

Word. Seems like they are going out of their way to avoid doing client side work even when it would be far easier to do so. Also seems motivated by the desire to keep Rails relevant, but without actually trying to evolve Rails towards being more useful for client side driven apps. On the flip side, you have to congratulate them on what seems like really great results. I'm definitely in favor of doing what works and w…

> Also seems motivated by the desire to keep Rails relevant, but without actually trying to evolve Rails towards being more useful for client side driven apps.

IME, there isn't a smoother way to implement a bunch of RESTish json endpoints hooked up to a database (resources) and have dependency management and compilation for your frontend js/css (via the asset pipeline).

There may be other frameworks out there that make serving up and delivering client-side driven apps easy, but I haven't heard of them.

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

#58

Post by adeelk »

bdittmer wrote: post #51
latch wrote: post #19

I 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.

I think you nailed it with "unless those exact same actions are actually (YAGNI) used as endpoints of a web service". I find client side javascript apps compelling because they are simply another consumer of your web service along with any other mobile/third-party/customer apps.

It’s not just client-side apps where you can consume your own API. It’s completely possibly to do the consumption on the server side.

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

#59

Post by [deleted] »

arturadib wrote: post #52
dhh wrote: post #44

Earlier quoted context omitted.

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…

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!

[deleted]

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

#60

Post by Joeri »

jondot wrote: post #33
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…

With all of the backbone and node.js hype going around, people tend to forget that client-side development is developing on the client's side. Sooner than later you will have to deal with * nondeterministic testing, * interactive testing (leaving machines on to run interactive testing at night), * most of the bugs will live on the client side, * you'll have to support each and every machine's quirks (you can't preten…

You can still do unit testing of your client-side code if you wrap everything in components that separate state from rendering. The rendering itself you can only test with a human looking at the page anyway (or by comparing to reerence renderings). Extjs uses this approach. I can easily unit-test my forms written on top of extjs.

Fundamentally this is a bikeshedding debate. Whether you're programming on the client or server, the tools are equally capable. The big difference is the server puts you closer to the data, and the client pus you closer to the user. Either way you're struggling with latency, and you do different trade-offs, and either way you reach your goals.

Post reply on HN