var x = 1;
    var y = 1;

    function methodA()
    {
	return
	    {
	 	javascript: x + y
	    };
    }

    function methodB()
    {
	return{
		javascript: x + y
	};
    }

    (0.1 + 0.2) * 10
    (1 + 2)

surely ... but ...

  >> (0.1+ 0.2) * 10
  3.0000000000000004
  >> (0.1 + 0.2 + 0.1) * 10
  4

I had to go and try it just because I could not believe it, now can anybody explain to me why there is a difference here ?

Ostensibly, this was added to the language to make it more user friendly. Instead, it's the source of a lot of bugs.

Here is a decent overview: http://www.openjs.com/articles/semicolon_insertion.php

This ought to be deprecated and exterminated.

The notion of writing a program to run on someone's desktop is reasonable; the notion of writing a program to run on my server, but send it's display information out to a browser, is also reasonable. The idea of having most of a program be on my server, but some random chunks be on the user's computer, seems like a bad split. I realize that in some cases such as input data validation it can remove a browser-server round trip, and in some cases it might be an over all win; but as a general rule it's a bad idea.

There is an idea that you can avoid the load of running everything on your server, but also avoid the problems of writing client programs for all the variations of operating systems, by writing code that runs in some wrapper, usually associated with the browser. These attempts - flash, java applets, javascript, active X objects, etc - are all bad ideas.

I realize that the majority of the population uses javascript enabled browsers. I didn't "miss the memo", I was there when the memo came out: I remember attending free lectures given by Sun Java evangelists when Java was first released, in fact I still have a free coffee mug with "headstart java" or something on it around here. I got excited, did the "hello world" app and then a calculator, and then suddenly had to disable java applets to keep the ads from crapping up my browser. Javascript came after that, then flash, now it looks like Microsoft is pushing this silverlight thing which sounds like v5.0 of the same bad idea.

Now, just so I don't totally seem like an old grouch, here's some constructive advice: write your web app so it's interface is all very standard, very minimal html. Then, write an iPhone program that does the client-side stuff you think is so great. If you are still in business after that, take the iPhone app and make it into an OSX desktop program and announce your iPhone app is now available on the desktop. Presuming your idea is not the friendster or geocities of it's age and already dead, and presuming that people find these client-side features appealing enough to download and install something, then move on to making your desktop client work on other platforms. Do not take the shortcut of presuming that the browser is an appropriate platform.

You don't like Gmail? Or Google Maps? Or the fact that when you click an up or down arrow here on Hacker News, you don't have to reload a new page?

I would not mind selecting a pull-down or radio button and hitting submit at the bottom of the page, however. In fact I'd prefer it.

And there are more examples of such systems poorly implemented, often to the point that they kill the usefulness of the site. Slashdot's firehose with it's + / - buttons is like that, and slashdot's main page has become like that, but I am logged in have as many "new features" turned off in my preferences as possible. When I type text into a box on Facebook, I can outrun the letters appearing by several sentences. There are numerous sites that use various kinds of javascript rich text or html editors that are also pretty unuseable.

I like gmail, but not it's javascript features. I use the basic html setting, because if I live it up with the normal setting, my browser will become unuseable after a few hours. It was particularly bad in some of the previous versions of firefox, which apparently had some memory fragmentation issue regarding parsing javascript, but as javascript brings no benefits and makes the page take slightly longer to upgrade, I have never switched back even now that I have the latest upgrades to the browser.

I like google maps as an application, and I use it pretty extensively, at least once a week. I don't find it's panning arrows and so on particularly appealing, and I habitually restart the browser after using it, to clean out any javacrap memory issues remaining.

And it is not simply the idea of the type of interface google maps has that I object to: for example, I love Google Earth, and I like to change the angle of view and rotate around various landmarks and so on. This is on the same computer where I turn off java script for gmail. So it's not just that I have some Amish insteance on older interfaces. It is that javascript in the browser sucks.

Now, that doesn't mean you won't make a billion dollars making a web site that depends on javascript, of course. But all other things being equal, I think you should focus on interfaces that are very simple and very fast if you want to get adoption. It's probably more important to hand-code your html and run it through packing scripts that remove all whitespace and etc, to really scrape every last byte out of what is sent to the user, than it is to have an up/down arrow that automatically submits to the server.

I find it terribly annoying when a site requires javascript, but doesn't do anything compelling with it. For instance, why on earth does this page require javascript to be on, just to show me a .jpg map? http://www.arkansashighways.com/Road/mapopt.htm

as an example, steve gibson (of grc.com) won't use it, iirc.

and they're right, really. you can't put bulky business logic in javascript if you have any need for security.