Was Standardizing On JavaScript a Mistake? 525
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.'"
Re:Got it wrong (Score:5, Informative)
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 (Score:5, Informative)
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 (Score:4, Informative)
In modern Javascript usage you leave that to a framework library such as Prototype, mooTools, jQuery, Dojo etc.
Re:Got it wrong (Score:5, Informative)
Start at the source:
http://developer.mozilla.org/en/Core_JavaScript_1.5_Guide [mozilla.org]
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 (Score:4, Informative)
Yep. Also the Microsoft reference on "JScript" is pretty good.
http://msdn.microsoft.com/en-us/library/4yyeyb0a(VS.85).aspx [microsoft.com]
The 1990s called and offered you a job. (Score:3, Informative)
1. By Many you mean 1% of the total applications excluding games written. Most frameworks for applications are this. Take Input process data produce output. Step one takes time so there is no need to keep a connection there. step 2 - 3 is done on the server. After you get the data you don't need the connection until the next input. Your way will have the server get overloaded much quicker then with Web Apps as it needs to keep connections until they quit.
2. I have heard this argument before however I have NEVER in 10 years ever seen this to come across a situation where not relying solely on the server for security didn't work. The server controls what the client see and it also can filer or reject what the client asks. The only case I can think of preventing someone from printing your document... However this exists across all other apps where doing a screen shot and printing that works too.
3. Most of the bandwidth used is not text data but binary information like pictures which take the most time. 9.6kbs is 1k a second. normally an complex page is about 10k so that is 10 seconds. But wait most browsers will render the html before it is completely downloaded so you can read input before it completes. Secondly most mobile users who use this speed are on phones that aren't designed well for the web and not recommended to for use of most apps. The iPhones and other smartphones more suitable for wireless web use a faster connection.
4. The extra stuff will only take a fraction of a second.
Techniques such as AJAX actually improve speed as it allows the server to handle smaller chunks and send it smaller chunks using the clients PC (which normally has a LOT of CPU Free to do most of the work) Covering the gap you mentioned in 1.
Re:Reasons why browsers are poor application runti (Score:1, Informative)
1. You mean stateless but that's been solved with sessions.
2. Privileges must be controlled on the server. That's the only reasonably safe place to do it. If you don't have access to the server, don't expect the app to be secure.
3. Enable gzip on the webserver.
4. XMLHTTPRequest might not be an official standard but it is supported in all major browsers so it is a standard that way.
Re:Got it wrong (Score:5, Informative)
That's because "framework" developers refuse to get with the times.
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 (Score:5, Informative)
jQuery's [jquery.com] $().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 (Score:2, Informative)
Re:Got it wrong (Score:4, Informative)
PHPMyAdmin, OSCommerce, CodeIgniter... yep. Just quick and dirty hacks. Come on, lay off the generalizations.
PHP doesn't make crappy code, coders do. The same could be said (and has been said) about Perl, but it doesn't make it true.
Re:Got it wrong (Score:5, Informative)
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!
Re:The 1990s called and offered you a job. (Score:3, Informative)
Well...
* Most applications we need to store information to be commonly shared.
* Giving people access to install and update apps is stupid.
* Having an IT Staff update every clients app for every small (but critical) change is expensive and time consuming.
* Having multiple apps point to the same file is a BAD idea.
* Syncing multible files can be troublesome,
* Making sure the binary file is secure is much more difficult (text based passwords embedded in executables, names of servers/odbc even particular SQL calls are often readable and modifiable.
* Diversity of hardware/software configuration which may cause random bugs.
* Remote access.
* Scaling the company up is easer.
* Upgrade and New OS's are easier.
* Usage monitoring.
* Disaster Recovery
* Easier DB Secuirty
Most apps are not doing tons of calculations. Most of the speed loss is via IO.
Re:Got it wrong (Score:3, Informative)
Defer only works in IE. Firefox doesn't support it, and I'm pretty sure Safari doesn't support it either.
Comment removed (Score:3, Informative)
Re:Javascript language concepts (Score:1, Informative)
Really? You've never developed in PHP, Perl, Python or any other language that does autovivification?
Re:Javascript language concepts (Score:3, Informative)
http://www.linuxtopia.org/Perl_Programming/pickingUpPerl_29.html [linuxtopia.org]
Re:No ActionScript is great! Really! (Score:3, Informative)
You should learn your history... ActionScript 3 was actually based off of an early proposal for "JavaScript 2", written by Mozilla (or maybe it was Netscape at the time.
The goal was for it to be standards-compliant with the next major revision to JavaScript.
Re:Javascript language concepts (Score:2, Informative)
voila:
http://jsunit.net/ [jsunit.net]
Re:Javascript language concepts (Score:3, Informative)
"I will also add, that I don't like prototyping as a concept and prefer OO over it. "
Huh? That makes no sense. Prototyping *is* OO. What it is not is *class-based* OO. It's in fact a much more flexible and natural way of doing OO and allows for better modelling of real-world situations.
The point of prototype-based OO is that you don't have two separate entities for 'class' and 'object': you only have one, and then you have the 'prototype' relation which is runtime-assignable to implement inheritance. Logically, this means you have much cleaner semantics (you don't need, ie, a meta-object protocol to define what kind of object a 'class' is); pragmatically, if you do it right, it means you can *change the class of an object at runtime*, which is in fact something that happens in The Real World.
(A Person starts out as a Baby, becomes a Child, then an Adult, all over the lifecycle of one object. Try doing *that* in Java with fixed class hierarchies. That's a bug in the Platonic idea of immutable 'classes', not a bug in the Real World.)
The other case where prototype OO rocks the house is where you have a heavily data-driven model with lots of singleton objects. In prototype OO, there's nothing at all weird about putting special-purpose methods or slots onto instance objects - in class-based OO, methods can only be put on classes, and instance objects can't have special-case slots at all.
Where this is a *huge* win is in GUI code, where you have all these special-case object instances representing widgets *with bound events*.
If you can't put method code directly on your instance objects, then you have to go through hideous convolutions of method calls on the class to simulate this by passing it as data. But with prototype OO, you can just put the code right where it needs to be, tweak the instance exactly how it needs to be tweaked, and it just works.
To really make this work you also need to have a language that allows the code you put on instance methods to also be special-cased in the same way; in other words, it needs to support the concept of *closures*. IE, the sweet spot for GUI development is a language that combines functional and prototype OO features. Javascript does this, and that's why it wins in the UI game.
Re:Got it wrong (Score:3, Informative)
There are step-through debuggers like FireBug, but I've never felt the need to use one. You may find such a debugger more interesting, though. :-)
Dont listen to this man. He knows not what he speaks of. FireBug is teh awesome! For one thing, it will keep a nicely parced log of all your HTTP requests to make AJAX debugging easy. For another, it is just awesome.
But yeah... I've never used much of it's step-by-step debugger. For some reason, I've never found the need--could be because javascript stack traces can be a little wonky with anonymous functions. And probably because most of the reasons *to* debug something are because of IE6 being retarded.
Re:No scripting language is going to solve (Score:3, Informative)
Bruce disagrees [schneier.com]
Re:Javascript language concepts (Score:3, Informative)
The most awful example is the concept of "undefined." Javascript is the only language I know of where it is legal to say:
Perl will let you do that, although the warnings pragma will remind you "Use of uninitialized value in numeric eq (==)". But in Perl, you test whether or not something is defined with defined(), or whether a hash key exists with exists(), so you don't need a crazy === operator.