Do not use RJS-like techniques | Hacker News Reader

Do not use RJS-like techniques

homakov.blogspot.ru

43 pointshomakov28 comments

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

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.

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.

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.

String concatenation is usually way faster both at runtime and at code-time than the alternatives.

RJS is fast but not secure. Trade off?

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

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)

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.

You can serve JS code that is wrapped in an anonimous function itself.

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.

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.

yes this is another good reason to avoid it

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.

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.

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)

I think 'abstraction' is the wrong term anyway. It has become a go-to term for "make the ugly go away."

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?

it's still easy to do interactive apps! just learn JS and throw away RJS

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.

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.

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.

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

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

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.

RJS is not only Ruby-to-JS, it is evaling response.

I thought RJS died with the release of Rails 3.0

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

Reply on news.ycombinator.com