Marnen Laibow-Koser wrote:
> Mk 27 wrote:
>> And
>> please, do not hand me some basic case involving onload(), and claim "oh
>> no, it could never be more coding, look...". Certainly, it could never,
>> ever, logically be *less* coding.
>
> You are absolutely wrong. Since inline JS, by its very nature, is much
> harder to refactor, in many, many types of cases, inline JS will lead to
> significantly more code than unobtrusive external JS.
I think we are talking about slightly different things. I am not
talking about defining functions inline. I'm talking about calling
them:
<script type="text/javascript>call_my_function(here, forthis)</script>
You can claim whatever you want but you are not going to get rid of that
from the page by adding a single line to a .js file somewhere. Period.
The end.
> No. Just iterate over the affected DOM elements and apply an
> appropriate abstraction.
Sure, but that is not one line of code. You are trying to make a "rule
with no exceptions" and you are bound to failure because of that.
> You said you were snobbish about JS as compared to "real languages".
> Well, guess what -- JS is a "real" language, and quite a powerful one
> too,
This was a joke about snobbishness, and not really anything else. Sorry
I did not make that clear earlier...
> "real" language. That means writing complete routines in one place, not
> scattered bits of inline code. [...]
The routines are in one place, a .js file. The calls are, often enough,
made in an html file.
> while keeping JS out of the HTML. I guarantee that both
> your JS and your HTML will be the better for it.
Inlining CSS is truly pointless, but when I look at a page source and
see a mix of html, javascript, and embedded "whatever", I honestly do
not, never have, never will, have some sort of absurd formatting related
freak-out (like: "See how much tidier your html is now!!" Grow up).
You sound like someone who insists there is only one place to place an
opening {, when in fact there are a number of acceptable styles and that
is all they are: styles.
>> You are not
>> talking about any improvement in functionality or performance, after
>> all.
>
> Wrong again.
No, you are wrong again. If you want to tell me
<script type="text/javascript>call_my_function(here, forthis)</script>
represents some kind of performance issue (considering call_my_function
is already cached), I will tell you are wrong again, because you are.
>> I would hate to consider a case where an author decided *not* to do
>> something because it required inline js.
>
> Read my lips: *NOTHING* REQUIRES INLINE JS! Anything doable with inline
> JS can also be done without it.
Possibly, although you don't make much of a case to support that. But
just because something *can* be done one way or another doesn't mean it
*has* to be, unless you have a good reason for it, and since you still
have not come up with one, I am satisfied that it doesn't exist.
MK
--
Posted via http://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
