5 ms·

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,

by dhh 15y ago

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

arturadib 15y ago
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!
- dhh 15y ago
  Is that supposed to be a slam? I've been working on "custom" platforms for the better part of a decade.
  - arturadib 15y ago
    Hence why you're trying at all costs to make it work with things it wasn't designed for?
    - smokinn 15y ago
      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.
- deleted 15y ago
  [deleted]
- batista 15y ago
  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?
jashkenas 15y ago
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.
- dhh 15y ago
  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.
  - MattRogish 15y ago
    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 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
arijo 15y ago
Also, bashing javascript client-side frameworks makes great link bait.
- gambler 15y ago
  Who's bashing what? The author simply described some caching techniques and got a tsunami of hatred from JavaScript, ahem, fans in response.
ThomPete 15y ago
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.
Void_ 15y ago
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.)
- irahul 15y ago
  OP is measuring page render time on the server. Network latency is variable, and there isn't much one can do to fix it.
  - Void_ 15y ago
    What does the user care if the time is spent rendering, transmitting or baking cookies?
    - poutine 15y ago
      Whether the data is sent via HTML or JSON it will still incur the network latency.
    - irahul 15y ago
      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.
      - jcoffey 15y ago
        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).
mhartl 15y ago
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.
- iamgilesbowkett 15y ago
  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.

by dhh 15y ago

arturadib 15y ago

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!

dhh 15y ago
Is that supposed to be a slam? I've been working on "custom" platforms for the better part of a decade.
- arturadib 15y ago
  Hence why you're trying at all costs to make it work with things it wasn't designed for?
  - smokinn 15y ago
    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.
deleted 15y ago
[deleted]
batista 15y ago
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?

jashkenas 15y ago

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.

dhh 15y ago
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.
- MattRogish 15y ago
  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 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

arijo 15y ago

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

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

ThomPete 15y ago

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.

Void_ 15y ago

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

irahul 15y ago
OP is measuring page render time on the server. Network latency is variable, and there isn't much one can do to fix it.
- Void_ 15y ago
  What does the user care if the time is spent rendering, transmitting or baking cookies?
  - poutine 15y ago
    Whether the data is sent via HTML or JSON it will still incur the network latency.
  - irahul 15y ago
    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.
    - jcoffey 15y ago
      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).

mhartl 15y ago

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.

iamgilesbowkett 15y ago
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.