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 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
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
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.
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.)
Any spec without ponies is a defective spec indeed.
Benford's Corollary to Clarke's Law: "Any technology distinguishable from magic is insufficiently advanced."
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.
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.
Liberty you never use is liberty you lose.
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."
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.
Javascript + Nintendo DSi = DSiCade
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!
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.