5 ms·

Do not use RJS-like techniques

43 points by homakov 14y ago

mwcampbell 14y ago
A generalization of this is to avoid string concatenation in favor of building up a proper internal representation of the data and then serializing it. See also: Data In, Garbage Out (http://glyph.twistedmatrix.com/2008/06/data-in-garbage-out.html http://glyph.twistedmatrix.com/2008/06/data-in-garbage-out.h...)
- deleted 14y ago
  [deleted]
- threedaymonk 14y ago
  That's a good post that I hadn't seen before. Thanks. It's a matter of continuing puzzlement to me that, despite the fact that more robust and better-abstracted methods of producing output exist, the dominant paradigm in web development is to concatenate strings together and hope. But it's worse than that: many people actively reject better methods on the basis that, as I've heard it expressed over and over, you "should" be able to just write HTML, ipse dixit. There's active resistance to improving this awful situation. I don't understand it. I wish I did.
  - rdw 14y ago
    String concatenation is usually way faster both at runtime and at code-time than the alternatives.
    - homakov 14y ago
      RJS is fast but not secure. Trade off?
  - dopamean 14y ago
    I am currently building a web app and I've found myself doing a lot of string concatenation. What are these more robust and better-abstracted methods? I would love to read up on them. Thanks.
    - nickzoic 14y ago
      Do you mean doing things (in jQuery) like: $('<div id="' + identifier + '">' + some_text + '</div>'); If so, consider doing: $('<div>').attr('id', identifier).text(some_text); which handles escaping correctly for you. Or equivalent in your preferred JS framework or lack of framework.
philipwalton 14y ago
One additional point the author didn't mention: Executing JavaScript code sent from the server requires your JS objects to be in the global scope. Returning JSON (on the other hand) allows you to keep your objects and logic inside a closure.
- v413 14y ago
  You can serve JS code that is wrapped in an anonimous function itself.
  - philipwalton 14y ago
    Yes, but that doesn't actually solve the problem. How is that code going to interact with your existing objects unless those objects are in the global scope? If both the requester of the AJAX call and the receiver are in the same closure, there's no need for those objects to be globally accessible.
    - homakov 14y ago
      yes this is another good reason to avoid it
    - v413 14y ago
      It is possible , e.g. if your javascript on the page is already using a common js module system, you can simply "require" the necessary modules. In addition, you can have a global pub/sub system in place (that you can "require" from you inlined script) and fire events. This will really help for decoupling. Usually you need inlined js along with the served html so that you attach behavior from within that inlined script. This is again easy to do from a "closured" piece of code.
vorg 14y ago
This problem just means a better implementation of RJS is required, or of any other technology that similarly tries to abstract away the client-server divide with a high-level concept.
- yuliyp 14y ago
  No. Abstracting away the client-server divide in web apps is a broken concept. The server runs in a trusted environment. You can trust the results of decisions it makes ("can the user write to this object?", "can the user see this object"). You can never trust the results of decisions client-side code makes, except insofar as they are a proxy of the intentions of the authenticated user on the other side of the interaction.
  - reeses 14y ago
    I think 'abstraction' is the wrong term anyway. It has become a go-to term for "make the ugly go away."
  - homakov 14y ago
    Well i got to disagree. If server responds "yes you can write to this object" client can represent form for writing but when he submits this form it depends on the server again. Client should not trust server as well. If server goes mad it still can be not compromising client-side (unless app was completely hacked and HTML was changed)
cpg 14y ago
Well, RJS was the more-or-less sanctioned way of doing interactive apps in Rails for a while. Even though it had all these issues, it was simpler for developers. Now it's deprecated. What are the best in class techniques for developers eager to do secure yet highly interactive apps in Rails today?
- homakov 14y ago
  it's still easy to do interactive apps! just learn JS and throw away RJS
  - cpg 14y ago
    This suggestion is rather naive and impractical. Most people do know JS. It's a rather painful way to develop reasonable UIs. Not even jQuery is abstracting enough these days (for this kind of work). Please make useful suggestions and cut down on specious remarks. RJS is not in use for a long time. This article did not even merit the first page, except it's a slow weekend.
    - homakov 14y ago
      your first question looked like "if not RJS then what". Now i just don't understand what are you talking about, what "interactive" is for you.
      - cpg 14y ago
        Oh, so if not raw JS, you don't "understand" what other possible libraries might be use to design modern usable intractive web apps? Way to go downvoting for that, too - shows real depth. I shall not try make you "understand" the existence of this fast-expanding space.
artellectual 14y ago
I actually developed a gem that solves this problem exactly, I am in the middle of cleaning it up and solidifying the api abit hopefully will release it soon, I will also be talking about it at red dot ruby conference
- homakov 14y ago
  it's easy to fix RJS leaking. You need to check CSRF token at every GET request
epochwolf 14y ago
I thought RJS died with the release of Rails 3.0
- homakov 14y ago
  the post is not only about RJS, about the whole concept of it
aantix 14y ago
Regarding #2, what is he talking about escaping? A simple call to the j helper (short for escape_javascript) and your render calls are properly escaped. Regarding #1; AJAX updates are incredibly easy (see the Railscast for review http://railscasts.com/episodes/136-jquery-ajax-revised?view=asciicast http://railscasts.com/episodes/136-jquery-ajax-revised?view=...). In fact, most of the Backbone BS that people are doing now days could be much more easily accomplished with a simple form_for (:remote => true) with a simple rjs response. This author appears to have lost the simplicity in it's approach. Review the Railscast and this video of DHH showing off the new Basecamp (http://www.youtube.com/watch?v=FkLVl3gpJP4 http://www.youtube.com/watch?v=FkLVl3gpJP4) and maybe you'll reconsider.
- homakov 14y ago
  2 let's start with the fact that rails escapes all html by default in normal views. In .js templates you have to do it manually 1 AJAX updates are easy, right. w/o RJS as well i don't describe my approach because my approach is different — i wrote a post about other websites' approach (RJS is used in the wild)
tomphoolery 14y ago
It's been deprecated for a long, long time. There's UJS and when you write your JavaScript you should be writing JavaScript, not Ruby. Silly rabbits.
- homakov 14y ago
  RJS is not only Ruby-to-JS, it is evaling response.

43 points by homakov 14y ago

A generalization of this is to avoid string concatenation in favor of building up a proper internal representation of the data and then serializing it. See also: Data In, Garbage Out (http://glyph.twistedmatrix.com/2008/06/data-in-garbage-out.html http://glyph.twistedmatrix.com/2008/06/data-in-garbage-out.h...)

deleted 14y ago
[deleted]
threedaymonk 14y ago
That's a good post that I hadn't seen before. Thanks. It's a matter of continuing puzzlement to me that, despite the fact that more robust and better-abstracted methods of producing output exist, the dominant paradigm in web development is to concatenate strings together and hope. But it's worse than that: many people actively reject better methods on the basis that, as I've heard it expressed over and over, you "should" be able to just write HTML, ipse dixit. There's active resistance to improving this awful situation. I don't understand it. I wish I did.
- rdw 14y ago
  String concatenation is usually way faster both at runtime and at code-time than the alternatives.
  - homakov 14y ago
    RJS is fast but not secure. Trade off?
- dopamean 14y ago
  I am currently building a web app and I've found myself doing a lot of string concatenation. What are these more robust and better-abstracted methods? I would love to read up on them. Thanks.
  - nickzoic 14y ago
    Do you mean doing things (in jQuery) like: $('<div id="' + identifier + '">' + some_text + '</div>'); If so, consider doing: $('<div>').attr('id', identifier).text(some_text); which handles escaping correctly for you. Or equivalent in your preferred JS framework or lack of framework.

philipwalton 14y ago

One additional point the author didn't mention: Executing JavaScript code sent from the server requires your JS objects to be in the global scope. Returning JSON (on the other hand) allows you to keep your objects and logic inside a closure.

v413 14y ago
You can serve JS code that is wrapped in an anonimous function itself.
- philipwalton 14y ago
  Yes, but that doesn't actually solve the problem. How is that code going to interact with your existing objects unless those objects are in the global scope? If both the requester of the AJAX call and the receiver are in the same closure, there's no need for those objects to be globally accessible.
  - homakov 14y ago
    yes this is another good reason to avoid it
  - v413 14y ago
    It is possible , e.g. if your javascript on the page is already using a common js module system, you can simply "require" the necessary modules. In addition, you can have a global pub/sub system in place (that you can "require" from you inlined script) and fire events. This will really help for decoupling. Usually you need inlined js along with the served html so that you attach behavior from within that inlined script. This is again easy to do from a "closured" piece of code.

vorg 14y ago

This problem just means a better implementation of RJS is required, or of any other technology that similarly tries to abstract away the client-server divide with a high-level concept.

yuliyp 14y ago
No. Abstracting away the client-server divide in web apps is a broken concept. The server runs in a trusted environment. You can trust the results of decisions it makes ("can the user write to this object?", "can the user see this object"). You can never trust the results of decisions client-side code makes, except insofar as they are a proxy of the intentions of the authenticated user on the other side of the interaction.
- reeses 14y ago
  I think 'abstraction' is the wrong term anyway. It has become a go-to term for "make the ugly go away."
- homakov 14y ago
  Well i got to disagree. If server responds "yes you can write to this object" client can represent form for writing but when he submits this form it depends on the server again. Client should not trust server as well. If server goes mad it still can be not compromising client-side (unless app was completely hacked and HTML was changed)

cpg 14y ago

Well, RJS was the more-or-less sanctioned way of doing interactive apps in Rails for a while. Even though it had all these issues, it was simpler for developers. Now it's deprecated. What are the best in class techniques for developers eager to do secure yet highly interactive apps in Rails today?

homakov 14y ago
it's still easy to do interactive apps! just learn JS and throw away RJS
- cpg 14y ago
  This suggestion is rather naive and impractical. Most people do know JS. It's a rather painful way to develop reasonable UIs. Not even jQuery is abstracting enough these days (for this kind of work). Please make useful suggestions and cut down on specious remarks. RJS is not in use for a long time. This article did not even merit the first page, except it's a slow weekend.
  - homakov 14y ago
    your first question looked like "if not RJS then what". Now i just don't understand what are you talking about, what "interactive" is for you.
    - cpg 14y ago
      Oh, so if not raw JS, you don't "understand" what other possible libraries might be use to design modern usable intractive web apps? Way to go downvoting for that, too - shows real depth. I shall not try make you "understand" the existence of this fast-expanding space.

artellectual 14y ago

I actually developed a gem that solves this problem exactly, I am in the middle of cleaning it up and solidifying the api abit hopefully will release it soon, I will also be talking about it at red dot ruby conference

homakov 14y ago
it's easy to fix RJS leaking. You need to check CSRF token at every GET request

epochwolf 14y ago

I thought RJS died with the release of Rails 3.0

homakov 14y ago
the post is not only about RJS, about the whole concept of it

aantix 14y ago

Regarding #2, what is he talking about escaping? A simple call to the j helper (short for escape_javascript) and your render calls are properly escaped. Regarding #1; AJAX updates are incredibly easy (see the Railscast for review http://railscasts.com/episodes/136-jquery-ajax-revised?view=asciicast http://railscasts.com/episodes/136-jquery-ajax-revised?view=...). In fact, most of the Backbone BS that people are doing now days could be much more easily accomplished with a simple form_for (:remote => true) with a simple rjs response. This author appears to have lost the simplicity in it's approach. Review the Railscast and this video of DHH showing off the new Basecamp (http://www.youtube.com/watch?v=FkLVl3gpJP4 http://www.youtube.com/watch?v=FkLVl3gpJP4) and maybe you'll reconsider.

homakov 14y ago
2 let's start with the fact that rails escapes all html by default in normal views. In .js templates you have to do it manually 1 AJAX updates are easy, right. w/o RJS as well i don't describe my approach because my approach is different — i wrote a post about other websites' approach (RJS is used in the wild)

tomphoolery 14y ago

It's been deprecated for a long, long time. There's UJS and when you write your JavaScript you should be writing JavaScript, not Ruby. Silly rabbits.

homakov 14y ago
RJS is not only Ruby-to-JS, it is evaling response.