

Do not use RJS-like techniques - homakov
http://homakov.blogspot.ru/2013/05/do-not-use-rjs-like-techniques.html

======
mwcampbell
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.h...](http://glyph.twistedmatrix.com/2008/06/data-in-garbage-
out.html))

~~~
threedaymonk
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.

~~~
dopamean
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
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.

------
aantix
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=...](http://railscasts.com/episodes/136-jquery-ajax-
revised?view=asciicast)). 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>) and maybe you'll reconsider.

~~~
homakov
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)

------
philipwalton
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
You can serve JS code that is wrapped in an anonimous function itself.

~~~
philipwalton
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.

~~~
v413
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
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
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.

~~~
homakov
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
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
it's still easy to do interactive apps! just learn JS and throw away RJS

~~~
cpg
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
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
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
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
it's easy to fix RJS leaking. You need to check CSRF token at every GET
request

------
tomphoolery
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
RJS is not only Ruby-to-JS, it is evaling response.

------
epochwolf
I thought RJS died with the release of Rails 3.0

~~~
homakov
the post is not only about RJS, about the whole concept of it

