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.'"

Got it wrong

[AKAImBatman (238306)]

So here's an idea: Your Web browser window is a View. Maybe it's high time we stopped trying to force it to be a Controller, too.

Here's an even better idea: The HTML DOM would be the View, the Javascript would be the Controller, and the server would be the Model! I'll bet I'm the first one to think of that...

So if nobody ever managed to come up with the ultimate, perfect language for systems programming, what makes us think we can do it for the Web?

The browser model allows for languages other than Javascript. (e.g. VBScript is somewhat popular in IE-only applications.) It's just that no one has come up with a better language. If no one comes up with a better language, why reinvent the wheel?

Ever since the early days of Web browsers we've had this language, JavaScript. Over the years, we've demanded more and more of it, to the point that we're now talking about using it to build entire applications. The simple truth, however, is that JavaScript will never be good for everything.

That's one person's opinion. My opinion (and the opinion of many others) is that Javascript is a very powerful LISP-like langauge capable of far more than its given credit for. Part of the reason for abandoning ECMAScript 4 is that v3 already supports most everything we need. It's not perfect, mind you, but it doesn't actually NEED the features of v4. Most of those features are syntactic sugar that makes the language more comfortable to Java programmers.

Behind the scenes, nothing really changes with the common features of v4. There's some type checking and a few other minor additions going on, but otherwise the objects are translated into Javascript objects.

Strong typing, packages, and namespaces may make it a lot easier to maintain large applications, but they're virtually useless to any Web coder who just wants to bash out a little bit of UI glitz.

And there-in lies the problem. People think of Javascript as being for "UI Glitz". That's the real issue to tackle. Not the imagined lack of MVC.

Re:

[mcvos (645701)]

It's just that no one has come up with a better language.

No one has been able to come up with a better language than javascript? That's a scary thought.

Re:Got it wrong

[Swizec (978239)]

The problem with javascript isn't that it's a bad language, the problem is that everyone continues on thinking about it as a tool for quick and dirty hacks. But guess what, that's how PHP started out and look where it came.

All javascript really needs is to be well supported in all browser and that people would stop thinking about it as just a script kiddie tool. Javascript is perfect for what it was intended to do and it's very good even for what it wasn't exactly intended to do and THAT's why there hasn't been a "better" language yet, because this one is good enough for the job. Frankly, outside of becoming standardised all over, I don't see what more you might want in javascript that you absolutely cannot live without.

Re:Got it wrong

[coryking (104614)]

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.

Re:Got it wrong

[Chaos Incarnate (772793)]

Any spec without ponies is a defective spec indeed.

Re:Got it wrong

[DougWebb (178910)]

- 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 [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

[coryking (104614)]

That document.observe is all great until you try to mix Prototype (or any of these libraries) up. 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.

Actually.. that is the biggest problem we have right now. Dozens of javascript libraries and all do pretty much the same thing. All of them "weight" like 20->40k. That "weight" and the potential for them to conflict make life really hard.

What if you based your own code on Prototype and want to integrate a really nice file-upload control that uses MoTools?

What if you are using Prototype and you drop in TinyMCE. Now you've got two runtime libraries that both have their own methods for injecting objects into the DOM. Those two methods are ever so slightly incompatible so if you create a DOM object via Prototype (actually scriptalicious) and try to inject it using the TinyMCE way, things will break in random browsers in very hard to track way.

Enter Silverlight/Flex. Now you can go from dozens of Javascript runtime libraries to only two very stable ones. As the "UI control" scene for these grow, I suspect our dependency on Prototype/jQuery/Whatever will shrink.

After all, it has to be way easier for control vendors to target Silverlight/Flex then it is for them to target javascript. And as a bonus, it is way easier for me to integrate their UI controls into my own Silverlight/Flex application.

Re:Got it wrong

[AKAImBatman (238306)]

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

[coryking (104614)]

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:Got it wrong

[PitaBred (632671)]

Except there will be no first-party support of Silverlight for Linux, ever, so it will always be a second class citizen in the .NET world. Assuming Moonlight even gets to the 1.0 status, or ever works as a browser plugin. The gnome guys working on it are so busy sucking Microsoft's dick for cash that they can't actually make it useful (it's compiled without any kind of multimedia support [go-mono.com], which is the main feature that it's pushed with). And the Mac will get the same treatment, the Silverlight releases will always lag significantly behind the Windows one in version and bugfixes.

Embrace, extend, extinguish. They've done it before, they'll keep trying to do it again, and people like you who say "look how little work it takes to make something locked into a very expensive OS that actively works against it's user!" just enable them to keep doing so.

Re:Got it wrong

[Serious Callers Only (1022605)]

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.

With Microsoft's track record of openness and cross platform support, what could possibly go wrong with your plan?

BTW, your upload control doesn't work on most browsers on the web today, and I wouldn't download a plugin for your content, sorry.

Re:

[Mr2cents (323101)]

Leaving the language itself aside, the big problem I see when reading javascript is all these tests to check on what browser it is running. If I write code, I don't wan't that mess (Luckily, I I'm not a web developer).

Re:Got it wrong

[erlando (88533)]

Leaving the language itself aside, the big problem I see when reading javascript is all these tests to check on what browser it is running

In modern Javascript usage you leave that to a framework library such as Prototype, mooTools, jQuery, Dojo etc.

Re:Got it wrong

[Cecil (37810)]

But guess what, that's how PHP started out and look where it came.

What it became? A tool for quick and dirty hacks that many people use to create applications that inevitably turn into a quick and dirty hack?

Re:Got it wrong

[Kozz (7764)]

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:

[mcvos (645701)]

One of the biggest issues I've had with it is the poor performance (relative to what it's being asked to do) in the current browser engines.

One thing I learned to avoid is big iterations. Keeping your loop as short, efficient and preferably absent as possible has a surprisingly big impact on javascript performance.

Re:

[mini me (132455)]

Javascript is an amazing language. The C-like syntax gets in the way occasionally, but all-in-all it's up there with the best of them.

The problem is that most people do not even realize that it is an object oriented language, let alone containing functional language features as well.

Re:Got it wrong

[tomtomtom777 (1148633)]

I strongly agree.

I even believe the features of v4 will unnecessarily complicate the language. Most problems in javascript arise when people try to mimic 'normal' OO-behaviour instead of using javascript's powerful prototype-based system as given.

Javascript is extremely useful to create large scale applications but most programmers are to much educated towards 'convetional' OO-programming to use it right.

I guess it is the same problem as with functional programming, which is often preferable above OO-programming for the server-side model layer. The mindset of the common programmer is simply not diverse enough to use a completely different approach, such as prototype-based or pure functional programming

Re:Got it wrong

[AKAImBatman (238306)]

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

[IntlHarvester (11985)]

Yep. Also the Microsoft reference on "JScript" is pretty good.

http://msdn.microsoft.com/en-us/library/4yyeyb0a(VS.85).aspx [microsoft.com]

Re:Got it wrong

[AKAImBatman (238306)]

WRONG!

Well, I don't know about anyone else, but I'm convinced. Your enthusiastic use of the word "WRONG!" has totally won me over. The fact that you only offered the weakest of excuses for your anti-Javascript bias does not matter. You yelled "WRONG!" louder than your opponent. Therefore you have convinced me.

Truly a masterful stroke.

Re:

[betterunixthanunix (980855)]

Wait, nobody has come up with a language better than Javascript? That's funny, because when I think of useful scripting languages, I tend to think of...AWK, PERL, Python, etc. There is nothing stopping someone from integrating one of those languages into a web browser, nor anything stopping a standard "Web Python" from being created, with a specific standard library for web apps (on the client side, that is).

Re:

[kingmundi (54911)]

>> It's just that no one has come up with a better language. If no one comes up with a better language, why reinvent the wheel?

The best language does not always gain mindshare.

Re:Got it wrong

[Blakey Rat (99501)]

I agree that Javascript/ECMAScript is an excellent language.

Real web-application development isn't being hampered by JS, it's being hampered by the crappy and woefully insufficient DOM API.

For example, make a Visual Basic (or RealBasic if you're rabidly anti-Microsoft) form and add a scrolling textarea to it. Take a look at the properties inspector, and notice how many properties it has.

Now do the same thing in DOM. Can Javascript tell which text is selected? No. Can it set the text color, size, or font? No. (There is such a thing as a rich-text textarea, with those options, but DOM API has virtually no access to any of it.) It's simply ridiculous how incomplete DOM is, and that's where your true problems lie.

Of course, most people (even a lot of web developers) confuse Javascript with DOM and assume they're the same thing. They aren't; if you used python or ruby or any other language, you'd still be limited by a crappy DOM.

Re:Got it wrong

[by Anonymous Coward]

The other big showstopper is the total lack of multithreading/multitasking. Javascript has an event system, but it can never interrupt a function. This makes it excruciatingly hard to keep a DOM UI fluid while the application handles big chunks of data, and consequently most developers simply stall the UI (for example: Slashdot AJAX UI.)

Re:Got it wrong

[hey! (33014)]

Some day, I may write an essay "Model View Controller Considered Harmful".

It's not that MVC is a harmful pattern. It's a natural pattern that often emerges from an application of sound design principles to many problems. It's that it has become such a design buzzword that it encourages a kind of "design first analyze later" phenomenon. People are so sure they're going to find MVC that they start with it and go looking for ways to fit the problem to it.

And they find them. The problem is that the first way you find to apply it isn't necessarily the best one or the only one. I think you're brining up an example of how the design first mindset introduces blinders into people's thinking. They can't see the obvious because they're too wrapped up in the idea that MVC will magically simplify design, whereas simplifying design will often generate MVC.

I've seen so many "MVC" designs that were superficially structured as MVC, but were in fact heavyweight, somewhat arbitrary abstractions through which all kinds of responsibilities are squeezed like so much meat through the grinder.

Re:Got it wrong

[AKAImBatman (238306)]

ActionScript3.0 anyone?

ActionScript 3.0 == ECMAScript 4.0

No scripting language is going to solve

[godefroi (52421)]

... the browser-as-a-ui problem. Browsers are great for online brochures, and terrible for anything more complicated than that. If browsers were a good application framework, we wouldn't need Flash, Air, Silverlight, Java applets, XBAP apps, XUL, etc, etc etc. The sooner we realize that trying to build an "application" directly in html+javascript+whatever-server-side-tech-you-like is a losing strategy, the sooner we can move onto something better.

Re:No scripting language is going to solve

[avandesande (143899)]

I guess the last 10 years where I have put food on my table and deployed 10s of applications that are used by thousands of people are really a loss.
Thanks for clearing that up.

Reasons why browsers are poor application runtimes

[betterunixthanunix (980855)]

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:Reasons why browsers are poor application runti

[hypnagogue (700024)]

1. IP is connectionless, but somehow TCP works anyway. Session is a layer.
2. Client side privileges are IMPOSSIBLE to control, relying on the server for security is mandatory.
3. Bandwidth does not govern RPC performance -- service time does.
4. The W3C is addressing XMLHTTPRequest standardization.

Re:Reasons why browsers are poor application runti

[betterunixthanunix (980855)]

Yes, but those "holes" are usually evident when you try to force an environment to do something that falls way outside of what it was designed for. HTTP is a connectionless, stateless protocol, by design. It makes a lot of sense for document retrieval. Forms make sense, even email front ends make sense. Instant messengers, word processors, spreadsheets, etc. make no sense in the context of document retrieval or exchange. We are going down a fundamentally misguided path when we try to force those applications onto the web. That was my point.

Re:No scripting language is going to solve

[AKAImBatman (238306)]

If browsers were a good application framework, we wouldn't need Flash, Air, Silverlight, Java applets, XBAP apps, XUL, etc, etc etc.

Newsflash! We don't.

Flash was never welcome on the web. It was responsible for some of the most horrific, unusable sites known to man. For the most part it has disappeared from common UI use. However, it did manage to find two major niches:

1. A standard for Web Video (because no one can friggin' agree on a standard)

2. Online Games

#1 may eventually be taken care of by the new HTML5 <video> tag. Unfortunately, the powers that be still can't agree.

#2 *is* taken care of. Javascript games already exist:

PentriiX Online Multiplayer [wiicade.com]
DHTML Lemmings [elizium.nu]
Hull Breach Online [hullbreachonline.com]
Tetris using Canvas [dnsalias.com]
Pac Man using Canvas [youtube.com]

XUL is a Mozilla technology primarily used to construct Mozilla apps. It is not a web language per se.

Air and Silverlight are solutions looking for problems. The latter is supposed to be a Flash killer at a time when Flash is already at the end of its life. Smooth move, Microsoft.

XBAP is effectively the heavy-weight daddy of Silverlight. Except that it's not really a web app.

The sooner we realize that trying to build an "application" directly in html+javascript+whatever-server-side-tech-you-like is a losing strategy, the sooner we can move onto something better.

So what you're saying is, the sooner we shut down GMail, Yahoo! Mail, Google Docs, Google Maps, Digg, Meebo, and every other DHTML app in existence, the better off we'll be*?

* Ok, maybe in the case of Digg we would be, but that's the exception that proves the rule!

Re:

[Bryansix (761547)]

This is moronic. The browser has been awesome for applications even simply for the fact that it forces user interfaces that are usable as opposed to some of the shit I could come up with in Flash for instance that would confuse the fuck out of people. Have you ever browsed for flash based UIs? Its like stepping into the twilight zone. I mean seriously, tell me one thing you would like to do in an application that you can't do in a simple browser without some plug-ins. I mean obviously some things won't work

Re:

[oyenstikker (536040)]

Java Web Start!

Re:

[betterunixthanunix (980855)]

As I recall, the point of making the browser was document retrieval; the name "browser" should give you a clue on that one. Let's see...the model of it was...right, hypertext documents that were linked together, thus forming a "web" of interconnected documents -- the "World Wide Web." Where does "application runtime" fit in with that?

Re:If your customers can't install the Java player

[ultranova (717540)]

This breaks for customers who use any of several non-PC platforms such as Wii and iPod Touch/iPhone. Neither has a JVM.

The premise of this discussion was the need to design something completely new, which would replace HTTP and HTML in order to support easier to develop Web apps. Do you think that these platforms would have that something, if it doesn't have even something as common as the JVM ?

Compare the number of angry customers who use an obscure setup for which your JavaScript code breaks to the number of angry customers you'll get when Java applets don't work at all on several common setups.

I'd imagine it would still pale in comparison to people who wouldn't have Brave New Browser.

XMLHttpRequest aught to be enough for anyone

[Lord Ender (156273)]

The combination of HTML's form controls and Javascript's XMLHttpRequest gives web app designers the power they need to implement 99% of applications as webapps with very little compromise vs. thick-client apps.

Personally, I care very little about the rest of Javascript's abilities. Most often when I see them used, they add nothing useful to the functionality of the applications--just complexity and gee-whiz UI silliness.

lol wut

[Alex Belits (437)]

1. The author is stupid.

Language for client scripts is standardized not based on its convenience for web site developer. It has to be implemented in all clients, and all implementations have to provide clear separation of actions that happen within interface handled by this language's implementation, an anything that affect client platform's security. More things to implement means more incompatibilities and security holes, so standards have to limit the amount of things to implement and clearly provide limits to their functionality. Microsoft tried to break this principle with ActiveX use in its "web technologies", and ended up destroying compatibility and security even within its own product lines.

2. "Model-view-controller" is a misnomer.

Properly it should be called "model-view", there is no "controller". Internal representation of data the program operates on is the "model". Interface between program and everything outside provides "view". Program itself would exist regardless of someone calling it "controller" or not, because without a program nothing would be there to implement model, view, and their relationship, so their description would not be applicable to anything at all. No other term specifies both design principle and simultaneously treats the mechanism that implements it as a component of the principle -- it's not even apples and oranges, it's apples and Z axis.

Since when is javascript only one language?

[MarkusQ (450076)]

We standardized on one language?

Cool. I must have missed that. Now I can strip out all that browser and version detection cruft and just code to the one standard language, right?

--MarkusQ::sarcasm

I would think...

[SirGarlon (845873)]

Now it's been what, almost 10 years since The Cathedral and the Bazaar, and we still have guys like this author telling us the Wisdom of the Enlightened Few should be dictating standards to us ignorant masses who are, well, doing all the productive work.

I would think we'd be beyond that point by now.

When it's all said and done...

[klondike (9378)]

...you have reinvented X11

It's for scripting, silly!

[Pedrito (94783)]

I think the problem is the failure to distinguish a scripting language from an application development language. JavaScript is designed for the square hole of scripting. It shouldn't be mashed into the round hole of application development. Nothing lives in a vacuum. Different tools are used for different jobs. Look at any major web app and you'll probably find compiled code and scripting languages like JavaScript and maybe some Perl and maybe some other stuff.

If you make all the tools do everything, then they'll all be cluttered masses of junk. If on the other hand, different tools perform different functions, then instead of using one cluttered mass of junk, you can uses several tools that each perform specific types of tasks that they're appropriate to, as it should be.

Sure, it can be a pain in the butt to learn to use different tools, but it's far less of a pain in the butt than trying to maintain a big app written with a nasty language that tries to do more than it should.

Plugins get a bad rap.

[argent (18001)]

I agree, plugins get a bad rap, but the biggest problem with plugins is that they are restricted to a little box in the browser window. What is needed is not a better Javascript, but a better way of doing plugins. What he's talking about, I think (correct me if I'm wrong), is this: let a web page have a Java component (for example) that doesn't run in a little box... but instead runs in the background and updates the page, hiding and showing components, triggering little bits of javascript glue, and generally doing the heavy lifting without having any graphical elements of its own...

In this case, the real question: is ECMA a mistake

[expro (597113)]

Netscape went with ECMA early on and got good results standardizing Javascript. Since that time ECMA whole-sale sold out to Microsoft. Ask any normal party that has been involved and I think you will get the same answer. They are to be blamed for not only this Javascript failure, but for the whole OOXML fiasco. Microsoft went there with a single goal in mind: to block Javascript to allow their own .net-related standards to become relevant, which they get rubber-stamped through ECMA.

To a lesser degree, W3C has also sold out to Microsoft in their efforts to sell SOAP, deemphasize all the web standards Microsoft does not want to be important so, for example, they don't have to waste effort competing in the browser wars when they think they should just forever be declared the winner without having to do anything that benefits the web in general.

Should Javascript be the defacto standard on the web? Only in so far as it is useful. Like anything else on the web, if it ceases being useful, people will build a new path and do something else (whatwg, anyone?). But it is silly to call it useful or not useful based upon Microsoft/ECMA blocking the way. It sounds to me like there is some good work going on inspite of the monopolist blocade. I would hate to never see it come to light because of the many formal committees that sold out to Microsoft.

I love competition and would love to see something an order of magnitude better take over and rule the day, but that should be based upon technical merit and competing against the current success, ubiquity, and any irreparable flaws of Javascript.

I have every confidence that as ECMA continues to be paid to make good things irrelevant and bad things relevant, other standards organizations, which may start out being ad-hoc, will rise up to fill the void, and Microsoft will continue being irrelevant to those they do not own until they can really come up with something generally useful as a standard.

Javascript language concepts

[MobyDisk (75490)]

Upon a cursory glance, Javascript seems like a good language. It takes elements from some of the most popular and well-known languages (C,C++,Java) and makes it into something appropriate for scripting. But with experience, I've found that Javascript really only borrowed the most trivial features of those languages, and forgot everything we learned about computer science in the last 20 years.

The most awful example is the concept of "undefined." Javascript is the only language I know of where it is legal to say:

if (MyObject.NonExistantVariable == 7)
{ // Do some work
}

(BTW: This expression returns false)

That is the source of most Javascript errors in a large project. A property was removed, a variable renamed, or misspelled, or never initialized. The value of the non-existant variable is "undefined" which is the bane of Javascript. There's even a special === operator for specifically comparing to undefined! And people thought NULL was bad!

It gets worse because Javascript is a glue language between other things like the HTML DOM or XML/SOAP/JSON so those object definitions can change at any time, and you won't know it broke your Javascript until you hit the right line of code in the right order.

Javascript is a language with totally dynamic typing and scoping. So it is impossible to compile, or type check. Even most scripty languages like PERL can detect more errors at load-time of the file than can be detected in Javascript.

Re:Javascript/HTML are the way of the past

[AKAImBatman (238306)]

I foresee API-based web development, and web pages/apps are done programatically, rather than as text markup.

You forgot to add "I have a dream!" in your one-liner.

Let me get out my crystal ball here... *clunk* *crash* *bang* sorry *oof* *whump* haven't *whim* *whim* *whim* used it *whack!* in awhile. So where was I? Ah yes. I am staring DEEP into the past. Looking at the days when UIs were programmatic. I see when UIs caused long lengths of repetitive and ugly code. I see resource files being invented! It's a miracle! UI programmers no longer have to keep their layout in their code! These resource files appear to be getting more complex... they are supporting graphical layout... productivity is improving!

Wait, what's this? Some silly person on Slashdot is attempting to derail the web form of resource files! He thinks that the DOM should be constructed... programmatically? Has he ever tried building a UI 100% programtically? It's a nightmare!

Levity aside, it can be done, but it's far from the ideal solution. New document formats like XUL may pop up, but suggesting that we move away from keeping layouts separate from our code simply smacks of inexperience.

"Those that fail to learn from history, are doomed to repeat it." - Winston Churchill

Re:

[betterunixthanunix (980855)]

Javascript works well when you have a program that writes half of the Javascript code for you. Try to write an AJAX application on your own, and see how far you get.

Java applets have an unfortunate reputation for taking a while to load, which is really the only reason they never took off.

Re:

[truthsearch (249536)]

I write all of my Javascript by hand, including AJAX. Just like my HTML. With libraries like mootools it's easy. And I'm referring to large, complicated sites that take many months to build. I've never found a program that generates JS for us that I've liked. And I don't see the need when good JS is easy to create when it's done right.

Re:End the web-apps

[Random BedHead Ed (602081)]

If you have a break-through network application that's going to change the world... GREAT! Write an actual program that will merely communicate over the net. Not some hacked together Javascript that just barely works on a good day, on the right version of the right browser, with all the settings done by your CTO.

Relying upon non-web network programs is what we've been doing for decades. The result is that people use inflexible proprietary software that locks them to their propriety desktop platforms, and those platforms (and we're not naming any names here) have stagnated for years, there being no real competition to drive innovation at the OS level.

The promise of these web apps is that it doesn't matter whether you buy a Thinkpad with Windows, a MacBook with OS X or an Asus netbook. In any case, online apps like Facebook and GMail work the same anywhere. It's not perfect, and you're right that there's a lot of entropy out there, but everyone can see by now that this is a move away from the Bad Old Days of "I need to be able to use Outlook and IE so I can't buy a Mac."