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.'"
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...
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?
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.
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.
Javascript + Nintendo DSi = DSiCade
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
Javascript + Nintendo DSi = DSiCade
... 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.
Karma: Poor (Mostly affected by lame karma-joke sigs)
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.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
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.
Contrary to the popular belief, there indeed is no God.
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
Javascript isn't the problem, it does a great job. The problem is all of the presentation differences between browsers. Having to code for every nuance in every browser makes things difficult. Show me a standard that insures that all of the browsers (IE, Firefox, Opera, Safari, etc.) display the DOM the same way and that is what I will back.
...you have reinvented X11
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...
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.
Palm trees and 8
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."
Reason why users like web apps even though they kind of suck: can go from computer to computer and still get your stuff. Not limited to a particular OS or browser.
You mean we could - theoretically - use browsers for what they were meant for (browsing hypermedia) and NOT try to turn the browser into the all-in-one universal application delivery platform????
BRILLIANT!
I'd like to hear more about your ideas, please subscribe me to your newsletter.
// TODO: Insert Cool Sig
We are going down a fundamentally misguided path when we try to force those applications onto the web. That was my point.
Then what should we use instead of the web to instantly deploy these applications to end users?
Your argument is bullshit.
Ah, we're back at the playground. OK then: your argument is horse dookie. And you smell.
And, from the looks of your last line, your post is an anti-MS screed in disguise.
It isn't in disguise. And it isn't specific to MS. Reliance on these web apps is changing the market substantially. It just as easily means a Mac shop can tolerate a Vista box, whereas that was a harder sell in days past.
It's not specifically JavaScript that's the problem. The problem is thinking that one language will solve all application requirements.
What we need is a way to write applications for this (web) platform with any language you want/need... just like the desktop.
Ideally we'd first have a VM of sorts on the browser... Separate the language from the execution. This would allow people to use their language of choice, and to take advantage of existing languages in order to write web-based display applications. For example, if you look at all the display methods right now: JavaScript, Flash, Java applets, etc. They all have pros and cons to their underlying technologies and browser tie-ins, but they're all tied to the specific language... I may like Java's concept of having a VM/byte-code interpreter, but I'm stuck with doing everything in Java. For some tasks, that just may not be ideal.
Once you've got that separation, then you can do some interesting things and actually learn past lessons. This whole concept of networked computing, remote displays, and server-oriented applications is actually quite old. The primary thing that's changed in the past 20 years is that we have smarter terminals.
So the next step is to develop something like X11 (or perhaps just extend X11?), but take advantage of the fact that we have smart terminals. Allow for the widgets and toolkit stuff (eg. gtk, Qt, etc.) to be loadable onto the remote display. This would provide the benefit that we want... low network overhead and high user interactivity for applications.
This would also allow us to standardize on UI toolkits much more so than we do now with AJAX, et. al. But because the UI can now be standardized, they can also be cached. Once you download a toolkit, you don't need to download it again.
But at the same time if some developers don't like the toolkit, you could easily have others without having to re-write your entire infrastructure. (Think Xaw, Motif, GTK, Qt. If you think that's too many, try to count the number of display toolkits commonly used in today's web application space).
The other benefit this gives you is the ability to just write applications once. You'd actually be able to share code bases when trying to support applications on the desktop and on the web. And this would be no more work than supporting, say Windows and Mac.
So the mistake we actually have has developers (in my view) is not recognizing that the web is a platform just like any other platform. And that we should treat it as such.
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 ?
I'd imagine it would still pale in comparison to people who wouldn't have Brave New Browser.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
I'm with you, except that I lament that the only way to get the "boxes and springs" tabular model that has been used by pretty much every UI ever invented is to use tables for layout. Which gets you crucified by the web standards crowd. The options that CSS gives you are a sad joke in comparison: in CSS, even creating a layout of three divs in non-overlapping columns is an art. Don't even think about trying to give it rows!
Everyone who continuously complains about the inadequacy of the web browser needs to step back, and remember that it is designed to be crippled. If it were as fully functional as the desktop, any yahoo could come by and completely replace your desktop with something of their choosing. I don't need DHTML to watch movies and read the news. I need Firefox and some interlinked markup. Anything more than that is opening up the web to all sorts of attacks that don't need to happen. We don't need a better JavaScript. It would be nice for programmers, but less secure for users.
I don't think the author really understands what TBL's original vision was, except in the narrowest of contexts. The idea of code on demand was certainly described as part of REST.
The problem with JavaScript standardization arguably comes down to vendor politics (as do most standards efforts). We're in a wave of proprietary "innovations" being pushed, like MS Silverlight, Adobe AIR, Sun JavaFX, etc. It's not in these gorilla's interests to commoditize a richer browser experience before they try to take over a portion of the web on their own.
-Stu