Was Standardizing On JavaScript a Mistake?

snydeq writes "Fatal Exception's Neil McAllister questions the wisdom of standardizing on a single language in the wake of the ECMA Committee's decision to abandon ECMAScript 4 in favor of the much less ambitious ECMAScript 3.1, stunting the future of JavaScript. Had the work continued, McAllister argues, it could have ushered in an era of large-scale application development that would ensure the browser's ability to meet our evolving needs in the years ahead. 'The more I hear about the ongoing efforts to revise the leading Web standards, the less convinced I am that we're approaching Web-based applications the right way,' McAllister writes. 'If anything, the more we talk about building large-scale Web applications, the more we should recognize that a single style of programming will never suit every job.' McAllister's simple truth: JavaScript will never be good for everything — especially as the Web continues to evolve beyond its original vision. His solution? 'Rather than shoehorning more and more functionality into the browser itself, maybe it's time we separated the UI from the underlying client-side logic. Let the browser handle the View. Let the Controller exist somewhere else, independent of the presentation layer.'"

Comments

Re:Got it wrong

[coryking]

I don't see what more you might want in javascript

- A real way to include other javascript files.
  - A well defined way to say "The page is loaded, all your variables and objects are loaded, Time to execute!" rather then "You can only see the variables and objects that are defined 'above' you and not 'below' you in unloaded portions of the page".
  - Ponies.

Reasons why browsers are poor application runtimes

[betterunixthanunix]

1. HTTP is connectionless, but many applications don't make sense in a connectionless setting
2. Client side privileges are difficult to control, and relying solely on the server for security is not always possible
3. HTML/XML requests use more bandwidth than binary protocols, which strains slow connections (yes, some people still use dialup, especially mobile users, and here in America many mobile users still rely on 9.6kbps cell phone connections). *ML requests also include a lot of useless tags that describe the "document," even though it is really an RPC request.
4. XMLHTTPRequest is not standardized across all browsers, and multiple copies of some sections of code must be sent, wasting even more bandwidth.

Anyone who wishes to amend this list is welcome to. I'm *ML requests sure there are even more reasons, that I am just not thinking of at the moment.

Re:Got it wrong

[AKAImBatman]

Start at the source:

http://developer.mozilla.org/en/Core_JavaScript_1.5_Guide

That document may be nearly 15 years old (plus/minus revisions along the way), but it's still the definitive method of learning Javascript.

For those who actually take the time to read it, that is.

Good luck! :-)

Re:Got it wrong

[AKAImBatman]

Say you needed to use the YUI calandar control on a page that also uses Prototype (for lightbox2). Now the two libraries will "fight" over the browser's onload.

That's because "framework" developers refuse to get with the times.

function done1() { alert("All done!"); }
function done2() { alert("All done!"); }
 
if(document.addEventListener) window.addEventListener("load", done1, false);
else window.attachEvent("onload", done1);
 
if(document.addEventListener) window.addEventListener("load", done2, false);
else window.attachEvent("onload", done2);

Some people who are otherwise very smart with Javascript (e.g. Douglas Crockford) can't seem to figure out why you might need more than one listener for an event. Sure, you could chain the events, but that's ugly. DOM 2 Events already exists, so why not use it?

And for the record, the conditional code wouldn't be necessary if Microsoft wasn't a bunch of tools. God help us all if they ever actually decide to... oh, I dunno... implement a standard they helped create. But that's just my opinion.

Re:Got it wrong

[DougWebb]

- A well defined way to say "The page is loaded, all your variables and objects are loaded, Time to execute!" rather then "You can only see the variables and objects that are defined 'above' you and not 'below' you in unloaded portions of the page".

jQuery's $().ready( function() {...} ); method has been a fantastic help in my Javascript development. It executes after the DOM has been initialized, but before all of the images have been loaded. window.onload() waits for the images to load, which delays your javascript from running until after the page has been rendered. jQuery doesn't do that; your code will often run before the page is rendered, so you can use javascript to enhance/replace elements that work without javascript too. For example, I often have UI controls which will refresh the entire page to perform their function when javascript is not enabled, but they'll use AJAX and refresh only the necessary elements if javascript is enabled. Using jQuery, I can attach events and alter CSS classes before the user sees the page, so javascript and non-javascript users get somewhat different looking, somewhat different behaving, but always fully functional views of my application.

Re:Got it wrong

[coryking]

Sure, you could chain the events, but that's ugly. DOM 2 Events already exists, so why not use it?

Dunno, but I'd imagine one reason might be to "standardize" the broken "body onload" event. For those who aren't up to speed in how crappy IE6 is... IE6 doesn't fire the body's OnLoad event when it uses a cached version of a document, it only fires when it loads a fresh one. Grrr....

Another reason I can think of is some of the libraries (YUI comes to mind) offer easy-ish ways of creating your own events. Having a (library specific) standard method to hook events that works with the (library specific) standard way of creating events might be nice.

Seriously, the bloom of incompatible javascript toolkits isn't making my life easy. I've standardized my own javascript code around Prototype (which is used in Lightbox). There are lots of cool jQuery-only and MooTools-only widgets I'd like to use, but I dont want to have clients pull down three javascript libraries for just one page.

And to finish my rant... just wait until your javascript toolkit vendor ships out a new version (prototype 1.6) that isn't completly compatible with it's old one (1.5). Just wait until 1/2 your widget set breaks on 1.6 and half breaks because of 1.6.

I love web development.

I've been playing with Silverlight. Took me a single night to cook up a file upload control that works on IE6,7,8, Firefox 2 & 3, Intel Mac & Windows (even 2000) and will work on any other platform Microsoft targets in the future. It just nestles itself right into my HTML all cute-like with no fuss. You can get your javascript code to interact with it just like a DOM object -- events and all. It is server-side agnostic and since it can serialize/deserialize JSON, it can talk with all the same server-side AJAX stuff my existing client-side javascript code does. In other words, it appears to be trivially easy to replace the javascript widgets with silverlight ones without touching a line of server-side code.

How long would it have taken to do the same file upload code in Javascript? Probably a week and a month of dealing with users running some spyware/toolbar that breaks the production code in insane ways.

Times are a changin!