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:1, Interesting)
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
Firefox is a good OS. All it needs is a decent web browser.
Re:Got it wrong (Score:5, Interesting)
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 (Score:3, Interesting)
No ActionScript is great! Really! (Score:2, Interesting)
An external browser module capable of executing most of the proposed ECMAScript 4 specification already exists: It's the Adobe Flash plug-in. Other platforms are available as plug-ins, as well, including Curl and REBOL.
As Web developers, we tend to shy away from these alternatives, but only because of the never-ending efforts to refine and standardize JavaScript within the browser itself.
Paid shill maybe? Sounds to me like Adobe is trying to persuade the public that "their" Flash ActionScript [slashdot.org] additions to the standard should have been the way to go.
Re:Java (Score:3, Interesting)
Java applets have an unfortunate reputation for taking a while to load, which is really the only reason they never took off.
Re:Java (Score:3, Interesting)
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.
I would think... (Score:3, Interesting)
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.
Re:No scripting language is going to solve (Score:3, Interesting)
It's for scripting, silly! (Score:3, Interesting)
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.
In this case, the real question: is ECMA a mistake (Score:5, Interesting)
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.
Re:Reasons why browsers are poor application runti (Score:5, Interesting)
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.
MVC? Again? (Score:2, Interesting)
Sensibilities be damned, they're going to make it work like Ruby-On-Rails if it kills them. Why not look at the requirement and then decide on an established design pattern (if any!)? Don't go trying to change a language we're all very happy with just because your knowledge is limited to one paradigm.
We should going back to designing things that work, not working things to a design.
Javascript (well, ECMAScript) is actually quite powerful. True it lacks a few of the features you'd expect to see on common UI languages (multhreading anybody?), but you can't have a strop and fragment ECMAScript because of that.
It is, by the way, a prototype-based language, so the sooner you stop deluding yourselves into thinking that you can code like it's OO, the better.
If you want to complain about something, whine about the totally fucking USELESS Document Object Model (DOM) we're given to work with today, talk about the weakest link... If there's ANYTHING that needs a total overhaul on the web today, its the DOM.
Re:No scripting language is going to solve (Score:2, Interesting)
I wholeheartedly agree. Web applications are just abusing the browser forcing them to do what they aren't supposed to. They are very inefficient (the browser is the heaviest application I run) and they have all sort of hacks to overcome the fact that HTTP and HTML were meant for simple stuff. Instead of doing dirty hacks we could do one of the two:
1) require a separate client for every networked application (should be more a efficient from a technical point of view)
2) improve the protocols and languages to natively (and uniformly) support asynchronous requests and just drop the concept of "page" altogether as it doesn't mean too much anymore.
Re:Why use Javascript at all? (Score:3, Interesting)
True, and I agree, but have you seen what crazy people are doing these days?
Take a real hard look at SproutCore. The basic concept is to write code in a Ruby-like template lanaguage which, when compiled/built generates a bunch of HTML. Then you write the actual application logic using Javascript. The back-end server piece is relegated to little more than a way to pull stuff out of and insert changes into a database (along with a thin security layer to prevent people from doing bad things).
The whole REST model more or less relies on a "thick" client doing all the logic. And these crazy people are doing all that with Javascript, basically. Which is fine from a pretty aspect, but verges on insanity for any sort of serious application.
Re:Got it wrong (Score:2, Interesting)
We have standards for the low/average JavaScript application and, amazingly, they're followed in all popular browsers (IE6+, Safari, Opera, FF2+) but there are still some nice things that are missing and are required for the most powerful applications - see GMail and Google Docs.
Re:No scripting language is going to solve (Score:3, Interesting)
If you really need all that, you can have it right now: just make a web page that contain nothing but a Java applet that connects back to your server. See http://www.mudmagic.com/java-client/ [mudmagic.com] for example.
That few people bother doing this implies to me that it isn't, in fact, widely needed.
Re:Got it wrong (Score:3, Interesting)
You've just described why I have a deep-seated hate for frameworks. If these frameworks really wanted to help, they'd focus only on APIs that make sense. But don't cram me into your idea of how Javascript APIs should look. The DOM/Javascript APIs exist for a reason, and most are quite good. Until the rest of the industry gets with the program, I'll roll my own toolkit-independent widgets.
As for Silverlight, you don't have compatibility problems now. But just wait a little bit. Microsoft is famous for incompatibly changing APIs from version to version. It happened with Access VBA from 97->2000, it happened to .NET, it happened with VB6->VB.NET, it happens with every version of Windows. Betting on anything Microsoft is a good way to find a stake through your back once you outlive your usefulness to them.
Re:Got it wrong (Score:3, Interesting)
I like the way that the Head First Design Patterns poster explains this with the "Zen of Patterns" section:
The Beginner Mind:
The beginner uses patterns everywhere. This is good: the beginner gets lots of experience with, and practice using patterns. The beginner also thinks, "The more patterns I use, the better the design." The beginner will learn that this is not so, that all designs should be as simple as possible. Complexity and patterns should only be used where they are needed for practical extensibility.
The Intermediate Mind:
As learning progresses, the intermediate mind starts to see where patterns are needed and where they aren't. The intermediate mind still tries to fit too many square patterns into round holes, but also begins to see that patterns can be adapted to fit situations where the canonical pattern doesn't fit.
The Zen Mind:
The Zen mind is able to see patterns where they fit naturally. The Zen mind is not obsessed with using patterns; rather, it looks for simple solutions that best solve the problem. The Zen mind thinks in terms of the object principles and their trade-offs. When a need for a pattern naturally arises, the Zen mind applies it, knowing well that it may require adaptation. The Zen mind also sees relationships to similar patterns and understands the subtleties of differences in the intent of related patterns. The Zen mind is also a beginner mind, it doesn't let all that pattern knowledge overly influence design decisions.
Re:Got it wrong (Score:3, Interesting)
Even when IE6 is using a cached version of the HTML? In my experiance, IE6 doesn't fire that event when the HTML is cached. It is hard to spot this bug because as a developer, you usually refresh the page to reload the javascript.
Re:No scripting language is going to solve (Score:2, Interesting)
To me, the ideal solution would be to take what we have now and reinvent it. HTML forms need much more rich controls. Javascript has a lot of rough edges; we really need a clean scripting language and a full development language that inter-operate. Of course, that will never happen. Meanwhile, I'm noticing how much Swing has improved and the possibilities of JNLP...
Re:Got it wrong (Score:3, Interesting)
Firefox 3 doesn't break your code because of an API change. It's based on web standards that remain frozen once implemented. Prototype 1.5 -> 1.6 will change like you mentioned, but you have just as much control there. In fact, you have MORE control because you're not at the whim of the plugin/browser maker to continue supporting the old plugin. One fellow I was talking to here on Slashdot actually kept a separate copy of APIs like prototype for each module. He simply didn't upgrade them unless there was a clear and solid need to do so.
I can't say I agree with such a draconian approach, but there's nothing inherent in web development that causes the problems you describe. If anything, web development is less susceptible to upgrade problems. Unless, of course, you're still doing browser version checking? (In which case it's your own damn fault.) PLEASE tell me you're doing feature checking instead?
Javascript language concepts (Score:5, Interesting)
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.
Now that you got that figured out...extra credit. (Score:3, Interesting)
Talk to someone who knows the inside story and can tell you (because you work for the same company and can discuss what happens at W3C) what happened to the DOM committee and vigorous efforts to add modules, cleanup, or take other actions to solve precisely those deficiencies at W3C.
Hint. For the sake of argument, assume Microsoft owns W3C control to some extend the same way they own ECMA (now obviously after .net, OOXML, and Javascript subversive actions).
Buying multiple machines; getting code signed (Score:3, Interesting)
We have networked window systems for people who don't own their own computers.
Which such window system is widely deployed in both homes and businesses as of 2008?
Writing a portable native app is no harder than writing a portable web app
Citation needed. The developer needs to own and maintain at least one machine of each architecture and operating system to compile and test on, which can get prohibitively expensive for hobbyists and small businesses. In particular, this would mean that a developer who had previously tested web apps in Safari for Windows would have to buy a Mac to reach Mac users. Worse, on several platforms such as Wii with Internet Channel, PSP, PLAYSTATION 3, and iPhone/iPod Touch, DHTML apps will run just fine, but native apps need to be digitally signed by the platform vendor or the operating system will refuse to run them.
Re:Got it wrong (Score:2, Interesting)
If you want standardized layouts, there are much lighter weight solutions than PHP. Server Side Includes have been around for ages and will do just that. You shouldn't be calling the PHP interpreter just to have common headers and footers.
PHP started out as a templating framework and evolved into a language. It also manages to do lots of little things just a little bit differently than every other language on Earth, making it hard to really learn. Throw in some dubious design decisions (no namespaces? WTF?) and you've got something that's really just a mess.
PHP should never have been extended to do real work. It's fantastic for really simple things, but once you add in much complexity, it's the wrong tool for the job.
Re:Reasons why browsers are poor application runti (Score:3, Interesting)
You don't HAVE to use XML for RPC requests. Heck, the XmlHttpRequest object doesn't even force you to use XML.
JSON is a much more concise RPC vehicle.
Further, HTTP isn't SUCH a bad RPC protocol. It's remarkably light-weight. HTTP Headers can be a little as 2 lines of text. And a lot of RPC functionality that doesn't involve sending or receiving much data (for example, marking a message as Read in Gmail) you can use a simple HEAD request instead of GET or POST and use the HTTP Status code to determine success/failure in your browser.
A binary protocol would be faster. No doubt about it. But if a dev understands HTTP and uses JSON, it can be pretty speedy.
Re:Got it wrong (Score:3, Interesting)
You may be right, but you got the wrong examples.
I don't know CodeIgniter, so I can't comment on it.
PHPMyAdmin is an useful app, but if you ever used MSSQl admin tools, you'd know it doesn't come anywhere near.
As for OSCommerce... LOL. Have you looked at the code? It's the very definition of dirty.
Re:Javascript language concepts (Score:3, Interesting)
Followup note: the reason why this is a big deal is that there is actually an unexamined problem in the whole definition of OO, in that *functions need to be objects in their own right* and they currently aren't - even prototype OO still has two fundamental entities, 'objects' and 'functions'. So many OO languages just don't grasp the concept that you could assign functions as values to slots at runtime. Prototype OO with functional features does, but it only takes that concept so far. There's still a lot of manual 'glue code' needed to build a GUI; ideally, you should be able to describe a set of widgets and bound events purely as a data structure and let the system figure out what if any 'code' needs to be generated. Dataflow engines like Flapjax are taking the next step in that direction; there's still a few more needed to completely close the loop and get to a really humane programming environment.
But that's a story for another day.