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.'"
Got it wrong (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
It's just that no one has come up with a better language.
No one has been able to come up with a better language than javascript? That's a scary thought.
Re:Got it wrong (Score:5, Insightful)
All javascript really needs is to be well supported in all browser and that people would stop thinking about it as just a script kiddie tool. Javascript is perfect for what it was intended to do and it's very good even for what it wasn't exactly intended to do and THAT's why there hasn't been a "better" language yet, because this one is good enough for the job. Frankly, outside of becoming standardised all over, I don't see what more you might want in javascript that you absolutely cannot live without.
Re:Got it wrong (Score:5, Informative)
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.
Re:Got it wrong (Score:5, Funny)
Re:Got it wrong (Score:5, Informative)
jQuery's [jquery.com] $().ready( function() {...} ); method has been a fantastic help in my Javascript development. It executes after the DOM has been initialized, but before all of the images have been loaded. window.onload() waits for the images to load, which delays your javascript from running until after the page has been rendered. jQuery doesn't do that; your code will often run before the page is rendered, so you can use javascript to enhance/replace elements that work without javascript too. For example, I often have UI controls which will refresh the entire page to perform their function when javascript is not enabled, but they'll use AJAX and refresh only the necessary elements if javascript is enabled. Using jQuery, I can attach events and alter CSS classes before the user sees the page, so javascript and non-javascript users get somewhat different looking, somewhat different behaving, but always fully functional views of my application.
Re:Got it wrong (Score:5, Insightful)
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.
Re:Got it wrong (Score:5, Informative)
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.
Re:Got it wrong (Score:5, Informative)
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!
Re:Got it wrong (Score:5, Insightful)
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 [go-mono.com], 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.
Re: (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 incomp
Re: (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 Sla
Re:Got it wrong (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
if the problem is that we have too many different javascript libraries, what are you going to get when you try applying the original post's solution of using multiple languages? an even bigger mess.
given that a lot of the work that these libraries have to do now is to cover for the fact that browsers haven't even really standardized on the same javascript language, the idea that there is some hope of having multiple languages fully supported across all browsers is laughable
Re: (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: (Score:3, Informative)
Defer only works in IE. Firefox doesn't support it, and I'm pretty sure Safari doesn't support it either.
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
Leaving the language itself aside, the big problem I see when reading javascript is all these tests to check on what browser it is running. If I write code, I don't wan't that mess (Luckily, I I'm not a web developer).
Re:Got it wrong (Score:4, Informative)
In modern Javascript usage you leave that to a framework library such as Prototype, mooTools, jQuery, Dojo etc.
Re: (Score:3, Insightful)
Some browsers include newlines in the DOM, some don't. If you
Re:Got it wrong (Score:5, Insightful)
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?
Re:Got it wrong (Score:4, Informative)
PHPMyAdmin, OSCommerce, CodeIgniter... yep. Just quick and dirty hacks. Come on, lay off the generalizations.
PHP doesn't make crappy code, coders do. The same could be said (and has been said) about Perl, but it doesn't make it true.
Re: (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: (Score:3, Funny)
Re: (Score:2)
One of the biggest issues I've had with it is the poor performance (relative to what it's being asked to do) in the current browser engines. The good news is the current advances (e.g. WebKit) give me great hope.
Re: (Score:3, Insightful)
One of the biggest issues I've had with it is the poor performance (relative to what it's being asked to do) in the current browser engines.
One thing I learned to avoid is big iterations. Keeping your loop as short, efficient and preferably absent as possible has a surprisingly big impact on javascript performance.
Re: (Score:3, Insightful)
Well, if you're going to standardize the object model, how much of a larger step would it be to define a virtual machine to go along with it? Then you could use any language you like, provided that it could be compiled for the VM.
It's funny that this wasn't the way things went, because that certainly works for many developers who don't want to share code, aside from the other things that would make this convenient. On the flip side, it's probably done a lot to encourage open source web UI frameworks, so i
Re: (Score:3, Funny)
But guess what, that's how PHP started out and look where it came.
To set that bar any lower, you'd need a spade.
Re: (Score:3, Insightful)
Javascript is an amazing language. The C-like syntax gets in the way occasionally, but all-in-all it's up there with the best of them.
The problem is that most people do not even realize that it is an object oriented language, let alone containing functional language features as well.
Re: (Score:3, Insightful)
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: (Score:2)
I brought this up a while back when there was an article about how Microsoft was abandoning javascript in favor of something else for use in the next
Re:Got it wrong (Score:5, Informative)
Start at the source:
http://developer.mozilla.org/en/Core_JavaScript_1.5_Guide [mozilla.org]
That document may be nearly 15 years old (plus/minus revisions along the way), but it's still the definitive method of learning Javascript.
For those who actually take the time to read it, that is.
Good luck! :-)
Re:Got it wrong (Score:4, Informative)
Yep. Also the Microsoft reference on "JScript" is pretty good.
http://msdn.microsoft.com/en-us/library/4yyeyb0a(VS.85).aspx [microsoft.com]
Re: (Score:3, Informative)
There are step-through debuggers like FireBug, but I've never felt the need to use one. You may find such a debugger more interesting, though. :-)
Dont listen to this man. He knows not what he speaks of. FireBug is teh awesome! For one thing, it will keep a nicely parced log of all your HTTP requests to make AJAX debugging easy. For another, it is just awesome.
But yeah... I've never used much of it's step-by-step debugger. For some reason, I've never found the need--could be because javascript stack traces can be a little wonky with anonymous functions. And probably because most of the reasons *to* debug something are because of IE6 being retard
Re:Got it wrong (Score:4, Funny)
Well, I don't know about anyone else, but I'm convinced. Your enthusiastic use of the word "WRONG!" has totally won me over. The fact that you only offered the weakest of excuses for your anti-Javascript bias does not matter. You yelled "WRONG!" louder than your opponent. Therefore you have convinced me.
Truly a masterful stroke.
Re: (Score:3, Interesting)
Re: (Score:3, Insightful)
>> 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?
The best language does not always gain mindshare.
Re:Got it wrong (Score:5, Insightful)
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.
Re:Got it wrong (Score:5, Insightful)
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.)
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).
Re: (Score:2)
ActionScript3.0 anyone? As client side languages goes it's pretty solid. Fully object oriented and ECMA compliant.
If anyone hasn't used flash for a while, it's a whole other beast now. It's not an animation package with a scripting language slotted into the side any more.
Re:Got it wrong (Score:5, Insightful)
ActionScript 3.0 == ECMAScript 4.0
Re:Got it wrong (Score:5, Insightful)
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.
Re: (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 extensibili
Re: (Score:3)
Here's another one for you: The HTML DOM is the view, the Browser is the Controller, the Model is implemented in Javascript, and the server would be a source of data.
No scripting language is going to solve (Score:4, Insightful)
... 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.
Re:No scripting language is going to solve (Score:5, Insightful)
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.
Reasons why browsers are poor application runtimes (Score:5, Informative)
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.
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.
The 1990s called and offered you a job. (Score:3, Informative)
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
Re: (Score:3, Informative)
Well...
* Most applications we need to store information to be commonly shared.
* Giving people access to install and update apps is stupid.
* Having an IT Staff update every clients app for every small (but critical) change is expensive and time consuming.
* Having multiple apps point to the same file is a BAD idea.
* Syncing multible files can be troublesome,
* Making sure the binary file is secure is much more difficult (text based passwords embedded in executables, names of servers/odbc even particular SQL ca
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 succes
Re:Reasons why browsers are poor application runti (Score:5, Insightful)
Re: (Score:3, Insightful)
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?
Re:No scripting language is going to solve (Score:5, Insightful)
Newsflash! We don't.
Flash was never welcome on the web. It was responsible for some of the most horrific, unusable sites known to man. For the most part it has disappeared from common UI use. However, it did manage to find two major niches:
1. A standard for Web Video (because no one can friggin' agree on a standard)
2. Online Games
#1 may eventually be taken care of by the new HTML5 <video> tag. Unfortunately, the powers that be still can't agree.
#2 *is* taken care of. Javascript games already exist:
PentriiX Online Multiplayer [wiicade.com]
DHTML Lemmings [elizium.nu]
Hull Breach Online [hullbreachonline.com]
Tetris using Canvas [dnsalias.com]
Pac Man using Canvas [youtube.com]
XUL is a Mozilla technology primarily used to construct Mozilla apps. It is not a web language per se.
Air and Silverlight are solutions looking for problems. The latter is supposed to be a Flash killer at a time when Flash is already at the end of its life. Smooth move, Microsoft.
XBAP is effectively the heavy-weight daddy of Silverlight. Except that it's not really a web app.
So what you're saying is, the sooner we shut down GMail, Yahoo! Mail, Google Docs, Google Maps, Digg, Meebo, and every other DHTML app in existence, the better off we'll be*?
* Ok, maybe in the case of Digg we would be, but that's the exception that proves the rule!
Re: (Score:2)
I agree, I think it's time for HTML5 to be the last web page spec then move on to the next thing.
We need and application framework. It has to break fundamental features of the HTTP/HTML model. It has to be authenticated at OSI session level that fixes huge problems trying to work around statelessness. It has to have something OBDC-like built in to handle data transfers. It can still keep XHTML markup, but streamline it for "moving" apps. It would look a lot like remote X sessions. It would be subject to
Re: (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:If your customers can't install the Java player (Score:4, Insightful)
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.
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Ever heard of this little thing called "native applications running on your computer"? It works much better than a browser.
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
Re: (Score:3, Funny)
Java Web Start!
Re: (Score:3, Interesting)
Re: (Score:3, Insightful)
The point of TCP/IP was to keep the military running when the commies nuked our ass to hell. Where does this 'HTTP' fit in with that?
Re: (Score:3, Informative)
Bruce disagrees [schneier.com]
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
Re: (Score:3, Informative)
You should learn your history... ActionScript 3 was actually based off of an early proposal for "JavaScript 2", written by Mozilla (or maybe it was Netscape at the time.
The goal was for it to be standards-compliant with the next major revision to JavaScript.
Adobe AIR does this (Score:2)
AIR lets you pick your language... it is practically a browser replacement using WebKit as it's html/dom render engine which lets you script however you like.... well, it supports javascript, actionscript and can be extended [onflex.org] to allow for coding in C/C++ and all the other languages that sit on top:
Java, Python, Ruby, PHP, Lua, Perl, C# (Mono), JavaScript
XMLHttpRequest aught to be enough for anyone (Score:5, Insightful)
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.
Better than other "standards" (Score:2)
Some things are standards by default. Like Microsoft Word format. So by comparison Javascript doesn't look so bad.
lol wut (Score:3, Insightful)
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.
When the student is ready the master will appear ? (Score:2)
The web was invented right, HTML for documents, HTML forms for simple data entry and APPLETS/OBJECT for complex and "rich" content
The problem is that not all developers look for the right tool for the job, they have a screwdriver and think how to adapt it to a wrench
Of course the correct solution is to use the right tool, but, hey, this means learning something new !
Having javascript doing what java/C# does is just reinventing the wheel, it can be done, someone will even be happy to slam Java once again but
Bypass the eBrochure Model (Score:2)
The HTML browser model is currently an eBrochure model. If one wants to create CRUD screens (business forms and grids), you have to make the eBrochure model bend over backward to achieve it. To allow a more desk-top like feel, the widgets and screen need to be more state-ful. That is, if you issue the command "draw screen X", screen-X will stay there until you tell it to close screen X. (For security-related isolation, an MDI model can be used.)
Further, we need a GUI interface language/standard that is more
What is "Model-View-Controller" (MVC) (Score:2)
I recommend skimming through Martin Fowlers excellent description [martinfowler.com].
You can also get additional links to PHP,
If you have never heard about it (and many of you haven't), you are missing out on a great design pattern.
- Jesper
MVCVC (Score:2)
"Let the browser handle the View. Let the Controller exist somewhere else, independent of the presentation layer.'"
Has the author ever actually developed a web app? Javascript may be doing things like fetching data and sorting lists, but I have never seen a real application that had sufficient non-display javascript to justify splitting it into a MVC pattern. Despite the fact that we have heavyweight JS frameworks like JQuery and mootools, those are still spending their time rendering the view.
Since when is javascript only one language? (Score:5, Insightful)
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
Short Answer (Score:2)
End the web-apps (Score:2)
I have a better idea. Give up the "web app" mentality all together.
When you need to access your e-mail, load up an MTA. It works an order of magnitude faster, without maxing out your CPU to display a message. It requires an infinitesimal amount of bandwidth, and allows you to read and respond to e-mails even when you're nowhere near an internet connection.
When I'm looking at several items, and want them sorted by popularity, I REALLY DON'T NEED to see an animated status bar show up to tell me that the pa
Re:End the web-apps (Score:5, Insightful)
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."
Re: (Score:3, Insightful)
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.
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.
When it's all said and done... (Score:4, Insightful)
...you have reinvented X11
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.
Plugins get a bad rap. (Score:3, Insightful)
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...
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.
What a novel idea... (Score:3, Insightful)
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.
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.
Re: (Score:3, Informative)
http://www.linuxtopia.org/Perl_Programming/pickingUpPerl_29.html [linuxtopia.org]
Re: (Score:3, Informative)
The most awful example is the concept of "undefined." Javascript is the only language I know of where it is legal to say:
Perl will let you do that, although the warnings pragma will remind you "Use of uninitialized value in numeric eq (==)". But in Perl, you test whether or not something is defined with defined(), or whether a hash key exists with exists(), so you don't need a crazy === operator.
Re: (Score:3, Informative)
"I will also add, that I don't like prototyping as a concept and prefer OO over it. "
Huh? That makes no sense. Prototyping *is* OO. What it is not is *class-based* OO. It's in fact a much more flexible and natural way of doing OO and allows for better modelling of real-world situations.
The point of prototype-based OO is that you don't have two separate entities for 'class' and 'object': you only have one, and then you have the 'prototype' relation which is runtime-assignable to implement inheritance. Logica
Re: (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 o
One problem: Security (Score:3, Insightful)
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.
Moving from its original vision? (Score:3, Insightful)
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 [uci.edu] 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.
Re:Javascript/HTML are the way of the past (Score:5, Insightful)
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
Re: (Score:3, Insightful)
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 [incutio.com] is an art. Don't even think about trying to give it rows!
Re: (Score:2)
Re: (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: (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.
Re: (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 mod