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)
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 additions to the standard should have been the way to go.
The real Sig captains the Northwestern. This one captains
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.
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.
Palm trees and 8
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
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.
Palm trees and 8
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.
Developers: We can use your help.
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.
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
...you have reinvented X11
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.
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...
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.
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
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.
1. By Many you mean 1% of the total applications excluding games written. Most frameworks for applications are this. Take Input process data produce output. Step one takes time so there is no need to keep a connection there. step 2 - 3 is done on the server. After you get the data you don't need the connection until the next input. Your way will have the server get overloaded much quicker then with Web Apps as it needs to keep connections until they quit.
2. I have heard this argument before however I have NEVER in 10 years ever seen this to come across a situation where not relying solely on the server for security didn't work. The server controls what the client see and it also can filer or reject what the client asks. The only case I can think of preventing someone from printing your document... However this exists across all other apps where doing a screen shot and printing that works too.
3. Most of the bandwidth used is not text data but binary information like pictures which take the most time. 9.6kbs is 1k a second. normally an complex page is about 10k so that is 10 seconds. But wait most browsers will render the html before it is completely downloaded so you can read input before it completes. Secondly most mobile users who use this speed are on phones that aren't designed well for the web and not recommended to for use of most apps. The iPhones and other smartphones more suitable for wireless web use a faster connection.
4. The extra stuff will only take a fraction of a second.
Techniques such as AJAX actually improve speed as it allows the server to handle smaller chunks and send it smaller chunks using the clients PC (which normally has a LOT of CPU Free to do most of the work) Covering the gap you mentioned in 1.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
What is with this strange new breed of programmer who thinks that everything should be crammed into the MVC pattern?
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.
You feel sleepy. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise.
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."
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.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
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.
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.
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.
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).
Comment removed based on user account deletion
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.
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.
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.
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