We use events, but only register them via DOM addEventListener or attachEvent. We don't use traditional style element."onxxx" event handlers.

From today I have decided that various non-essential (but desirable!) UI features will only be supported on IE8 to help our clients want to change. Also I have just spent more hours on an IE6 workaround, and I have had enough!

The last para is really the key point - we go through the pain, because the result is that client want our service enough to pay good money for it.

2nd "low bandwith" should be "low latency". UI can be made responsive and it is noticable.

Advantages:

• Fast response even on slow connection.
• Low bandwidth.
• Potentially off-line (we don't need that, but could do it).
• Low bandwidth.
• Offload rendering and UI work to client.

Dis-advantages

• Limited choice of components. Often need to rewrite or author your own. No single popular library - incompatible components.
• Much slower to develop - hard to build on top of other's work.
• Difficult to make user friendly (few common user experiences, incompatible with some normal browser user behaviours).
• Memory leaks: Ugggh. IEJSLeaksDetector v2 is great to detect them (and we wrote a custom tool to detect "deleted" Javascript components that were still referenced). Rules for component framework: must not use element.onxxx, must track all attachEvent calls, must detachEvent when component destroyed. On unload framework: must detach all events, must set all global window.xxx to null, must set any document.xxx variables to null. Elements must never reference javascript objects (Object, Function, or Array). Unfortunately most libraries don't get it right ( to prevent leaks we had to develop various custom memory leak prevention code, edit control code, and completely replace event registration code).
• XMLHttp communication issues - ugly.
• Cruftiness - dirty workarounds, reliability problems, usually must support IE6 so often limited to what that can do.

For us, the pain has been worth it. Our clients just buy our service with very low deployment issues, fast pilot and training, fast rollout, nasty dependencies are avoided, and political involvement by IT departments is minimised.

100% agree. We use browser side controls and all HTML rendering is done on the browser. We avoid manipulating strings except where required for performance (pure DOM is too slow and we have to support IE6. Easy to avoid script injection by careful design). Solves a bunch of problems - the biggest problem is the lack of good libraries and controls. It feels like programming for DOS.

Amen. JavaScript is following Lisp's footsteps: no common community, incompatible libraries, incompatible implementations, and a lack of common goals. CommonJS is a perfect example.

Server side requirements are grossly incompatible with browser side requirements.

IMHO unless you have peculiar needs, preferring a serverside JavaScript framework over an existing server language and framework is for fools.

PS: disclaimer: I develop a browser based application using JavaScript (with an application server using JSON - not an HTML/CSS generating web server)

PPS: I would like to see HTML split into two standards: a static form for documents (zero script, no dynamic CSS3 etc), and a dynamic form for applications (JavaScript, DOM, Libraries). I hate the trend towards flash-like HTML documents. I do like browser deployed applications though.

I have an Asus 520GU running OpenWRT. The current limitation is you have a choice of running the 2.4 kernel and getting wifi but there are some USB issues (although USB is working fine for me - YMMV), or the 2.6 kernel and getting no wifi.

Apparently the closed braodcom driver has now been reverse engineered for 2.6, but it isn't yet in the main branch so you have to do your own build and patch of the kernel.

The latest memory leak tools for IE6/IE7 are actually pretty slick. Version 2 of IEJSLeaksDetector tells you the line the leak occurred at. And sIEve is good for finding in page leaks (i.e. leaks when you are constructing and destructing components within a single page Ajax app). Before those tools, I spent months trying to resolve IE leaks.

Also I have written my own tool to check that "destroyed" JS objects (components on our Ajax page) are not reachable from window i.e. objects will be garbage collected. Code was a fairly simple traversal of objects and arrays - one day's coding.

If you want "real" classes you can use a JavaScript implementation that supports the proposed standard. Or choose a library - they do make prototyping look and smell like OO. Sure there are quirks, but all languages have their own quirks. Or are you complaining about current browser implementations?

Not sure of your gripe. Never had a problem.

The Microsoft Studio JavaScript debugger works fantastically well. I prefer not to use MS tools, but I use the best tool available to me. Other in-browser JS debuggers have their advantages.

What's your problem? JavaScript wasn't designed to be an "enterprise" language and mostly does not have enterprise tools. However, it is not much more difficult to manage than most other dynamic languages. Pick the right tool for the job.

Definitely sounds like you *are* confusing the language JavaScript, with the implementations you know.

You are advocating walking into a woman's house while she is gardening out the back, and leaving a note in her knicker drawer explaining why her knickers are insecure.

There is a social norm of not invading privacy, even when it is possible to do so.

Except: "Each partial instance-hour consumed will be billed as a full hour." - from http://aws.amazon.com/ec2/#pricing

Do students prefer to use machines that have a view out of the window?

Did the sun shine in the window during the day?

Was the error distribution at night the same?

Was the pile offcenter? (the cone depends upon location)

If the engineer presumed it was Alpha (or Beta, or Neutron) radiation then that is not a good sign they are that clued up. Although gamma could be a possibility.

Did you look at the reviews of the model you knew was good to see if it had the same number or type of negative reviews?

I have not been to the US since the introduction of its id/facist-checkpoint/visa requirements. In the past I have skied there for months, always enjoyed it there, and it is an easy stopover for me. US travel no more for me!

I have also travelled to Rio - and it is the only place I have ever been mugged - but I would still go back. Hopefully they can clean up the pestulent beaches where the sea is loaded with desease...

I love the example given in Language and Cognition: Investigating the Sapir-Wharf hypothesis:

'Follow me to Pormpuraaw, a small Aboriginal community on the western edge of Cape York, in northern Australia. I came here because of the way the locals, the Kuuk Thaayorre, talk about space. Instead of words like "right," "left," "forward," and "back," which, as commonly used in English, define space relative to an observer, the Kuuk Thaayorre, like many other Aboriginal groups, use cardinal-direction terms â" north, south, east, and west â" to define space.1 This is done at all scales, which means you have to say things like "There's an ant on your southeast leg" or "Move the cup to the north northwest a little bit." One obvious consequence of speaking such a language is that you have to stay oriented at all times, or else you cannot speak properly. The normal greeting in Kuuk Thaayorre is "Where are you going?" and the answer should be something like " Southsoutheast, in the middle distance." If you don't know which way you're facing, you can't even get past "Hello."'