8 ms·

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

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 principle, it can't possibly be close to as fast (client-side can render optimistically, where possible), and it can't be close to as flexible (you don't have a model of state on the client to perform logic with). I think that the truth of this is already admitted in that the really fancy bits of UI are being implemented in JS: http://37signals.com/svn/posts/3094-code-statistics-for-basecamp-next http://37signals.com/svn/posts/3094-code-statistics-for-base...

latch 15y ago
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 super dumb, but to me this approach is going to result in faster rendering.
- MatthewPhillips 15y ago
  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.
  - danmaz74 15y ago
    IIRC, innerHTML is actually faster than the DOM API, if you have to make the same changes...
  - andybak 15y ago
    Also remember that it's usually latency and connections that kills mobile performance. I've also found the actual data transfer to be fairly good compared to your average domestic DSL.
- VMG 15y ago
  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.
  - latch 15y ago
    Good point, thanks. So it potentially provides you with opportunities for further optimization. I guess the message from DHH is that they hit their performance targets, so this would be an unnecessary optimization (and I'm tempte to say "non-trivial to implement"..but now I know I'm being biased..)
  - hollerith 15y ago
    >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.
    - VMG 15y ago
      That is limiting the application though. With client-side rendering you can have large view changes with little state change.
- ColinCampbell 15y ago
  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 change has even been persisted back to the database. This is inherently faster. If you're able to invest in the infrastructure to allow you to do this on the server, and your use cases allow you to make that decision, then the trade-off is a little less black and white.
  - romaniv 15y ago
    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).
    - jashkenas 15y ago
      There are smart ways to render client-side UI, and there are not-so-smart ways. http://jsperf.com/dom-vs-innerhtml-based-templating/350 http://jsperf.com/dom-vs-innerhtml-based-templating/350 If you want to use a decent library, you can rest assured that your client-side templates will render far faster than the Ruby version of the same HTML.
      - stock_toaster 15y ago
        Even considering I do not have an 8 core machine with 32 GB of ram sitting on my lap (or in my pocket)? I realize that ruby is significantly slower than v8/JägerMonkey/Tracemonkey/etc, but is it so easy to discount the significant disparity between the average compute power of a server vs mobile/laptop? I think a stronger counter argument would be flexibility, smaller http responses (and thus less latency), and possibly an argument that it is simpler or more straightfoward, in favor of client-side javascript templating/rendering, but rendering speed? Not so sure.
- Joeri 15y ago
  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.
boucher 15y ago
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 what you're comfortable with. I just don't think Basecamp Next Next will be written this way.
- alinajaf 15y ago
  > 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.
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]
nathansobo 15y ago
Agreed. I prefer writing UI code on the client. But you need quality abstractions because it is more complex than doing everything on the server where all your data is at arm's length. I've written two frameworks that make it easier... SpacePen for the view (https://github.com/nathansobo/space-pen https://github.com/nathansobo/space-pen) and Monarch for the model: (https://github.com/nathansobo/monarch-rewrite https://github.com/nathansobo/monarch-rewrite)
romaniv 15y ago
is there still an argument that can be made in favor of doing your UI on the server side? Ability to link to documents, bookmark, meaningfully use history and save pages to the disk for offline use. Ability of the users to customize standard behaviors without reverse-engineering your JavaScript code. Transparency, which often leads to much, much easier debugging and improved usability. No need to run a quad-core 4GB desktop to use the website. And this is just the stuff relevant to internal (non-public) websites. You can argue that all of this can be achieved with JavaScript heavy clients, but in reality, it's just isn't. It's not something you get by default, it's tons of extra work, and most people don't do that work. Even just in principle, it can't possibly be close to as fast (client-side can render optimistically, where possible), and it can't be close to as flexible (you don't have a model of state on the client to perform logic with). In principle, server-side rendering can allow you to share pre-rendered components between thousands of users saving everyone tons of work. In practice, rendering on the server side is just string concatenation and is insignificant compared to things like running SQL quires, which you'll have to do anyway.
- sourcefrog 15y ago
  > Ability to link to documents, bookmark, meaningfully use history and save pages to the disk for offline use. Ability of the users to customize standard behaviors without reverse-engineering your JavaScript code. Transparency, which often leads to much, much easier debugging and improved usability. No need to run a quad-core 4GB desktop to use the website. You can manipulate the page url/browser history from js, and you can use the url to set the application state. History and bookmarks work perfectly well in gmail, for example. This does take explicit coding. But, if fragments of the page are being replaced as bcx does, then you need to do similar coding anyhow. Otherwise, you're doing whole page loads on every request. js works pretty well on modest smartphones, at which level network latency is usually the major concern...
  - romaniv 15y ago
    This does take explicit coding. But, if fragments of the page are being replaced as bcx does, then you need to do similar coding anyhow. It should not be similar. There is a huge architectural difference between the two approaches. In server-side approach you're adding caching or prefetch to an already working application that has established and working URLs. With client-side approach, you need to implement adapters that transform URL information into the client state that is normally achieved by a series of UI operations and AJAX calls. Then you need to add new code to generate URLs and manipulate history. The beauty of caching or partial page fetches is that they are generic. History manipulation is not. js works pretty well on modest smartphones, at which level network latency is usually the major concern... The last time I tried to browse on Kindle, it choked and died on most JS heavy websites. When 500MHz processor is not fast enough to browse the web, to me, that's a problem.
dgregd 15y ago
"but does it feel like a sustainable approach going forward" Maybe you are right. However it it too early to do a big rewrite in JS. There are many JS frameworks but no clear leader. I am sure that in 3 years decision how to design you client side web app will be much easier.
asaeidi 15y ago
Also what about deployments/bug fixes? Seems if you need to make changes to the html fragments you'd have to do a full app deploys every time. Versus making changes to specific JS file and uploading it. Personally that's why i like this whole shift to single page apps. Just as we've decoupled certain aspects of the server-side development, we can do the same with the UI.
batista 15y ago
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? Sure. 1) Client side UI frameworks are still immature. For example Backbone is minimal, while Ember is more featured but with bad documentation and not proven yet. Big frameworks with UI widgets never caught on and are too restrictive. GWT is also on the down and out, etc... 2) Same goes for the tools you need for debugging, unit testing, automation, etc. Nowhere as complete as the server side tools that have been honed for 10+ years. 3) Client experience can be extremely different, when JS performance differs widely between Firefox, Chrome, Safari and IE versions. Not to mention not everybody supporting the history state API. 4) JS performance for long running pages can also vary, due to memory management. and it can't be close to as flexible (you don't have a model of state on the client to perform logic with) And on the client you don't have a model of the server (where the actual data are and where the actual actions are performed) to perform logic with.

latch 15y ago

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 super dumb, but to me this approach is going to result in faster rendering.

MatthewPhillips 15y ago
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.
- danmaz74 15y ago
  IIRC, innerHTML is actually faster than the DOM API, if you have to make the same changes...
- andybak 15y ago
  Also remember that it's usually latency and connections that kills mobile performance. I've also found the actual data transfer to be fairly good compared to your average domestic DSL.
VMG 15y ago
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.
- latch 15y ago
  Good point, thanks. So it potentially provides you with opportunities for further optimization. I guess the message from DHH is that they hit their performance targets, so this would be an unnecessary optimization (and I'm tempte to say "non-trivial to implement"..but now I know I'm being biased..)
- hollerith 15y ago
  >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.
  - VMG 15y ago
    That is limiting the application though. With client-side rendering you can have large view changes with little state change.
ColinCampbell 15y ago
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 change has even been persisted back to the database. This is inherently faster. If you're able to invest in the infrastructure to allow you to do this on the server, and your use cases allow you to make that decision, then the trade-off is a little less black and white.
- romaniv 15y ago
  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).
  - jashkenas 15y ago
    There are smart ways to render client-side UI, and there are not-so-smart ways. http://jsperf.com/dom-vs-innerhtml-based-templating/350 http://jsperf.com/dom-vs-innerhtml-based-templating/350 If you want to use a decent library, you can rest assured that your client-side templates will render far faster than the Ruby version of the same HTML.
    - stock_toaster 15y ago
      Even considering I do not have an 8 core machine with 32 GB of ram sitting on my lap (or in my pocket)? I realize that ruby is significantly slower than v8/JägerMonkey/Tracemonkey/etc, but is it so easy to discount the significant disparity between the average compute power of a server vs mobile/laptop? I think a stronger counter argument would be flexibility, smaller http responses (and thus less latency), and possibly an argument that it is simpler or more straightfoward, in favor of client-side javascript templating/rendering, but rendering speed? Not so sure.
Joeri 15y ago
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.

boucher 15y ago

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 what you're comfortable with. I just don't think Basecamp Next Next will be written this way.

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

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]

nathansobo 15y ago

Agreed. I prefer writing UI code on the client. But you need quality abstractions because it is more complex than doing everything on the server where all your data is at arm's length. I've written two frameworks that make it easier... SpacePen for the view (https://github.com/nathansobo/space-pen https://github.com/nathansobo/space-pen) and Monarch for the model: (https://github.com/nathansobo/monarch-rewrite https://github.com/nathansobo/monarch-rewrite)

romaniv 15y ago

is there still an argument that can be made in favor of doing your UI on the server side? Ability to link to documents, bookmark, meaningfully use history and save pages to the disk for offline use. Ability of the users to customize standard behaviors without reverse-engineering your JavaScript code. Transparency, which often leads to much, much easier debugging and improved usability. No need to run a quad-core 4GB desktop to use the website. And this is just the stuff relevant to internal (non-public) websites. You can argue that all of this can be achieved with JavaScript heavy clients, but in reality, it's just isn't. It's not something you get by default, it's tons of extra work, and most people don't do that work. Even just in principle, it can't possibly be close to as fast (client-side can render optimistically, where possible), and it can't be close to as flexible (you don't have a model of state on the client to perform logic with). In principle, server-side rendering can allow you to share pre-rendered components between thousands of users saving everyone tons of work. In practice, rendering on the server side is just string concatenation and is insignificant compared to things like running SQL quires, which you'll have to do anyway.

sourcefrog 15y ago
> Ability to link to documents, bookmark, meaningfully use history and save pages to the disk for offline use. Ability of the users to customize standard behaviors without reverse-engineering your JavaScript code. Transparency, which often leads to much, much easier debugging and improved usability. No need to run a quad-core 4GB desktop to use the website. You can manipulate the page url/browser history from js, and you can use the url to set the application state. History and bookmarks work perfectly well in gmail, for example. This does take explicit coding. But, if fragments of the page are being replaced as bcx does, then you need to do similar coding anyhow. Otherwise, you're doing whole page loads on every request. js works pretty well on modest smartphones, at which level network latency is usually the major concern...
- romaniv 15y ago
  This does take explicit coding. But, if fragments of the page are being replaced as bcx does, then you need to do similar coding anyhow. It should not be similar. There is a huge architectural difference between the two approaches. In server-side approach you're adding caching or prefetch to an already working application that has established and working URLs. With client-side approach, you need to implement adapters that transform URL information into the client state that is normally achieved by a series of UI operations and AJAX calls. Then you need to add new code to generate URLs and manipulate history. The beauty of caching or partial page fetches is that they are generic. History manipulation is not. js works pretty well on modest smartphones, at which level network latency is usually the major concern... The last time I tried to browse on Kindle, it choked and died on most JS heavy websites. When 500MHz processor is not fast enough to browse the web, to me, that's a problem.

dgregd 15y ago

"but does it feel like a sustainable approach going forward" Maybe you are right. However it it too early to do a big rewrite in JS. There are many JS frameworks but no clear leader. I am sure that in 3 years decision how to design you client side web app will be much easier.

asaeidi 15y ago

Also what about deployments/bug fixes? Seems if you need to make changes to the html fragments you'd have to do a full app deploys every time. Versus making changes to specific JS file and uploading it. Personally that's why i like this whole shift to single page apps. Just as we've decoupled certain aspects of the server-side development, we can do the same with the UI.

batista 15y ago

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? Sure. 1) Client side UI frameworks are still immature. For example Backbone is minimal, while Ember is more featured but with bad documentation and not proven yet. Big frameworks with UI widgets never caught on and are too restrictive. GWT is also on the down and out, etc... 2) Same goes for the tools you need for debugging, unit testing, automation, etc. Nowhere as complete as the server side tools that have been honed for 10+ years. 3) Client experience can be extremely different, when JS performance differs widely between Firefox, Chrome, Safari and IE versions. Not to mention not everybody supporting the history state API. 4) JS performance for long running pages can also vary, due to memory management. and it can't be close to as flexible (you don't have a model of state on the client to perform logic with) And on the client you don't have a model of the server (where the actual data are and where the actual actions are performed) to perform logic with.