I was wondering, is Ruby on Rails dependent on JavaScript?
A little background to this question: I created a link that would
remove an element from the database. Thus, this link has a :method
=> :delete appended to the end. When I look at the source this code
generates, there is a huge ugly paragraph of JavaScript. I loaded up
FireFox and disabled JavaScript and was unable to remove the element.
I was simply redirected to the show action.
If my members have JavaScript disabled, are there some elements of
Ruby on Rails that will simply not work? Thanks for your help!
I was wondering, is Ruby on Rails dependent on JavaScript?
No. You can write all kinds of websites without any JS. The only
drawback is
slight user hostility in various corners of the application. For
example, you
should pre-select your first edit field, like www.google.com’s home page
does.
Without JavaScript you can’t do that.
And you must avoid RoR constructions that spontaneously generate JS…
A little background to this question: I created a link that would
remove an element from the database. Thus, this link has a :method
=> :delete appended to the end.
Doesn’t that create a call to an HTTP DELETE verb? That can’t be what
you want,
because I suspect the basic intent is “delete this web page off your
server”.
When I look at the source this code
generates, there is a huge ugly paragraph of JavaScript.
Is that code what’s required to convert a normal link into a DELETE
link?
I loaded up
FireFox and disabled JavaScript and was unable to remove the element.
I was simply redirected to the show action.
Don’t use :method => :delete. A link that deletes should use :method =>
:post.
If you switch to that, do you get more JS?
If my members have JavaScript disabled, are there some elements of
Ruby on Rails that will simply not work? Thanks for your help!
An action that deletes should not call with the GET verb.
In terms of user hostility, if a simple link cannot call POST without
a blob
of JavaScript, then you will have to use the non-JS version, which is a
complete
and a submit button. This looks ugly, but it's still tractable.
Look at
GMail in HTML-only mode, for example.
Is that code what’s required to convert a normal link into a DELETE link?
There is no DELETE HTML link type. HTML really only understands GET
and PUT – forms are either, regular links are always GET. The JS
involved here generates an internal form, sets a field in it to
indicate that it is a POST but should (by RoR) be interpreted as a
DELETE HTTP verb, and submits it.
You could make each delete link be a form with a button an insert the
appropriate hidden fields. But now you have a button, and not a link.
Or you could abandon the RESTful mathods and use a GET request to
trigger a “do you really want to delete this record?” form, and have
that submit.
I tend to think this is a missing functionality in REST anyway – edit
→ create, but there’s nothing to confirm delete requests in HTML.
I guess my primary concern is that RoR seems to hold the opinion that
users will have JavaScript enabled. JavaScript is a big part of todays
Internet, though despite how popular it is, there are still a small
percentage of people who have it disabled. Should I keep these members
in mind when I program my application - or should I merely program for
the majority? What have you guys decided on behalf of your
applications?
Don’t use :method => :delete. A link that deletes should use :method => :post.
If you switch to that, do you get more JS?
Yes, if I change the method over to :post, it still generates the
JavaScript. Also, when I click the Delete link, I receive an error:
Only get, put, and delete requests are allowed. Thus, I’ve been given
two options: program my own forms and use a submit button, or program
with the Rails opinion that JS should be enabled.
Thanks again for your replies - they are very helpful.
Yes, if I change the method over to :post, it still generates the
JavaScript. Also, when I click the Delete link, I receive an error:
Only get, put, and delete requests are allowed. Thus, I’ve been given
two options: program my own forms and use a submit button, or program
with the Rails opinion that JS should be enabled.
Third option: Your behavior should gracefully degrade if JS is not
available.
Ultimately, you must pass this question to your client. Some brag they
want to
hit “every browser in the world”, forbearing JS, even if 99.9997% of all
browsers have it turned on.
Ask your client if you absolutely must work with non-JS browsers before
spending
extra time creating a 1995-style website.
I’m starting to feel that I’d rather only support JavaScript enabled
browsers. Every part of the site that doesn’t require a member to
login, should support non-JavaScript users, however, before a member
logs in, I could have a message, “In order to login and use this site,
please insure that JavaScript and cookies are enabled.” This way, I
can focus on the user experience and not have to worry about those
who, like you said, are stuck in 1995.
I’m an entrepreneur web designer. Thus, I’m programming this site for
my own company. Thanks for your posts, they were quite helpful.
I’m starting to feel that I’d rather only support JavaScript enabled
browsers. Every part of the site that doesn’t require a member to
login, should support non-JavaScript users, however, before a member
logs in, I could have a message, “In order to login and use this site,
please insure that JavaScript and cookies are enabled.” This way, I
can focus on the user experience and not have to worry about those
who, like you said, are stuck in 1995.
Whip out your Firefox. It has a menu item, fairly high up, to turn off
JavaScript.
Turn it off, and go surfing. See how far you get. Also, see if anyone
even bothers to tell you, “BTW, we f— up totally without JS turned on.”
Another aspect of the JS riddle - in the olden days, no two browsers
ever
performed the same JS function in exactly the same way. These days, they
often
do, and libraries like prototype.js fill many gaps. So modern websites
can rely
on JS much more safely…
When you scaffold a new Rails app, the scaffold generates a link_to for
the delete. The additional :method => :delete on the link_to causes JS
to be written to generate a form on the page so that the method gets
sent. It’s the only way to fake the delete method.
Nice tip, but I doubt the OP is RESTful, and totally doubt he actually
needs the
HTTP DELETE verb. This is the second time this week I have seen :action
=>
:delete, and I looked up to see if it was the same guy. It was not…
…but I am too spoiled: All our really wicked s at my day job go
to
in-house webpages, where we are allowed to smack anyone not using
Firefox >=1.5.
But please promise that when you make your money, you’ll come back and
make it work for non-JS devices too.
Under tests. They help you get version 1 out the door, and they help
preserve
version 1 while you add the features for version 2!
You can do everything in Rails RESTful and still support JS-disabled
browsers. I have pretty bad vision and I do a lot of work with
accessibility
for the disabled. Sites that require JS often make life difficult for
blind
users.
When you scaffold a new Rails app, the scaffold generates a link_to for
the
delete. The additional :method => :delete on the link_to causes JS to be
written to generate a form on the page so that the method gets sent.
It’s
the only way to fake the delete method.
The solution is simple, though not always obvious. In the old days of
Rails, you were told to use button_to intead of link_to for any
destructive
actions, so that spiders couldn’t inadvertantly monkey with your
database.
Button_to uses a post, and actually draws the form on the page. Use
button_to instead of link_to for the delete links in your Rails 2 apps
and bam it works without JS. Change the style of the button using CSS
Of course thinks like form_remote_for and link_to_remote are going to
fail
for you, but you don’t need to use those. So, no… Rails does not
require
Javascript. Javascript does make sites more user-friendly except for
screen-reader users.
If you’re building a commercial product and you’re trying to get to
launch
so you can actually make money, do it the best way you can so that you
can
make money. Then when you have money coming in, make sure it works
without
JS enabled. No sense in blowing your budget making two versions of your
site, or a scaled-down version that is universally accessible but
unappealing to the majority of potential paying customers.
But please promise that when you make your money, you’ll come back and
make
it work for non-JS devices too.
Turn it off, and go surfing. See how far you get. Also, see if anyone even bothers to tell you, “BTW, we f— up totally without JS turned on.”
I tried this and didn’t find too many things that didn’t work.
However, I didn’t play with actual applications, mainly viewed content
sites - blogs an such. Advertisements didn’t work, which is really bad
for me, as that’s how my website will generate revenue. Even though
users who have JavaScript turned off won’t make me any money, them
simply being on the site will likely bring others.
But please promise that when you make your money, you’ll come back and make
it work for non-JS devices too.
That’s something I’ll do my best to achieve. Like I said above,
building an application that everyone can use, is ideal. Where those
users won’t directly be making me money, they are likely to bring
friends.
Count yourself lucky Phlip!
Thanks for all your replies - they were quite insightful.
~Dustin T.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
