rails.js etc.

Hi,

Just a comment.

I just had a brief look at rails.js (latest Rails 3 master) and immediately noticed some really ugly errors like an accidental global variable (no "var" statement for it) and re-declaration of variables (more than one "var" statement for the same variable in the same function), not to mention several forrgotten line-ending semi-colons. Sure, it _works_, but would it be too much to ask to put such "official" framework JS files, which thousands of people end up using, through something like jslint(.com) for at least some basic syntax checks?

Also, is there a higher-level description of the intentions behind the JS infrastructure? I've been a little reluctant to start working on it from just the sources. Okay, it really isn't very complicated, but addinng/chaning something is easier when one knows the intentions of those who designed that stuff :slight_smile: For example, I don't know immediately know what's there to support legacy code, nor what features are supposed to be implemented by the "modern" JS infrastructure. To me "modern" means all JS code is in .js files, and data between server and browser is transferred using JSON(P) or XML, but no inline-eval of JS code received through an XHR request (evil!) nor of HTML. It's not obvious if my idea is the same as that of the Rails development team, or if they/you take a more pragmatical view(?) and also want to support those last two things as part of the "modern" Rails 3 JS infrastructure, and not just for legacy support.

Anyway, in general I haven't heard/read much about the JS stuff in Rails 3 after some initial general announcements, while one can read so much more about the Rails 3 mailer, router, activemodel, query builder - the "core" Rails stuff. The JS infrastructure does not seem to get all that much attention(???).

Thanks.

PS: I would like to add YUI3 support (meaning "I'd like to DO it", and not "I'd like to ask for it"). I would not bother with supporting the inline legacy JS code and helpers though.

and what stoping u, to use yui?

Ivan Nastyukhin dieinzige@me.com

That was not my question.

Michael,

I'd say there's a good chance that if you ran rails.js through jslint.com and made the appropriate changes that they'd be accepted.

I believe the UJS helpers were written in quite a short time period by a crack team in January, and I doubt anyone would complain if you were to come in and clean things up a bit.

—P

Michael, please take a look at ECMAScript specification, section 7.9 - "Automatic Semicolon Insertion":

This is not an error but a feature. The only case where this could lead to some problem is code like this:

var l = variable.length (function(){alert('a')})()

In this case, if we miss the semicolon, this would be interpreted as:

var l = variable.length(function(){alert('a')})()

You get the point. But this is only to mention that it is ok to not put the semicolons at the end of the line. I barely put them when writing Javascript...

About repeated variable names, I didn't find any case. Could you point me one? Remember that you can define the same variable multiple times in different scopes, such as functions. This is no problem.

But I'll take the chance to discuss another issue I've just opened yesterday on Github:

http://github.com/rails/jquery-ujs/issues#issue/11

It would be great if the jQuery driver supported including the CSRF token in all AJAX post calls, such as "$.load(url, {data: sample})".

What do you think?

Rodrigo.

Hi,

Just a comment.

I just had a brief look at rails.js (latest Rails 3 master) and immediately noticed some really ugly errors like an accidental global variable (no "var" statement for it) and re-declaration of variables (more than one "var" statement for the same variable in the same function), not to mention several forrgotten line-ending semi-colons. Sure, it _works_, but would it be too much to ask to put such "official" framework JS files, which thousands of people end up using, through something like jslint(.com) for at least some basic syntax checks?

Look forward to your patch, if it's not too much to ask :wink:

Also, is there a higher-level description of the intentions behind the JS infrastructure? I've been a little reluctant to start working on it from just the sources. Okay, it really isn't very complicated, but addinng/chaning something is easier when one knows the intentions of those who designed that stuff :slight_smile: For example, I don't know immediately know what's there to support legacy code, nor what features are supposed to be implemented by the "modern" JS infrastructure. To me "modern" means all JS code is in .js files, and data between server and browser is transferred using JSON(P) or XML, but no inline-eval of JS code received through an XHR request (evil!) nor of HTML. It's not obvious if my idea is the same as that of the Rails development team, or if they/you take a more pragmatical view(?) and also want to support those last two things as part of the "modern" Rails 3 JS infrastructure, and not just for legacy support.

The JS support there is hooks for the Rails form helpers, so check those out for guidance. There's no broad philosophical statement in them; it's just UJS hooks for some common behavior we like to add to forms, buttons, etc.

Anyway, in general I haven't heard/read much about the JS stuff in Rails 3 after some initial general announcements, while one can read so much more about the Rails 3 mailer, router, activemodel, query builder - the "core" Rails stuff. The JS infrastructure does not seem to get all that much attention(???).

Read up, dig in, and write it up! We could really use a Rails Guide on the topic.

Thanks.

PS: I would like to add YUI3 support (meaning "I'd like to DO it", and not "I'd like to ask for it"). I would not bother with supporting the inline legacy JS code and helpers though.

Cheers, jeremy

Hi,

Yes, automatic semi. insertion is a feature - and a most horrible one!

I am unwilling to discuss it though: I must admit I completely and uncritically submit to "higher authority" and Javascript-god Douglas Crockford as far as code writing rules are concerned, since as far as I'm concerned that guys simply is GOOD, or at least so much better than ANY other voices I have heard so far (where Javascript is concerned). I *highly* recommend the Crockford-videos on Yahoo's developer theater for anyone writing Javascript. Okay, "uncritically" is not quite right, to me his statements simply make sense. The only exception I occasionally take is usage of the ++/-- operators, although I limit myself to using them in the head of for-loops only. When listening to Crockford one must not forget of course that his advice is especially targeted at developers of mashup-able enterprise large(r)-scale JS apps where *teams* rather than individuals have to work with the code for a long time again and again, and not so much for handfuls-of-lines-of-code for "beautifying" HTML pages. However, since Rails is a framework IMHO those high and very strict coding standards should apply to its JS code.

Yes, I'm willing to contribute and not just complain and I'll try to do so - time permitting, which right now is a little scarce (I'm a week behind schedule in a JS project and also just opened a restaurant in Nuremberg, Germany, with an Italian cook/friend :slight_smile: ).

About redeclared variables: 1) see function handleMethod, variable field. 2) Further down in event handler document.on("submit",...) variable "element" is declared twice.

Crockford gives a compelling case for putting all var-statements into the TOP of the function instead of declaring them as they are used. I forgot was the argument was, but it was very compelling. Crockford is strong both in theory (computer science: programming languages) as well as in practice. I may sound odd to freely admit I forgot the argument and not to care, but I don't care - if you listen to the Crockford videos you'll understand :slight_smile: Seriously, I'm not nearly as good as this guy and since his videos are publicly available why should I try to repeat his statements, which is all I can do?

Thanks for the github pointers to the prototype and jquery components, I wasn't aware of them but only of the code bundled with rails directly. Contributing to the Guides is on my TODO list... I wasn't so much calling for other people's action but was/am much more interested in finding background info - such as those github links. One usually assumes much more intention than there is when one doesn't know all the things that are NOT going on :wink:

Michael

Hi Michael, I'm so sorry for the confusion that I made! :slight_smile:

I don't know why, but I thought you were talking about the jQuery rails.js driver. I've just seen you are talking about the default Prototype driver when you talked about the handleMethod function, which I didn't find in the jQuery driver:

http://github.com/rails/jquery-ujs/blob/master/src/rails.js

But now, I think you're probably right on the repeated declarations.

Regarding Crockford code writing rules, I've heard about him but have never been interested on reading his tips at all... I don't like the idea of following some rules without understanding the reasoning. Since I never had problem in organizing my js, I didn't find the need for looking for some guides on this topic.

For example, once you know the caveats of not using the semi-colons, I don't see any problems in using that feature. Actually, I dislike using semi-colons since the code is cleaner for my taste when not using semi-colons, unless you have multiple statements in the same line. Yes this can make sense, for instance:

var r=; for (var i in ary) r.push(ary[i]*2)

I also don't like the idea of using some tool for formatting code. For instance, the above code would be indented in Netbeans, probably as:

var r=; for (var i in ary) {      r.push(ary[i]*2); }

Some people may argument that this is much cleaner/better than it was. I don't think so. Why? Because I think that some simple idea should read as a single statement. 4 lines for doing that little job is too much for me. The problem is that some scripts may have thousands of lines. If you waste space like the code above, it becomes difficult to read other's code and get the idea without having to scroll lots of pages to finish reading some function, for instance.

Another common code writing mistake I see on people's code:

function x() {      if (! exception_condition) {             // several lines of code      } }

This is much better written as:

function x() {      if (exception_condition) return;      // same lines of code without unnecessary nested statements }

This is much better because you don't need to be worried about what happens if exception_condition occurs. And deep nesting is always more difficult to read.

About defining all variables at the beggining of some function is not a great thing at my opinion. It is much better to have a fluid source code where you are only concerned about some variable when you are reading the related code. Also, I always avoid declaring variables unnecessarily. That is because there is no standard way for giving it a scope. For instance, when you are reading code like this:

function x() {    var x = ... // something meaninful    // we are using the value of x here    // ...    // here follow several other lines where x is no more relevant    // how can the reader know that? He will be worried what else can be affected if he refactors the above x related code. }

There are several situations where variable declarations are unnecessary. For instance, using jQuery:

var el = $('<div/>') var body = $('body') body.append(el)

This could be written using no variable as:

$('<div/>').appendTo('body')

Or even as:

$('<div/>').text('content').appendTo('body').click(function(){alert('clicked: ' + $(this).text())})

or

$('<div>content</div>').click(function(){alert('clicked: ' + $(this).text())}).appendTo('body')

I usually use this approach whenever possible. I think it is much clear for other developers trying to understand what the code does. When there is some declared variable, you have no idea when and what it will be used for.

Also, I don't like to see 80 characters only page delimiter because most screens nowaday are wide and have small height. This mean we should avoid several lines of code in favor of lengthy lines. What I mean is that there was some reasoning for using 80 characters delimiter in the past that is no more valid nowadays. It is much better to get as much code as possible without the need of scrolling, unless the code readability is affected, which I don't think is the case in the above examples.

I don't see any problems either with the ++ and -- operators, but of course someone should understand how they work. And Javascript should be tested as well, the language is not an exception. There are good frameworks for that, as Selenium, for instance. So, why avoid the great features of the language? These operators works exactly the same way as C, C++ and Java...

But I hardly use them anyway. They are most used in for loops. I barely use constructions like "for (var i=0;i<10;i++)". When working with jQuery, I usually use something like $.each() and if I am using pure Javascript, usually a for loop is used in some context where the syntax "for (var el in elements)" is more suited.

Well, actually I was wondering writing some post about this topic on my site, but ended up never writing about it. Maybe, now that I have already written part of the content in this email, I can put this on my site :slight_smile: I always wanted to write about this for some years now whenever I have to read other's code in my company :slight_smile:

Here I have only given JS examples, but there are other subjects in other languages as well I would like to cover...

Sorry for the post-in-email-shape :slight_smile: Too long for an e-mail, probably, but please don't blame me. You have inspired me with this subject :wink:

Thanks for reading until here, :slight_smile:

Regards,

Rodrigo.

Michael,

I recently read Crockford's book "The Good Parts" and I absolutely share your opinions about bowing down to the master! That said, I think that his arguments simply make a lot of sense more than anything else, and it's useful to have a prescribed style at least to _start_ with, rather than picking and choosing at will.

Roderigo,

I've been hacking a bunch of javascript lately, and thought I'd reply to some of your admirably empassioned comments!

Regarding Crockford code writing rules, I've heard about him but have never been interested on reading his tips at all... I don't like the idea of following some rules without understanding the reasoning. Since I never had problem in organizing my js, I didn't find the need for looking for some guides on this topic.

Crockford's rules are backed by pretty strong logic. I'd recommend reading "The Good Parts" ... he has some compelling arguments.

My personal opinion on organization of js that we should have some consistency. Unlike Rails, where I always feel I know where to put my code, with js it often feels like I'm guessing.

For example, once you know the caveats of not using the semi-colons, I don't see any problems in using that feature. Actually, I dislike using semi-colons since the code is cleaner for my taste when not using semi-colons, unless you have multiple statements in the same line. Yes this can make sense, for instance:

One of the arguments for consistent semi-coloning is that in some cases, non properly ended statements will break js minifier tools. Given the huge surge in gzipping and minifying JS for performance, and the hassle of trying to find the missing semi-colon, I've tended toward including the little shits.

var r=; for (var i in ary) r.push(ary[i]*2)

I also don't like the idea of using some tool for formatting code. For instance, the above code would be indented in Netbeans, probably as:

I think Michael was referring to JSLint (http://jslint.com/) ... it's not a formatting tool, it's a _correctness_ tool, based on c++ lint, from back in the day.

var r=; for (var i in ary) { r.push(ary[i]*2); }

Some people may argument that this is much cleaner/better than it was. I don't think so. Why? Because I think that some simple idea should read as a single statement. 4 lines for doing that little job is too much for me. The problem is that some scripts may have thousands of lines. If you waste space like the code above, it becomes difficult to read other's code and get the idea without having to scroll lots of pages to finish reading some function, for instance.

I would argue that if you want to read this as a single statement, you should abstract it into a function. For me, the overhead of parsing out the single statement far exceeds the convenience of having it on a single line.

Another common code writing mistake I see on people's code:

function x() { if (! exception_condition) { // several lines of code } }

This is much better written as:

function x() { if (exception_condition) return; // same lines of code without unnecessary nested statements }

Nice tip.

About defining all variables at the beggining of some function is not a great thing at my opinion. It is much better to have a fluid source code where you are only concerned about some variable when you are reading the related code. Also, I always avoid declaring variables unnecessarily. That is because there is no standard way for giving it a scope. For instance, when you are reading code like this:

function x() { var x = ... // something meaninful // we are using the value of x here // ... // here follow several other lines where x is no more relevant // how can the reader know that? He will be worried what else can be affected if he refactors the above x related code. }

I see assigning variables up top as something similar in concept to attr_accessor in Ruby. ... I think if you keep functions short, than the issue of relevance shouldn't really creep in.

There are several situations where variable declarations are unnecessary. For instance, using jQuery:

var el = $('<div/>') var body = $('body') body.append(el)

This could be written using no variable as:

$('<div/>').appendTo('body')

I think this is just an example of a smart refactoring.

Or even as:

$('<div/>').text('content').appendTo('body').click(function(){alert('clicked: ' + $(this).text())})

or

$('<div>content</div>').click(function(){alert('clicked: ' + $(this).text())}).appendTo('body')

I usually use this approach whenever possible. I think it is much clear for other developers trying to understand what the code does. When there is some declared variable, you have no idea when and what it will be used for.

Also, I don't like to see 80 characters only page delimiter because most screens nowaday are wide and have small height. This mean we should avoid several lines of code in favor of lengthy lines. What I mean is that there was some reasoning for using 80 characters delimiter in the past that is no more valid nowadays. It is much better to get as much code as possible without the need of scrolling, unless the code readability is affected, which I don't think is the case in the above examples.

Here is where I disagree with you most. I don't think the 80 character limit has anything to do with screen resolution.

Maybe it's because I don't really mind scrolling, but I'd much rather scroll down than across, and I'd much rather read a number of short statements down, than a long statement sideways.

I'm a huge fan of the jQuery style of chaining functions on new lines:

$('<div/>').text('content')               .appendTo('body')               .click(...)

I don't see any problems either with the ++ and -- operators, but of course someone should understand how they work. And Javascript should be tested as well, the language is not an exception. There are good frameworks for that, as Selenium, for instance. So, why avoid the great features of the language? These operators works exactly the same way as C, C++ and Java...

Javascript has some great unit testing frameworks too.

Well, actually I was wondering writing some post about this topic on my site, but ended up never writing about it. Maybe, now that I have already written part of the content in this email, I can put this on my site :slight_smile: I always wanted to write about this for some years now whenever I have to read other's code in my company :slight_smile:

Here I have only given JS examples, but there are other subjects in other languages as well I would like to cover...

Sorry for the post-in-email-shape :slight_smile: Too long for an e-mail, probably, but please don't blame me. You have inspired me with this subject :wink:

Very cool discussion to be having.

—P

Michael,

I recently read Crockford's book "The Good Parts" and I absolutely share your opinions about bowing down to the master! That said, I think that his arguments simply make a lot of sense more than anything else, and it's useful to have a prescribed style at least to _start_ with, rather than picking and choosing at will.

Roderigo,

I've been hacking a bunch of javascript lately, and thought I'd reply to some of your admirably empassioned comments!

Regarding Crockford code writing rules, I've heard about him but have never been interested on reading his tips at all... I don't like the idea of following some rules without understanding the reasoning. Since I never had problem in organizing my js, I didn't find the need for looking for some guides on this topic.      

Crockford's rules are backed by pretty strong logic. I'd recommend reading "The Good Parts" ... he has some compelling arguments.     I'll take a look when I have some free time.

My personal opinion on organization of js that we should have some consistency. Unlike Rails, where I always feel I know where to put my code, with js it often feels like I'm guessing.

For example, once you know the caveats of not using the semi-colons, I don't see any problems in using that feature. Actually, I dislike using semi-colons since the code is cleaner for my taste when not using semi-colons, unless you have multiple statements in the same line. Yes this can make sense, for instance:      

One of the arguments for consistent semi-coloning is that in some cases, non properly ended statements will break js minifier tools. Given the huge surge in gzipping and minifying JS for performance, and the hassle of trying to find the missing semi-colon, I've tended toward including the little shits.     As I said, once you know the reasoning you can follow his suggestions. It just happens that we don't use minifiers at our company since Javascript is cacheable and there is no such "one-time users" thing with our products. The overhead is also negligible for not using any JS minifier. I mean, even if the JS code is reduced to 1/3 that would mean just some hundred of KB that won't make any difference in our clients and the content is cached after the first access. The client load is not that big to justify server Internet band economy.

Anyway, you are always free to choose which minifier method to apply to you code, so you can use a more conservative approach rather than an aggressive one. Code readability is much more important in my opinion than worrying about minifier tools, but each case needs particular considerations. I also don't mind seeing the semicolons in the code, but just don't bother to put them on code I write myself.

var r=; for (var i in ary) r.push(ary[i]*2)

I also don't like the idea of using some tool for formatting code. For instance, the above code would be indented in Netbeans, probably as:      

I think Michael was referring to JSLint (http://jslint.com/) ... it's not a formatting tool, it's a _correctness_ tool, based on c++ lint, from back in the day.     Yes, I know, I wasn't refering to JSLint when I wrote the above statement. I just took the chance to comment on this subject too. I was also a C++ developer a long time ago :slight_smile:

var r=; for (var i in ary) {     r.push(ary[i]*2); }

Some people may argument that this is much cleaner/better than it was. I don't think so. Why? Because I think that some simple idea should read as a single statement. 4 lines for doing that little job is too much for me. The problem is that some scripts may have thousands of lines. If you waste space like the code above, it becomes difficult to read other's code and get the idea without having to scroll lots of pages to finish reading some function, for instance.      

I would argue that if you want to read this as a single statement, you should abstract it into a function. For me, the overhead of parsing out the single statement far exceeds the convenience of having it on a single line.     Yes, this is really a matter of taste. It is trivial to me to parse this single statement, just like reading an english sentence and I actually need more time for parsing multiple lines. So this is no overhead to me. But, unfortunately, we developers have different tastes for source formatting :slight_smile: This is a simple matter of coding style.

Another common code writing mistake I see on people's code:

function x() {     if (! exception_condition) {            // several lines of code     } }

This is much better written as:

function x() {     if (exception_condition) return;     // same lines of code without unnecessary nested statements }      

Nice tip.

About defining all variables at the beggining of some function is not a great thing at my opinion. It is much better to have a fluid source code where you are only concerned about some variable when you are reading the related code. Also, I always avoid declaring variables unnecessarily. That is because there is no standard way for giving it a scope. For instance, when you are reading code like this:

function x() {   var x = ... // something meaninful   // we are using the value of x here   // ...   // here follow several other lines where x is no more relevant   // how can the reader know that? He will be worried what else can be affected if he refactors the above x related code. }

I see assigning variables up top as something similar in concept to attr_accessor in Ruby. ... I think if you keep functions short, than the issue of relevance shouldn't really creep in.     The biggest problem of Javascript in my opinion is the lack of a "require" statement. In Ruby, we usually write one or a few small classes per file and they don't get big. Code is well organized in different files. So, defining the attributes in the top is a good practice. In Javascript, we can have thousand lines of code in a single file unless we use some methods provided by some Javascript frameworks for managing Javascript dependencies with multiple files in a consistent way. jQuery still don't have such a feature and I don't like the idea of mixing different JS frameworks, so I avoid this approach for now...

Being object oriented, we barely see big methods in Ruby. They are usually split in various small methods. This is more difficult to achieve in Javascript without compromising code readability. Thus, functions tend to get big and declaring the variables in the top of each function can make it more difficult to read the function's code.

Anyway, unlike object attributes, variables in Ruby are not explicitly declared at all. So this would be the case in Javascript using the approach I suggest, except that we must declare the variables otherwise they would become global.

There are several situations where variable declarations are unnecessary. For instance, using jQuery:

var el = $('<div/>') var body = $('body') body.append(el)

This could be written using no variable as:

$('<div/>').appendTo('body')      

I think this is just an example of a smart refactoring.

Or even as:

$('<div/>').text('content').appendTo('body').click(function(){alert('clicked: ' + $(this).text())})

or

$('<div>content</div>').click(function(){alert('clicked: ' + $(this).text())}).appendTo('body')

I usually use this approach whenever possible. I think it is much clear for other developers trying to understand what the code does. When there is some declared variable, you have no idea when and what it will be used for.

Also, I don't like to see 80 characters only page delimiter because most screens nowaday are wide and have small height. This mean we should avoid several lines of code in favor of lengthy lines. What I mean is that there was some reasoning for using 80 characters delimiter in the past that is no more valid nowadays. It is much better to get as much code as possible without the need of scrolling, unless the code readability is affected, which I don't think is the case in the above examples.      

Here is where I disagree with you most. I don't think the 80 character limit has anything to do with screen resolution.

Maybe it's because I don't really mind scrolling, but I'd much rather scroll down than across, and I'd much rather read a number of short statements down, than a long statement sideways.     Of course, there is a limit. I also don't like scrolling horizontally (much worse than vertically). But I think 80 is too little for nowadays standards.

I'm a huge fan of the jQuery style of chaining functions on new lines:

$('<div/>').text('content')                .appendTo('body')                .click(...)     This is exaclty the situation I hate because of the waste of screen space :slight_smile:

I don't see any problems either with the ++ and -- operators, but of course someone should understand how they work. And Javascript should be tested as well, the language is not an exception. There are good frameworks for that, as Selenium, for instance. So, why avoid the great features of the language? These operators works exactly the same way as C, C++ and Java...      

Javascript has some great unit testing frameworks too.     Sure, we have no excuse at all, have we? :wink:

Well, actually I was wondering writing some post about this topic on my site, but ended up never writing about it. Maybe, now that I have already written part of the content in this email, I can put this on my site :slight_smile: I always wanted to write about this for some years now whenever I have to read other's code in my company :slight_smile:

Here I have only given JS examples, but there are other subjects in other languages as well I would like to cover...

Sorry for the post-in-email-shape :slight_smile: Too long for an e-mail, probably, but please don't blame me. You have inspired me with this subject :wink:      

Very cool discussion to be having.     Yes, thank you for the comments! :slight_smile:

Best regards,

Rodrigo.

Hi,

> Crockford's rules are backed by pretty strong logic. I'd recommend > reading "The Good Parts" ... he has some compelling arguments.

I'll take a look when I have some free time.

http://developer.yahoo.com/yui/theater/

It is very, very well worth taking the time watching the videos - even if it takes a couple of hours total!

I managed to convince several programmers to at least take a look, and they all ended up watching almost all of it.

Crockford is the inventor of the JSON format - but more important, he is credited with being largely responsible for spreading the news that JS is a great modern programming language. Several now widely used patterns for encapsulation, inheritance (prototypical or classic), etc. are his design. He isn't just some random programmer, he carries enormous weight in the JS community (meaning more those on the top including in the ECMA commities etc., those who "only use" the language unfortunately are not all aware of him - as can be seen here).

As I said, once you know the reasoning you can follow his suggestions. It just happens that we don't use minifiers at our company since

Excuse me, but here we are talking about the JS in Rails, a framework used by thousands!

Javascript is cacheable and there is no such "one-time users" thing with our products. The overhead is also negligible for not using any JS minifier. I mean, even if the JS code is reduced to 1/3 that would mean

That is WRONG. Please multiply the homepage by the nr. of hits. Okay, the reasoning for Google and Yahoo is orders of magnitude stronger...

Pls. also have a look at the research mentioned somewhere at Yahoo, in one of those videos above by a Yahoo (JS) engineer in one of the other videos I believe about users and page loading. From personal experience I agree with their findings. Way too many pages even of big professional sites (who should know better!) waste my time and make me very impatient with loading of way too much stuff before I get to see anything. It's one thing for an app (e.g. gmail), but when I load a page for German-English translation to look up a word and have to wait several seconds - even though there's just one lonely input field... anyway, cutting down from 800ms to 500ms page load time IS a huge deal!

If you feel it is not necessary pls. go ahead and don't minify your code - but pls. leave that option open for the rest of the Rails users. We are talking about the rules for a widely used framework, not about individual decisions.

Great discussion though.

Michael

Hi,

>> This could be written using no variable as: >> $('<div/>').appendTo('body')

> I think this is just an example of a smart refactoring.

No it is not.

>> Or even as:

>> $('<div/>').text('content').appendTo('body').click(function(){alert('clicked: >> ' + $(this).text())})

There is a reason why Java is so important today in "professional programming". When you have (sometimes very large) teams of programmers (of all types - and quality!) working on projects for years, when code has to go through many hands (over time and through departments or even companies), often with changing programmers, you have to have a different style.

Apart from the problem that if any one part of such a chain fails it's harder to find out WHICH part did so compared to having it all on a single line, it simply isn't as readable (whatever you say, that's a psychologically proven fact) - unless you have very little code.

Of course, when JS is used only for adding a little interaction to a page - go ahead like this. However, when you write a application I'd fire you instantly before you create even more chaos to be untangled later by others trying to debug your code :slight_smile: For example, in such projects I want to have the code that binds behavior to the UI in one place - but the actual functions doing that job in quite another, so no anonymous functions right inside the .click(....), ever. Readability for large pieces of code would be impacted severely otherwise.

Michael

Hi,

   ...    

As I said, once you know the reasoning you can follow his suggestions. It just happens that we don't use minifiers at our company since      

Excuse me, but here we are talking about the JS in Rails, a framework used by thousands!     In the case of jQuery-UJS, we are talking about 4k of JS code. I wouldn't say this is that much significative... This can reach 2k using minifiers but that means we would be saving only 2k by minifiying...

Anyway, if you think about it, I can't find any reasons why a minifier should made a mistake.

Javascript is cacheable and there is no such "one-time users" thing with our products. The overhead is also negligible for not using any JS minifier. I mean, even if the JS code is reduced to 1/3 that would mean      

That is WRONG. Please multiply the homepage by the nr. of hits. Okay, the reasoning for Google and Yahoo is orders of magnitude stronger...     In the context, I was talking about my individual situation...

If you feel it is not necessary pls. go ahead and don't minify your code - but pls. leave that option open for the rest of the Rails users. We are talking about the rules for a widely used framework, not about individual decisions.     I'm not taking any decision at all... :slight_smile: I'm just saying that I don't think the semi-colons won't make any difference here... But that is just a discussion, not a decision (I don't have any write-permission on these repositories at all :slight_smile: ).

I don't mind either if they decide to use semi-colons. It won't make any differences in my opinion...

Great discussion though.     Thanks,

Rodrigo.

Hi,

This could be written using no variable as: $('<div/>').appendTo('body')           I think this is just an example of a smart refactoring.        

No it is not.

Or even as:           $('<div/>').text('content').appendTo('body').click(function(){alert('clicked: ' + $(this).text())})           There is a reason why Java is so important today in "professional programming".

Well, that is your opinion. I don't give that much importance to Java, even though I do Java development at work most of the time.

  When you have (sometimes very large) teams of programmers (of all types - and quality!) working on projects for years, when code has to go through many hands (over time and through departments or even companies), often with changing programmers, you have to have a different style.     That is exactly what happens in my company, but Javascript is hardly the problem here and we do a ton of Javascript coding here. Usually, Java is the problem here... We develop lots of interactive UI with maps, services, etc, which results in lots of Javascript. We don't separate our JS code as you suggests and this has never been a problem at all here. But understanding other's Java code here have been a pain for new developers... We use a lot of anonymous functions here and I think it is easier for newcoming developers to understand the code that way. It smells like Ruby closures I would say...

Apart from the problem that if any one part of such a chain fails it's harder to find out WHICH part did so compared to having it all on a single line, it simply isn't as readable (whatever you say, that's a psychologically proven fact)

Why do you say so? If I'm saying that my experience reading more lines per page is better, than it is certainly a matter of taste. You (or someone else) cannot prove this is not, once I don't agree... This is logical to me... You can take statistics about what most developers think about the subject, but you cannot prove all of them will think that way...

Anyway, where is the link for such affirmation proving that statement?

  - unless you have very little code.

Of course, when JS is used only for adding a little interaction to a page - go ahead like this. However, when you write a application I'd fire you instantly before you create even more chaos to be untangled later by others trying to debug your code :slight_smile:

We would probably never work in the same company, then. :slight_smile: Anyway, some say automated testing exists exactly for situations like that... :wink:

Regards,

Rodrigo.

Aaaaaaaaaand this is getting a bit off-topic. If you guys want to fight, that's fine, I'll get some popcorn, a boxing ring, and a bell to signal the rounds. But it's probably better not to do it on this list :wink:

Cheers

Fully support Nicolás about this not being a place for religious discussions about JavaScript. Michael, did I understand correctly that what you said below in 2 simple sentences were the only things actually wrong with the script?

Aaand my commit access is back, and the fixes are pushed:

http://github.com/rails/prototype-ujs/compare/35b4551…c00e908

It doesn’t pass JSLint because we have if/else one-liners without curly brackets. No biggie.

We would probably never work in the same company, then. :slight_smile:

Indeed.