1. 12

  2. 4

    I like this approach. From my experience Backbone.js apps are difficult to maintain and test properly after a certain codebase scale (this could be said about javascript apps in general). Best practices from real apps are just starting to appear.

    I was all about JS-heavy frontends last year, but after using it in production, I didn’t find working with the apps as enjoyable as other ruby/clojure projects. In additon, the UX pros/cons (faster load speeds vs history states) is still debatable until all browsers are fully modernized.

    1. 3

      Can we lump rails stuff into the “ruby” tag? .. or maybe have a “rails” tag?

      EDIT: Oh thanks!

      1. 2

        The discussion at HN lead me to a great blog post by DHH about Basecamp Next. He talks about two approaches to making Rails applications feel faster by caching “to the extreme” and using pjax, or similar technologies, to only render partial html pages. The latter approach allows you to update a page without a full refresh, all while maintaining the rendering layer on the server.

        1. 1

          We’ve added ‘russian doll caching’ to Rails 4, so it’ll be really easy to copy his approach.

        2. 1

          I don’t understand how anyone can think 14 layers of caching is simple, or that “javascript is the wrong tool for rendering html”, when it is a) faster then ruby, b) not adding load to your server, c) dramatically reducing data on the wire, d) not breaking the back button, e) only updating what is necessary without managing 14 layers of caching e) provides a better user experience

          I think the problem is that the appropriate way to build highly dynamic interfaces on the web is to use the language of the web, javascript, but there is an extreme shortage of developers with the skills necessary in that language to build/maintain the kind of code required to build these interfaces.