Slashdot Mirror
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.'"
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.
Comment of the year
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.
love is just extroverted narcissism
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?
Random and weird software I've written.
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.)
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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.
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."
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, 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.
My blog. Good stuff (when I remember to update it). Read it.
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.