Slashdot Mirror
MS, Mozilla Clashing Over JavaScript Update
jfruhlinger writes "JavaScript has become a crucial part of Websites built on AJAX underpinnings, which makes the upcoming revision to the ECMAScript standard crucial for the future of the Web. But in today's browser environment, no one vendor can impose an update path — which may set things up for a nasty conflict. A fight is being fought on blogs between Mozilla Chief Technology Officer (and creator of JavaScript) Brendan Eich, who wants to the new ECMAScript standard to be a radical upgrade, and Chris Wilson, architect of MS's IE team, who would rather keep JavaScript as is and put new functionality into a brand-new language."
But they got along so nicely the last time Microsoft invited the Mozilla Developers over for a trip to the factory!
Oh, I hope this doesn't sour their play time together!
Maybe this is a naive question, but why isn't a third-party standards organization leading the way on this? I know that W3C didn't do a great job standardizing HTML (as any web developer who has spent hours debugging IE vs Mozilla can attest), but ANY standard is better than no standard here. Where's NIST or ANSI? I hate to even suggest that the US government get involved, but setting some kind of standard could avoid another Blu-Ray vs. HD DVD wasteful standard war that hurts consumers and developers. Everyone would be better off if this conflict could be avoided entirely. What would it take?
It seems they could both radically improve javascript and add in support for additional scripting languages. It would come at the price of increasing the size of the browsers, but that seems a small price to pay for the increased flexibility for developers.
Yeah, design by commitee always works out so well! Seriously, third party standards bodies are only good at post-facto. Don't rely on them to innovate. I say IE and Mozilla battle it out, release the product, and may the best man win. Once a winner is reasonably clear, then the standards bodies can get in and write it in stone.
agree on using and implementing the same HTML and CSS standards. What? Never in a million years? OK, there's your answer for fixing/replacing JavaScript.
We're all hypocrites. We all have hidden parts, it's the contrast between them that make us more a hypocrite than others
I know you're joking around, but if you really think Javascript is the problem, then just disable it. Much more effective than a popup blocker.
Thank God for evolution.
Opera's Haarvard suggests that it's about Silverlight, and Microsoft trying to close the web. Mozilla, Opera and others are pushing to extend open web technologies, but Microsoft is saying, wait, the web doesn't need to be extended at all! Well, except with Silverlight and WPF...
If they're serious about turning the browser into an application platform, there needs to be a multithreaded language with full DOM access, whether that is Javascript or something else. An application where the UI stalls the processing or the other way around is just not acceptable. Since Javascript multithreading has been rejected before, because it's supposedly too difficult for the typical script author, I suspect that Microsoft may have the right instinct here to go with a separate language for "pros", keeping Javascript simple for things like mouse rollovers and other eye candy.
ECMA International is a group that writes standards.
By the time that a good chunk of all browsers actually support ECMA 4, it's going to be a "nice to have" feature that nobody's going to be too keen on.
The road forward, in true hacker fashion, is probably to write translators so that part of your PHP, Ruby, Perl, Java, or C# code magically runs on the client, treating ECMA 3 as a vague intermediate language.
ECMA 3 can be the x86 assembly language of teh intarweb. No CPU actually executes real x86 instructions anymore, they translate it into internal RISC/VLIW-ish operations. Very few programmers write much of any raw x86 instructions anymore.
Of course, this may or may not be handy for the other ECMAScript implementations like LiveScript.
Gentoo Sucks
Avoid the two big warring parties that are too big to get anything right, strip down your runtime and spend more time being less concerned with government or browsers. Opera is the Ron Paul of browsers in that it seems a lot of us use it online, but you never see mention of it in the "real world," and this article is part of that trend. Why?
technical writing / development
There needs to be a third pary arbitrator here.
And hopefully that arbitrator tells them all to just STFU up and use python
NewslilySocial News. No lolcats allowed.
As a user, I really couldn't care less which way it goes.
Just don't break things that work now!
As a developer, I really don't care, either.
Just don't break things that work now!
Honestly, if we're going to have a new version that's significantly different and "updated," just fork: Keep the original code that works well as one version and then rewrite it as the basis for the new one. The first thing that comes to my mind is KDE4: It's a hell of an idea, but I think they'd best keep 3.5.* around until they're done with 4.0.
In short, give people a choice: Let me choose if I want to write for the stable venerable base or the new pretty whizbang version.
For the most part, standards organizations don't lead all that much, they, at best, referee, and their decisions are typically preceded by just this kind of jockeying by interested parties.
There is a reason the standardized language is called ECMAScript, and not NISTScript or ANSIScript.
OK, maybe I'm missing the point here but AFAICS no-one's arguing against the new draft; instead, the argument about whether you accept the new syntax inside tags or not. One side says yes, other says we should keep that for older JS and put the new stuff inside tags or similar so we can tell ahead of time which one we're supposed to be dealing with and make sure we don't break existing web code.
I don't see anything about closing the web or stomping on the little guy or anything like that. Where's that coming from?
I would say start a new Language. If they *upgrade* JS how well will it support older browsers. I am not talking IE 5 or anything, but say mobile phone browsers etc? If developers start creating new web pages with the new version of JavaScript are people going to have to upgrade everything? I think it would be better to start a new language so developers can support both. Have a JavaScript page and a XYZNewLanguage page. Sort of like how they have a Flash and a non flash page. So gradually they can phase out JavaScript in replace of a new better language.
I smoked pot once. But I DID NOT inhale. Will you hire me?
For once, someone at Microsoft gets the deal right. They should leave javascript as-is, and improvise XUL or whatever is the new buzzword. Tacking on updates to existing standards only creates ugly security loopholes, and all sort of weird hacks. Why, in the name of the lord, can't people learn from the mistakes that others have made?
Microsoft: "You've got questions. We've got dancing paperclips."
I know it's somewhat indicative of a tinfoil hat, but that's basically what I and many others do, using NoScript.
If I trust the website enough to run javascript, then I add it to my whitelist. I don't see the need for javascript on most of the pages I go to, and would rather not have my computer running unnecessary code. Seems to my totally uneducated POV that it'd slow my computer down if I have 20 tabs each running javascript stuff, when only 2 of them ACTUALLY need it. My RAM is precious to me. =(
And the languages won't win either. Javascript will stall at its currently supported version as people strive for cross-compatibility.
[ think ]
I've actually had dreams about all the major browsers coming to an agreement about consistent standards with HTML, CSS and Javascript. I have actually had dreams about designing an elaborate webpage layout for Firefox and then having it turn out perfect when it came time to load it in IE. But then I woke up and went about another busy day of using tables and NOT divs for webpage layouts...
*sigh*
/* No Comment */
The catch is that in order to take advantage of the new language features, developers will potentially have to do twice as much work. Already JavaScript's event model varies between browsers. In my ideal world there'd be a single language and all modern browsers would support it fully.
That's what's already happening. Even if a standard is published it's usually ignored. The problem is that Microsoft now has the huge majority and can do pretty much whatever they want. If my web app breaks when the next IE comes out you better believe the site will be made compatible, whether I like it or not.
So your plan for winner-take-all is nice in theory, so long as you don't complain when Microsoft wins because they can muscle their way into a de-facto standard.
Oh, fa! I hope not. Microsoft's idea of innovating is to take what someone else has done and make it incompatible, or write their own stuff and ram it down our throats.
Making stuff work on more than one browser platform can be a pain in the ass enough as it is. For once, I wish they could set out goals in advance. Of course, I'd be naive to believe that would actually ever happen.
Unfortunately, Microsoft also has the goal of entrenching their stuff as a 'standard' and only people willing to pay them money will be able to play. They have the industry's worst case of NIH that has ever existed. They're sure as hell not going to implement improvements to Javascript that are being pushed by someone from Mozilla. They're certainly not going to choose an implementation that Mozilla can do for free; they're simply incapable of doing *that*.
If it hadn't been for the fact that HTML was already in use before they came along to the browser market, I'm sure they'd have long since put forth their own version of it.
Cheers
Lost at C:>. Found at C.
Wanting to create a new language instead of supporting an upgraded JavaScript shows one thing, how bad the IE codebase for JavaScript handling might be. This majorly smells like those situations where after a long update and extension period a code becomes so hard to handle that it's better to drop the whole thing and start a rewrite from scratch. Of course, if you argue for a new language, this probbably isn't such a big issue, since you'd need to write a new handler code for that anyway, and nobody will know what your reasons were.
Of course this is all just speculation. Wouldn't be the first time I'd be wrong, still, the smell is really strong.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
Well that's what GWT, OpenLazlo et al do already anyway. The thing is you can't get all the features of the underlying language that way. The key is to making the source language so much better than Javascript that my complaint sounds like saying "the problem with C++ is that you can't get all the features of assembly." (And I mean within the source language, not with things like asm blocks.)
Personally I like Javascript as a language and think it's a shame to see roadblocks to it's development happen because of the nature of the platform it usually runs on. I'd like to see something like GWT where the source language is Javascript instead of Java - that is a Javascript to Javascript compiler where you could add whatever local features you need and have the compiler throw away the fluff and stick in cross-browser compatible shims.
more of the same on Twitter.
Huh, I hadn't realized that NoScript has a whitelist feature. That sounds like a good approach actually. Obviously I want Javascript working on a place like GMail, but I don't need accordian boxes everywhere, much less the insidious popups. Thanks!
Thank God for evolution.
The trouble is, Microsoft has a point. Original HTML, up to, say HTML 3.1, was limited but a reasonable design. Most of the attempts to extend past that point have been disappointing. CSS is a collection of attributes in search of an architecture. Page layout with "float" and "clear" is too limited and doesn't work well. (The "three column problem" is well known, and workarounds using layers or absolute positioning often result in text on top of other text.) Javascript is a mediocre language. (Could have been worse; see TCL.) That's the current mess.
Papering over the problem with a layer of "toolkits" just resulted in a proliferation of incompatible toolkit layers. That wasn't the solution.
But Microsoft will try to "fix" the problem with a closed, ambiguous system that requires frequent updates. That's what they do with everything else.
I don't see a good way out of this. Who can provide leadership? Adobe? They can't even make Dreamweaver work right any more.
Browser compatibility of those javascript(s) and jscript is a nightmare.
There is a spark in every single flame bait point.
Wilson wrote that the proposed new standard may result in complications and incompatibilities with existing Web sites and applications.
So, it works the same as always then? Everything seems normal with the new standard.
What I want to see is a giant red T-Rex fighting a massive four-colour Butterfly...with the T-Rex stomping the Butterfly, completely altering the future.
He who knows best knows how little he knows. - Thomas Jefferson
You wanted to be funny, but I do agree with you somewhat. Javascript adds unnecessary size to a lot of web pages. Why, for example, is it necessary to use javascript to cause the browser to follow a link? Or to refresh a page? I haven't seen many particularly novel web sites that actually justify the amount of javascript that is out there. I should be able to browse the web on a 9.6K connection without waiting 5 minutes for 100kb of javascript to load for less than 10kb of content.
Palm trees and 8
Lets call it C# or linq instead of java and xsl2 just so we can force our own standard upon everyone.
thank God the internet isn't a human right.
Microsoft are right IMHO, JavaScript is a horrible language in many ways which are well known. I would much rather see a more modern language designed from scratch designed for the future of the web rather than hack in new features to JavaScript beyond the scope it was originally designed for. We also need better development environments for JavaScript as debugging it can be a royal PITA, while Firefox + extensions help it isn't perfect, a proper debugger would be great :)
So I can't see MS having anything to do with it, unless there's some convoluted plotting going on.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
Javascript is intentionally designed to be less functional than any of the languages you've mentioned, and with good reason...A client side language with the sort of feature set that perl or ruby or python has would be death on a plate in the context of a modern web browser; you'd go to a webpage and it wouldn't just slip you a trojan--it'd reinstall your OS.
Client side languages need to be concerned purely with the cosmetics of the interface. Any single step beyond that opens up some extremely scary security concerns.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
As usual, Microsoft is attempting to wipe out an existing standard in favor of some new bastardized monster which it will control. Everyone will have to play catchup to Microsoft's ever-shifting language target, web developers will more than ever be stuck writing everything twice, once for IE and once for everything else. To further its monopoly, it will screw developers and consumers.
I mean, and what the fuck is wrong with updating a fucking language? Christ, they've been doing it with C for the better part of four decades, Fortran and Cobol for longer (adding OOP functionality and other radical new ideas). Microsoft has done it tons with its own Basic dialect, which barely resembles the old MS-BASIC found on Trash-80s and the like.
The world's burning. Moped Jesus spotted on I50. Details at 11.
ITYM rubber stamps them.
Deleted
I think Microsoft royally screwed up with outlook web access. They added XMLHttpRequest to the browser so outlook web access would work more like a desktop app. They built an application on a technology that did not require full access to the latest version of the win32 api and x86 assembly language and it was off to the races. Most of Google, Yahoo and indeed the entirety of Web 2.0 was built on this mistake. They are desperately trying to put the web back in the original box they intended it to be in which is people without access to the latest version of the full Win32 API, and an X86 processor will be denied access to all online content.
Are you nucking futs? At what point in the history of MS have they done anything that was relatively useful to the end user if it was not Ultimately useful to MS in isolating end users from choice?
Not because I just want to bash MS, but they earned this one fair and square.
I'm not against a company wanting to innovate and improve their product in order to be the best in class, but that is not what MS is famous for. Their innovations have been purchased (nearly a 100 startups left to buy now) and they do not strive to be best in class with any kind of success (can I mention Vista here?). Even when a workable open standard is proffered up, MS has to do their own version in order to isolate end users from choice (can I get a hell yeah for ODF?). We 0nly have to look at the difference between standards based web browsers and IE to see that MS has no intention of doing anything that is actually good for the world unless it benefits MS (can I mention the bill and melinda foundation and OLPC?). MSIE was, and will continue to be a tool for MS to attempt to remain dominant on the desktop. By virtue of business mentality, it must also always be used to isolate the end user from choice. That is simply how big business in the US of A works.
I believe that it's simple dumb luck that we don't have to buy tires from the manufacturer of the vehicle we own. Sure, there is more to it, but think about how valuable the car analogies really are. Do we really want Nissan or Ford or VW designing the roads? Your driving experience depends on your choice of vehicle, and choice of roads. If we all drive MS cars and truck, using MS tires, on MS designed roads... where will the choice be?
Support NYCountryLawyer RIAA vs People
Javascript, like HTML, has grown to handle tasks it was never envisioned or intended to do when it was first created, and that has tremendous implications in the security space (cross-site scripting, cross-site request forgery, etc). Why not just scrap the HTML and Javascript specs and start over with something designed with security in mind from the get-go? Swapping Javascript for Python or Ruby only means that we get to write/deal with exploits with more syntactical sugar. Let's fix the darned problem once and for all.
I'd prefer to see scripts specify which language interpreter they're tested under, and the browser (or other executing object) retrieve an interpreter for it, caching them (and bundling popular ones if necessary). Why should old scripts stop working because they fixed something I never used in its interpreter, and left out the things I did use?
--
make install -not war
What would that take????
Think Communism.
It works great on paper, but then you add the human element.
Self proclaimed wannabe geek. You know how it is. Most of us who read this stuff probably fit in that category.
You want to give a website the ability to run client side perl?
Considering the amount of havok that is caused using javascript, a language that can't even actually write to a file, I can't even imagine the chaos that would be caused by perl, with all of it's methods for reading system states, and manipulating files and output devices.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
I find it incredibly annoying when links are done in javascript. When I follow a link, I usually middle click on it so it opens in a new tab. With javascript, if I try to open the link in a new tab all I get is a blank page. More bloat and less convenience... *insert offtopic slashdot snipe about how this could also describe windows vista*
"ECMA International is a group that approves standards, but isn't as widely accepted as ISO."
Fixed that for you.
Lately, they've also been known for the large amount of Microsoft standards passing through them, such as C# and OOXML.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Did you know that in Opera you can right click on a web page, select Edit Site Preferences and disable Javascript, or just disable the features the site abuses. No extension needed! And it runs perfectly fine on older machines since it doesn't leak memory like sieve like certain competing browsers. It's also free and cross platform just like them.
And it has fewer vulnerabilities -
http://news.softpedia.com/newsImage/Internet-Explorer-vs-Firefox-vs-Safari-vs-Opera-3.png
Plus since it has a tiny market share it's very unlikely anyone will bother to target it.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
ITYM?
What's that short for?
*sigh* back to work...
Do you really think it is a good idea to insert a whitespace meaningful scripting language (Python) into whitespace meaningless HTML? The level of indenting in HTML has no effect on the rendering, but change the indenting in Python and you've borked your script.
Seriously, Python would be the WORST language to use for scripting in HTML.
Javascript is actually pretty good, the only reason it has a bad name is from the different browser implementations and different DOM accessing methods. Fix that, and add some more convenience libraries / functions and you are set.
iso and/or w3c could actually DEMAND full operation of the ecma standard in applications, and hand down some sort of ecma certification
im sick of these companies arbitrary implementations!!
its time for interoperability and compatibility
the amount of time and money spent by developers/designers to handle these different browser implementations is ludicrous
these standards organizations should start doing their job and start making sure companies are implementing these specs properly
its this sort of stuff that has sabotaged vrml and others in the past.
by allowing anyone to interpret and implement their own interpretted version we, as developers of web applications, get left with the clean up
its time for these companies to start being more exact
and for the standards organizations to start making sure their standards are being implemented correctly
back in the day we didnt have no old school
My guess is Microsoft realise that compatibility with JavaScript, HTML and other open standards is questionable in most browsers and they absolutely do not want to make it any better. After all, if the open standards were adhered to (and improved such as with ES4), who would care about Silverlight or .NET? I think that's the bottom line here. ES4 makes many fundamental improvements to JavaScript. It's not hard to think that ES4 + HTML + a strong Ajax lib might render Silverlight irrelevant. And Microsoft sure can't let that happen. Better to talk up problems in js and subvert every effort to improve. Meanwhile they'll push Silverlight as the solution to all the problems they're partly responsible for. The sad part is that Flex and venerable Java are still better solutions than Silverlight but we know how the industry loves the next best thing even if there is no need to.
"Embrace and Extend" not working, Microsoft goes with "Repudiate and Close".
I expect a Dilbert strip about this any day now.
668: Neighbour of the Beast
But if MS creates a new language and it's beloved of "web developers", it won't take long to be implemented within Firefox, Opera and Safari. If not beloved and not supported, it'll die.
Deleted
Heh. Thanks. I was actually having a little trouble wording that...
I don't know much about ECMA besides that they were responsible for the js standards... Looking at their list of standards, it appears they are responsible for a few more yuckies such as the CLI and the Windows C API. On the other hand, it appears they control the Eiffel standard as well.
I wonder what their reputation in other industries is like...
I'd like to see something like GWT where the source language is Javascript instead of Java - that is a Javascript to Javascript compiler where you could add whatever local features you need and have the compiler throw away the fluff and stick in cross-browser compatible shims.
You'll probably not get this wish any time soon. An essential design choice in GWT is that the source language uses static typing. This is what allows for the resulting "binary" (javascript) to be as small as possible (everything is monolithically compiled as one unit, and so the compiler can dead-strip any code that is provably never called -- and that "proof" hinges on static typing. Incidentally, the static typing is what makes fancy method/member completion in IDEs like Eclipse/Netbeans possible too. You'll not be seeing tools like that for JavaScript any time soon.
GWT is a brilliant design. I'm so happy someone thought to create it. I realize there are a couple of other things out there in a similar vein, but GWT is the only one that focused on building excellent web applications, rather than trying to make fat-client-apps-in-a-browser or X11 emulators.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
You can't say "it's better to do this in a new language" or "it's better to extend the existing language" in abstract.
The right question is "Is this feature more trouble for implementers and users than it's worth?" If yes, it probably goes in. Either way, it can go into the new language.
Microsoft may have perfectly ordinary maintainer's qualms here. They don't support the full set of standards they're supposed to already; in addition, they've got non-standard extensions already that may clash in various ways foreseen and unforeseen. And people, if not exactly ecstatic about the state of the product, at least can live with it.
If maintenance ain't going so well, and lots of people depend on the stuff that's already there, a developer naturally starts thinking about clean sheets, or fresh fields of snow, or whatever, so long as it isn't digging the hole he's in any deeper. Other people may or may not be in the same boat; in fact, that's really the question. The most commonly used implementation is an important data point, though; they'd be perfectly within their rights to say, "go ahead, but we're not on board."
It may be entirely a coincidence that this opens the door to all kinds of skullduggery. On the other hand, nothing really is stopping them from taking the IE ball and going home on the next revision of the standard, offering ActiveVisualWebScript or whatever to future standardization efforts as a fait accompli.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
And hopefully that arbitrator tells them all to just STFU up and use python :).
Yes, a language that parses whitespace like Python does would be great for client-side scripts run from a web browser.
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
Javascript is in no way comparable to XUL. XUL is an XML layout dialect, JS is a programming language.
Also "Tacking on updates to existing standards only creates ugly security loopholes, and all sort of weird hacks."?
Yeah, that explains why Python 2.x is so much worse than Python 1.x and Perl 5 is so much worse than 4 and why the new versions of C, C++, C# and Java never caught on... Oh, wait.
Climate Progress - Hell and High Water
Incidentally, you may want to investigate JSNI -- GWT's JavaScript Native Interface. It allows you to write incantations in your Java code that can call out to other JavaScript libraries -- if there's something you'd like to be able to exploit within the scope of a GWT project.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
Whitespace is significant in Javascript too. It just has less uniform rules than Python does.
EVERYDAY IS CATURDAY
I have looked at ECMAScript V4 and it is much better than V3. I see major changes, all for the better, The question is how backward compatibility is it? AND How much backward compatibility is needed. Like HTML, JavaScript is evolving, like it should. Is XHTML a different language than HTML 3.0?
My feeling is it should just go to the new version, get it in FireFox 3.0, start testing it there. see what happens.
shaun
I won't give you a hell yeah for ODF, a better example is I give you Microsoft Java.
Wow, that makes so much sense. I've never been able to explain why they would introduce something like XMLHttpRequest. I was unaware that its history was tied to outlook web access. I think you're right: they screwed up to our benefit, and now they're trying to put the genie back in the bottle. Thanks for that little history lesson!
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
I think the biggest problem with JavaScript is bad libraries, bad GUI standards, and bad debuggers. If you fix these 3, then it would not feel so rotten.
Table-ized A.I.
You can look at the myriad of html formats (3, 4, 4.1, DHTML ...) around to understand why incrementally improved standards is a bad idea. Maybe, the number of versions of MS word formats, and the grand-daddy that is OOXML is a good standard? Oh wait, the best is korn-style shells where each standard has been very accommodative of the previous ones.
You mentioned a couple of standards that were openly developed, where the controlling parties did not have a nefarious interest in its development. Please see the current context, which is the background of my comment.
Microsoft: "You've got questions. We've got dancing paperclips."
At this point I don't like the thought of either approach. In the case of Microsoft's approach, adding a completely new scripting language, I can foresee another 10 years of attempts by them to lock web developers into using a Microsoft defined framework while at the same time making compliance within other browsers difficult. They will make sure that other browser development teams are always trying to hit a moving target and stretching their resources, while MS sits back with 10 times the developers and makes this new scripting language ever more integrated with whatever they are calling an operating system that year.
But I don't really like a "radical upgrade" approach as proposed by Mozilla either. While it is the lesser of two evils, I can foresee many many security issues, unless the radical upgrade is designed from the ground up with curtailing XSS vulnerabilities and the like in mind. Also, as we head blithely into a Web 2.0 world (never did find the RFC for "Web 2.0"), I see more and more processing dumped in the lap of the web client that has to render the web page. Where we used to begin to get annoyed at web pages that took more than a few seconds to load, somehow we are now okay with waiting 20-30 seconds for some Javascript heavy page to render in addition to the loading time. Not everyone out there writes good efficient Javascript code such as Google.
Let's fix what's broken with Javascript first. Let's make XSS attacks hellishly difficult to create and fix the sandbox that JS is always threatening to break out of. Sure, let's add an extension or two so that AJAX functionality has more inbuilt support, rather than being what it is now: a massive hack of XMLHttpRequest. Let's even work at simplifying handling of browser differences in the DOM and increase the efficiency of the interpreter for what is unfortunately a very clunky interpreted language.
But while we're doing this, let's not break it, okay? Not everyone out there is a typical Slashdotter. I know people who are very proud of having constructed their own websites in (awful non-compliant) HTML with a few Javascript bells and whistles too. If we give those people a "new and improved" scripting language that is much more difficult to write, then we take away something that made the web so exciting at its very start in the early 90s: the fact that anyone with just a small amount of technical knowledge could publish rich content to be viewed anywhere the Internet reached. I know, backwards compatibility can be a bitch at times.
I actually wrote (Not Vista, that's a sack of crap, no matter who wrote it), but I used the Not sign instead of the word, and for some reason it's gone from my post
Just browsing comments, a lot of people think Javascript is pretty horrible. I've developed a few internal web-based tools and always managed to produce nice looking Javascript that does a good job. Unless you try and use IE with it. I develop with Firefox as I can use Firebug to debug through the problems that crop up.
This last week I've been doing some javascript for a commercial product and it all fell apart in testing with IE. IE worked for two or three screens refreshed dynamically with Javascript - just enough for me to decide hey! cross-platform! But after that it went mental. I've had to change loads of stuff with heavy reference to a similar application that was tested and proven - the main problem being that there's no useful debugging tools I could find for IE and so much stuff just doesn't quite work.
Javascript is quite a nice language, it just has a poor implementation that you basically have to work around unless you're in the position to impose Firefox on the users.
Your criticisms seem to be aimed at HTML and CSS, and at attempts to make up for their failings with Javascript toolkits. What Mozilla is pushing here is significant enhancement to Javascript in order to remedy many of its failings while maintaining backward compatibility. Microsoft, on the other hand, is trying to limit changes to the language. According to Eich, Microsoft is criticizing the ES4 proposal without offering concrete alternatives. Instead, he says, they are developing their own language in secret.
I think Javascript's a pretty good language. Certainly it's not perfect - few languages are. PHP, C++ and Perl spring to mind as being particularly flawed, but they have been indispensable nonetheless. Javascript has a huge installed base of runtimes and many programmers are familiar with it (so there's lots of bad code, which may be why JS has such a bad rep). We know how conservative most developers are about learning new languages (especially ones that don't look like C or BASIC), so there would be a significant cost and risk to trying to switch horses from Javascript to something else. Browser compatibility is another matter altogether - but we know who is causing the trouble there.
Javascript is practical and flexible; the main problems I have encountered are weak support for OO and larger projects - problems the ES4 effort appears to be trying to address. Microsoft's argument is for making minimal changes in favor of some unknown future language. If they really are working on that language in secret, and are able to complete it while Javascript is mired in controversy, the outcome is unlikely to be good for the rest of us.
That's exactly it. Some people are fond of saying "You know, it was actually Microsoft who invented AJAX because they had XmlHttpRequest() first" but if Microsoft had known that they'd be enabling a general-purpose platform for application delivery -- one that doesn't require Win32, or even a full desktop computer at all -- they'd have found another way or not done it at all.
Tired of FB/Google censorship? Visit UNCENSORED!
I agree with you, except for the Python part. Python is an ill fit for a language that's meant to be embedded in a (X)HTML, because (X)HTML does not honor content whitespace (and neither to a lot of related tools) and Python relies on whitespace for structure.
I could see trying to standardize a subset of Ruby though. Drop some of the ambiguous (or more difficult to implement parts) and access to operating system services (like fork(), etc), just keep the very basics necessary for pure code and modular OO, give it a well-though-out built-in object model for the DOM (and perhaps some built-in libraries of functionality for things like XML/XSLT, xmlHttpRequest-like stuff, etc), and keep the language compatible back to real Ruby (that is to say, all BrowserRuby code runs on a real Ruby interpreter, but not vice-versa).
Re-reading the above, it sounds like I'm basically describing a rehash of what the Javascript guys did. The difference would be that (1) We can do a better job today now that the problem domain is better understood, (2) It will actually be compatible (javascript code does not run in a real java environment unfortunately), and (3) It will be based on a much better language (no offense, but Java sucks).
Normally I advocate Perl over Ruby, but in this context Ruby probably makes more sense (in the very broadest sense, the languages are fairly comparable anyways).
11*43+456^2
The ECMAScript 4 is backward compatible. Brendan Eich:
my favorite is the jackass that replaces an input type="submit" with an input type="button" and adds a keydown event handler to submit the form when return is pressed and an onclick event handler to submit the form when the button is clicked.
Do you even lift?
These aren't the 'roids you're looking for.
Hey thats not true, my 386 16mhz router is still running true protected mode x86 instructions right on the hardware.
You seem to have some facts wrong, so your viewpoints are off.
MicroSoft has not released Silverlight for Linux, go look at the downloads page (/silverlight/downloads.aspx). They probably never will.
Miguel de Icaza of Mono/GNOME/Novell fame has led the effort to make a Linux implementation called MoonLight (http://www.mono-project.com/Moonlight). Supposedly, Microsoft will not sue for the infringement of their intellectual property, http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx -- but that is a promise, not a license, so those are legally tenuous grounds to walk on. If they were serious, then they would grant a license. The problem is that it would have to be an open source license.
Do not delude yourself or others: Microsoft sees Linux as a threat to their OS. Microsoft uses Silverlight to control Internet user interfaces and fend off adoption of Adobe/Macromedia's Flash, Java applets, and the web standard of SVG, and even AJAX/HTML/CSS as well as all other UIs.
JavaScript has always operated in a sandbox: so I disagree about your notion of "developed in a trusting world" because any compromise is lethal, no matter what the point. Designing a sandbox around JavaScript is pragmatic security design -- much like Flash, Java applets, and much unlike ActiveX's origins. So if you've ignored the security patches of JavaScript (to keep it secure) and if you've never benefited from an AJAX web site or HTML form validation, then I can forgive your comment.
Of course, people who do not design for graceful degradation of any technology in a web page might have caused your comments, but the web benefits from dynamic applications in web pages: there's no installation necessary.
You can keep your HTML 1.0 web circa 1993 -- I remember it fondly, because nostalgia wins the truthiness argument. I'm happier with the possibilities of web applications based on open standards delivered by the Internet versus proprietary OS applications because it fosters competition and advancement in the market.
My opinions are my own, but you may share them!
Actually, I wrote a function for an application I'm developing (in Python) that fixes that problem to some degree with XML files. Example:
:)
<script type="text/python">
from template import *
who='Slashdot'
if not (who == ""):
s=Template('Hello, $n!').substitute(n=who)
else:
print "I'm confused!"
print s
</script>
will cause problems, since XML parsers tend to include all the whitespace and newlines and so forth. My function simply converts the tabs to spaces and then unindents everything deleting the number of leading spaces of the first line, which will never be indented in a valid Python script, from all the lines of the script.
Probably not something that hasn't been done before, but I did come up with it all by myself.
My blog
I have to agree with microsoft here, some of the suggestions that were made for the ES4 standard were quite frankly mad. The current draft has removed some of the more ridiculous ideas like the adding in the E4X support which involved introducing new syntax for dealing with XML. I don't think that adding domain specific features like this to the core language makes sense at all in a language that is general purpose. The spec still seems to suggest trying to form some sort of hybrid of prototype and class based OO which I suspect will lead to both bad implementations and unmaintainable code. The ES4 group also seems to have decided that simply gluing on features from python is a good idea (for example list comprehensions), I like python but I'm not sure that this is the best approach to extending javascript.
I think that some of the work the WHAT WG group have done is actually much closer to what the ES4 group should be looking at - making a standard library that is richer. For example the HTML 5 draft has an API for SQL that could easily be used as the basis for a new standard object in JS.
Unless a real good reason can be shown for creating yet another programming or scripting language, then we should stick with what we have. If new functionality is needed, then why not add some new standardised object type.
I should note that I am always sceptical when Microsoft says we need a new scripting language, because they usually try to keep control of it and make it another reason to stay with Windows. This is not to say other companies have not tried to control the programming languages they have created, but the reason Microsoft's approach usually annoys me is because of their lack luster cross-platform support.
All this said and done, a few things could be improved in Javascript, including
- ability to have typed methods
- ability to have multiple methods with the same name, but different signature
One thing that needs to be noted in all this is that Javascript is a scripting language and not an excuse to shove the whole web site logic onto the client side.
Jumpstart the tartan drive.
Brendan is completely right. ..), SVG, new Javascript version will make for a new generation of browser.
This is all about open web.
Browser technology was somehow lagging behind what's used (ie flash...) and need to improve for the future web.
HTML5 (video, canvas
IE will probably try it the proprietary way.(at least at first)
Concerning Javascript, it will allow complex site to better work with modern browsers (Mozilla based, Opera, Safari/webkit) providing a better user experience and security, while still "just work" for IE via a compatibility layer...(until MS somehow catch up, which they have already done in the past)
This will be interesting to see how the situation evolve in the mid term when some of this technology starts to be available in more browsers (ie in one/two years)
Microsoft doesn't really believe in evolution when it comes to development environments and UIs, preferring radical departures from the past. I'm not surprised that instead of adding features to Javascript, they'd prefer a whole new language. It fits their model, since radical changes require radical reeducation, a service in which they make money. This is why they didn't add the features ASP needed but instead blew it away with .NET. This is why Vista fucks with things that worked fine in XP - just so they could cause feature churn and sell more instruction. Contrast this to open source environments, which change gradually and incrementally. If you knew Unix in 1978, chances are you'll do okay on Linux's command line. If you knew PHP in 1998, you also know it today.
The flag just makes more sense than the constitution. - Judas Gutenberg
Oh, don't forget that they approved OOXML as a standard and was the body that tried to fast track it with ISO.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
I would be rather less paranoid than you. Microsoft is rapidly moving to a service and web model. Not very happily, but moving. When there is a reasonable user base in Linux and a business model to make money, they will follow the users. They don't want to leave the customer with no choice but Google and Adobe, neither of whom are any more magnamious that Microsoft.
The market is focused upon neat features and gee-whiz issues. Doing this with the OS and applications is what both made Microsoft sucessful and dug them into the security hole they are trying to work their way out of. I am an old fart and remember one of the old security dictums - Thou shall not mix data and executables. Scripting does so. It makes lots of neat features possible, but it also significantly reduces trust. For certain applications, such as banking, or high value financial transactions, trust is far more important to me than features. For others, the neatness may be more important.
I am actually buying a new computer so that the computer I use for my banking can be hardened and restricted and will not run any of my children's games or web snap-ins. It will be running Vista with all users running as normal users, sidebar disabled, and IE7 will be running in enhanced security mode.
I allow my kids machines to run flash and javascript because there is nothing valuable on them and neither my wife or I use them.
XMLHttpRequest comes from the golden age of the browser wars when the WWW was the hot new thing which was set to change the industry, and the head of this new company called Netscape was claiming that the WWW would "reduce Windows to an unimportant collection of slightly buggy device drivers". The web was new and out of Microsoft's control. They had no choice but to tackle it head on and gain control of the browser market any way possible, even by bundling it Windows 98, which got them into antitrust trouble with the US government. It was Netscape vs Microsoft in a features arms race until Microsoft finally gained control and market share. Netscape then opted to more or less leave the browser war. With the browser war won, the stream of features stopped and after IE 6 the stream of new innovative browsers stopped to. This effectively froze the functionality of the web browser as a platform for years to come, stopping it from encroaching on any more desktop territory.
It is only relatively recently with IE 7 that the world learnt that Microsoft's Internet Explorer team even existed still. Despite the popularity of Web 2.0 style graphic effects and GUIs, Microsoft still doesn't dare extend their browser and the web platform with more functionality. Any new functionality must come in a standard that Microsoft can completely control, Silverlight that is. It is kind of ironic that the features that Microsoft brought out to try to win the first browser war are also powering Web 2.0 sites all these years later. Microsoft also gave us "design mode", WYSIWYG style editting functionality in a browser too, by the way.
This concludes the history lesson for today.
(I didn't know about Outlook web access. Very interesting!)
--
Simon
Some fairly prominent figures in the web development world disagree.
See: Doug Crockford's "JavaScript:
The World's Most Misunderstood Programming Language"
See also this video presentation.
Apparently everyone you know is writing JS the way they learned on internet forums in 1998. Ecmascript is actually a wonderfully consistent and logical language. Once you get over a fear of prototype-based OOP, and once you quit using global variables, it's awesome. How many other languages let you extend the behaviour of the built-in data types?
As for browser incompatibilities, you're free to write your own code to abstract that away, or you could use any one of prototype.js, mootools, scriptaculous, yahoo uilibs, dojo, ajaxtk, and so on. Using a library like these is equivalent to using the C++ STL; while you *can* reimplement all of that from scratch, you're much better off using a well-supported and cross-browser library to do it.
http://www.sitepoint.com/blogs/2006/02/16/javascript-libraries-and-patterns-yahoo-does-ajax/
Absolutely, they shoot themselves with that XMLHttpRequest...
They loose every inch of web business sector. No Browser, No HTTP Server, No Search Engine, No multimedia format (flash won the war).
And now they try to f*ck up the current axax movement with that silverlight.
No thanks...
[My english is better than most other people's Turkish, so please point out mistakes politely. Thank you.]
This is a bit off the topic, but communism actually can work reasonably well when it's practiced on a small scale by willing participants who all know one another directly. It tends to fall apart when strangers from across wide areas with different values, resources, and interests are forced into it. It also tends to fall apart when combined with idealized notions the participants don't really buy into, like mutually interchangeable sexual partners, no labor-saving devices, or unusual cult-like religions.
Small self-sufficient communes function about as well as large extended families do. You piss some people off, and they get over it. They piss you off, and you get over it. Some people leave and stop talking to the group. The Amish live in a nearly communist situation, and they're just fine. They have buy-in from their members.
There's a commune not far from where I live of non-Amish Protestant Christians who interact as capitalists with the outside but share the wealth internally. They have a dairy, a restaurant, a few stores, and a few other things supporting their church, school, and faith-centered drug rehab center. There's a communal foster home for troubled teens near here, too. They have a school, several homes, farmland, livestock, and accept donations. The foster parents take care of their own kids and the foster kids, and the money and farm work is all shared among the households. It works, because that's the way they all want it and the struggles are shared among them.
The Soviet Union, for example, tried to combine by force several nations of people with their own languages, cultures, natural resource differences, religions, and industries. A restaurant manager in Minsk didn't see the struggles of a construction worker in Vladivostok, and the two likely didn't agree to be communist/socialist in the first place. It's a very different type of thing. The scale's different. The agreement is different or nonexistent. The common bonds outside the economics are thinner. It's just not the sort of thing that's going to stretch to that situation. Anything you're forcing millions of people to do is not likely to gain much appreciation for the perpetrators or their ideals.
Capitalism, though, is a very naturalistic market type. You want something, and you need to do something to get it. You give something up in order to get it, or you decide it's not worth the trouble. There's no enlightened common interest necessary. In fact, enlightened self-interest isn't always a big hit either. Capitalism can largely function on pure greed, even though helping yourself through helping others is more sustainable. That is the reason capitalism is so successful -- it's simple, and it doesn't overestimate the goodwill of man for his fellows. The funny thing is, with computer modeling and research into complexity and chaos theory, there's just now more to learn about how and why capitalism works than ever. It's like the KISS principal, genetic algorithms, neural nets, network effects, and feedback loops all applied to moving goods and services around in the real world. We're just starting to understand the value of those methods in software, but the markets have been doing it for centuries with decent results.
Now, if we really want to help people in poor countries, we should seriously look into getting education, skills, and capital investment up. That way they can participate in capitalism. Unfortunately, capitalists in relatively peaceful and secure areas don't invest much in areas where their assets will just be burned, seized by warlords, or looted. Getting those areas that lack investment stable is a prerequisite for getting investment into them, but getting investment into them is also a prerequisite for getting them prosperous and therefore stable. Gradual investment in progressively more market-centered areas is probably the best route. Start with water, food and medicine. Then do housing, utilities, and schools. Then transportation, security, and local self-sufficiency. Then big business inve
What exactly is "bad" about JQuery?
Bad GUI standards? What does that have to do with JavaScript? If you can name a GUI standard within a single language that it better, please let me know. Certainly you don't mean Python's GUI since there's no standard there at all. It's the same story with C, C++, Ruby, Perl, Pascal, and all of the others. A notable exception is Java (aside from the AWT/Swing duplication), and a large number of people hate that. Name something better.
What's wrong with DOM/CSS, especially when there is nothing about JavaScript itself that's intimately tied with DOM/CSS. There's no reason within the language's constraints that an applications programmer couldn't integrate JavaScript with GTK+ or Qt.
As for debuggers, have you even used Venkman? Or are you still using alert() calls for your debugging?
- I don't need to go outside, my CRT tan'll do me just fine.
was that it used the same operator for concatenation and addition. That's just all kinds of stupid for a loosely typed language.
I would like to use MS' idea, but have somebody, anybody, else implement it. A new language is okay, as long as Microsoft stays out of the process of making it, since they have extreme interest in creating vendor lock-in.
The problem is once something becomes (even de-facto) standard on the web, it will never die.
It doesn't matter if the standard is crappy or not. Look at all leftovers from browser wars (DOM0, quirky box-model, framesets, all now-deprecated HTML elements) -- browsers still must have first-class support for all that garbage.
Even if you add a brand new, super-cool language with excellent security model, Javascript won't die. Revolutions don't work on the web (see how far application/xhtml+xml has got and how well XHTML2 is doing). Browsers will just end up with new things to implement, new incompatibilities, more code to maintain and larger attack surface.
They want people to use windows and not the web for applications. Google apps and java scare ms to death. People might actually ... gasp .. not have to use windows.
.Net is a way to fix this by having everything done on the server end.
IE stopped innovating the second netscape became irrelevant with the exceptions of security fixes and anti phishing schemes with IE 7. Now that the web is no longer a threat the focus is back on the proprietary windows desktop but this obnoxious firefox thing happened. (In microsoft's eyes)
Also javascript is viewing as a page source so even if ms came out with a proprietary api it would not take long before it could be reverse engineered. The push to
http://saveie6.com/
Problem is Microsoft's answer is silverlight which will only run on Windows with IE. It still uses javascript but I do not trust a convicted monopolist to redefine web standards.
If we are going to redo javascript then it should be opensource by a comittee or group. Unfortunately MS owns so much of the browser marketshare that they can just ignore any standard that is not there own and it will go no where as a result.
http://saveie6.com/
Actually, you could happily write your entire script file on a single line, and you'd only need to put spaces between keywords. I think GP was referring to line breaks, which languages like Python and BASIC need, but languages like C, Pascal, and Javascript do not.
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
OK, I fully admit the history of javascript is something I'm not extremely knowledgeable about. I also am aware people are using javascript outside of the browser these days. However, since to date, javascript is primarily a browser based language, why don't they use some of the fundamentals that the browsers use? Simply, make the new version (and future versions) declare their version to the browser, and the browser can then handle how to run. Microsoft can treat it like a new language, Mozilla can handle it they way they want to, and people running older browsers will be oblivious to it all (as long as however it identifies itself doesn't break the previous version). So the new version would have something like //ECMAScriptv4.00
at the top of every line of javascript that needs the new interpreter. True, we spend more bandwidth, but in todays age of gzip compression everywhere, is it really going to matter?
Firstly, at the time there were a huge range of "safe-for-scripting" ActiveX objects that could be created in IE. This was Microsoft's way of clutching every corporate shop that dared to use one in a death grip, instantly destroying their potential to have the versatility that a web application would normally bring. XmlHttp, found in the MSXML library, was just another safe-for-scripting object. At the time the web curious were already exploring a number of ways to do asynchronous calls, most commonly being hidden IFRAME updates, but there were a myriad of other options, including plenty of third-party XmlHttp type components, and even some Java Applet techniques for doing this.
This was a hugely growing need, and while Netscape was beaten to the ground and slowly regrouping Microsoft seemed to lead by default.
The point, I suppose, is that the invention of "AJAX" was absolutely, positively inevitable. Microsoft's influence in those early days is entirely the result of its monopoly, not its technical leadership.
I have to say, I agree with Microsoft on this one. No doubt they have some sinister motive that I'm missing, but on the technical point I'd rather not see major changes to javascript. Radical upgrades to well-used languages are rarely an improvement as they have a habit of breaking so much existing code (you know the languages I'm on about...) Far better, in my opinion, to let javascript keep doing what it does and put all the new features into a separate language. It needn't add (runtime) bloat to browsers if the interpreters are modular, loaded as needed; and these days who cares about a few extra megabytes of hard disk bloat?
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
Also "Tacking on updates to existing standards only creates ugly security loopholes, and all sort of weird hacks."? Yeah, that explains why Python 2.x is so much worse than Python 1.x and Perl 5 is so much worse than 4 and why the new versions of C, C++, C# and Java never caught on... Oh, wait.
.. but if you want another example of a language where tons of insecure and hacky cruft has accumulated over the versions, try PHP. Now there's a language that needs a complete restart if I ever saw one!
Your examples actually strengthen the point you are trying to argue against. C++ is indeed lots of new stuff tacked on to an existing language (C), with a result that is far from elegant and full of gotchas, as any newbie to C++ will know. C# and Java are both completely new languages, they can be called successors to C/C++ but neither even tries to be backwards-compatible and neither builds on the C++ standard. I don't know about Python and Perl
Quality, performance, value; you get only two, and you don't always get to pick.
It might make enterprise development easier if you're forcing users to have a certain browser platform available, but it will make extranet web development an even bigger nightmare.
It's bad enough as it is already:
if(browserSupportsPlatformA)
doSomethingThatBrowserSupports();
else if(broswerSupportsPlatformB)
doTheSameThingButInADifferentWay();
else
doSomeFallbackCodeSoSiteIsntTotallyUnusable();
And then you'd have to somehow write fallback code in a different scripting language in case one scripting language is completely unsupported.
It's bad enough as it is. And you know exactly what will happen: web sites will be built for only two browsers (maybe three if you're extra lucky), so you have no choice but to have those browsers installed, even if you hate them, while the browsers (such as Opera) that actually *follow the correct standards* are left out because they don't render websites as expected because those websites are built to suit Microsoft's and Mozilla's deviant specifications.
The whole browser architecture we have is absurd. Web development is almost like having to write XML files that are deserializable in two or three different XML schemas. The JavaScript DOM is at least common enough so that you can easily go to the W3C website and quickly see what you can do in all three or four major browsers... The last thing we need is less compatibility.
Hmmm... I always thought C++ was messier than Java and C# because it completely different design goals. ie. Java and C# are simple, platform independent OO languages, whereas C++ tries very hard to avoid abstracting away anything useful for writing high-performance code (real pointers, for example), while still giving you the full power of an extensible OO language (instead of the crippled feature set of Java). What you perceive as "cruft" in C++ is actually what allows it to still be usable for writing things like operating systems.
Creating a programming language that allows you to use abstract concepts and tinker with what's under the hood is hard. Making it pretty is probably impossible.
"I'm a Laver, not a Phyto[plankton]"
I learned to program with VB, and still think its an acceptable language, and I agree with you 100%. Newlines mark the end of statements unless you add a '_', you Dim As, or just Dim (strongly typed or not, wtf?), and thats all I really can remember.
As someone who has written a 1000+ line AJAX app in the last 6 months, I can tell you that cross-browser incompatibilies already make programming javascript a bitch. I can't remember too many specifics, but I know that mozilla javascript implements arrays slightly different than IE, and it was a pain in the arse to CONSTANTLY patch around DOM issues. The breakdown of my time was probably spent 20% design, 20% code, 60% patching for IE.
I don't think so
For fairly well-defined problems. GSM isn't a great cell phone standard, but it has allowed European cell phone manufacturers to take over the global marketplace while American cell phone companies with splintered standards have had to play catch up for more than a decade now.
C++ is an example of horrible design by committee, with ever shifting basic functionality and over complexity. But the updates to C (by committee) have been very reasonable and useful. Germany's design by committee of power plugs has been great for Europe, and has even taken over Britain's mishmash of plugs that has been a plague and a bane to the folks of the island. The metric system has worked out pretty well for everyone.
When the problem is old and simple, committees do a great job of explicitly laying out the pre-existing consensus. When the problem is new and interesting, with no clear solution, committees produce a self-conflicting hodge-podge solution that is always behind the times.
It's not necessarily post-facto, but just not innovative. They're not the same thing. I'm not sure how much "innovation" is really needed for the next generation of js. I'd hope that the problems and their technical solutions are pretty clear by now, and just implementation and standardization are needed. If that's the case, design-by-committee is probably the best thing that could happen.
Sounds like a lot of people are addressing this from the anti-MS, pro-Mozilla Foundation standpoint.
The next version of ECMA Script will break just about every piece of legacy javascript. That's a decade of history and development in the crapper. People have just begun to release real and functional javascript libraries that open up a whole world of opportunities and going with a new standard not only destroys those libraries but it puts a serious hamper on the evolution of the web in general.
Even if we throw in a tag to make legacy javascript viable, every legacy page out there would have to be updated - meaning all of those abandoned or hardly maintained web sites with tons of useful information are going to be broken - so instead we'll have to wade through 200 word ad filled pages looking for the information we need.
Re-implementing javascript breaks the web as we know it. As such, it is a bad idea. If you want to extend the experience, implement the new language as a new alternative language - like VBScript.
How would you all be reacting if there was talk about re-implementing C or heaven forbid Ruby.
It's pretty clear why Microsoft wants a new language: they think they can get away with designing it and imposing it on the world, after patenting it and making one of their bogus covenants.
ECMAScript 4 is a nice language, and a good evolutionary development from the current version of JavaScript. And if Microsoft wishes to, they can view ECMAScript 4 as a "new language" too; we can have bold old and new JavaScript in the same browser.
Okay, whitespace can be significant in JavaScript. Look at automatic semicolon insertion.
EVERYDAY IS CATURDAY
I have to agree with MS on this one. A radical update to Javacript has the potential to break more than I would care to think about. Major web applications can take months to simply test and years to design and implement! Major platform changes of this type are an unacceptable risk in the enterprise setting. Now, I fully agree that JScript is a horrible and broken implementation of the ECMAScript standard, but let's face it: JScript's own problems aside, Javascript as a language is not acceptable given what people are trying to do with the web. It was meant to provide limited dynamic capabilities to mostly static information delivery. That was yesterday, now let's take a serious look at today. I'm sorry if I'm offending any scripting fanboys, but weak typing, the lack of threading, the lack on non-prototypical OO features, the lack of a serious class library (including real data scructures), etc. all get in the way of delivering truly powerful client/server apps.
As I view it, casual web browsing and using a large-scale web application are fundamentally two different things, and demand two different approaches to development. Let ECMAScript/JScript/etc. stick around; it's sufficient for small-scale or casual needs. But if we're really talking about delivering large-scale, complex applications over the web, Javascript costs countless hours of productivity, and does limit the potential for what web applications might be able to deliver to users.
I'm completely in favor of creating a new language to meet the needs of tomorrow's web applications, provided that Microsoft and open source vendors work together in an open and honest fashion. This will only become a reality if all parties cooperate and make it a true standard. But on principle, yeah, Microsoft has the right idea on this one. (In my dream world, I would love to be able to deliver bytecode via HTTP, execute it in a tightly controlled sandbox, but still use the DOM as the UI delivery mechanism, but somehow I doubt that'll happen!!)
-James
I'm having nightmares of the reincarnation of C++ into javascript. Oh the horror!
Microsoft's dream since 10 years is to rent web applications, since it will allow them to earn more and more money.
It's impossible to program Office with the current Javascript language.
So, Microsoft is trying to push Silverlight (since it's its own baby based on C#).
The battle that will result may see Microsoft's largest defeat.
First, this is a political battle, and every opponent has to make concessions, and M$ are not good at that.
Secondly, M$ is no more in a position to dictate how the Web should work, since the users have now a large choice of Web browsers (Safari and Firefox in particular). They still behave as if the Web was IE-centric.
Thirdly, Microsoft imposed his OS by crushing its competitors one by one. Due to the progress of Apple and GoogleOS, it's not any more possible.
Frankly, I don't see how Microsoft could win this battle.
If they count on their own forces, they will fail, like they failed with Vista.
If they expect a large developers support, they are wrong, since nobody (I mean nobody important) is supporting Silverlight.
If they count on a miracle, I think they had their share.
Once a technology standard will be decided, everything will depend on large Web companies, like Google.
You are incorrect. I do not consider stuff like pointers "cruft" in a programming language; C, for example, while old, is quite an elegant and cruft-free language. C++, however, is not, unless you trim off all the bits that characterize it as C++ rather than C with a few pieces of syntactic sugar added. The stuff in C++ that makes it messy is that they kept mostly backwards-compatible with C, to make it easy to port programs from C to C++, while introducing a poorly structured and horribly bloated STL. Still, there are enough differences between C and C++ to make porting a pain in the ass anyway, so it can be argued that it would have been better to drop the legacy stuff from the beginning.
Second, you may not have noticed, but none of the current big operating systems are actually written in C++. The Windows, Linux, BSD and OSX kernels are all written in straight C. You can use C++ in the kernel, but there are lots of drawbacks, google "kernel c++" for details. Now, you said "operating systems", but the kernel is the only part that's relevant here; userspace tools can be written in any language so long as there's a compiler for it.
Quality, performance, value; you get only two, and you don't always get to pick.
Javascript was never intended in any way to have anything to do with Java. Netscape marketing thought it was a good name though.
Nerd rage is the funniest rage.
The CB App. What's your 20?
My understanding is that Silverlight replaces the DOM. It is xml markup at its core. I'm pretty sure it is like flash, embedded as an object and run by a plugin.
Second, you may not have noticed, but none of the current big operating systems are actually written in C++. The Windows, Linux, BSD and OSX kernels are all written in straight C. You can use C++ in the kernel, but there are lots of drawbacks, google "kernel c++" for details. Now, you said "operating systems", but the kernel is the only part that's relevant here; userspace tools can be written in any language so long as there's a compiler for it.
The main reason that the kernels themselves are written in C is twofold. Firstly, C++ has a lot of unusual side effects that are highly undesirable in a kernel because you need to be able to understand 100% of what is happening at any given time. Secondly, C++ requires significantly more runtime support than C. Kernels in C++ are not unheard of, it's just that most people don't go through the trouble, since as you've pointed out, C is elegant and mostly cruft-free. The best practice for kernels, even now, is to write the core in C, and provide C++ bindings and interfaces for application developers.
You seem to be under the impression that JavaScript has some relationship to Java. It doesn't.
From the Wikipedia Javascript page:
"Despite the name, JavaScript is essentially unrelated to the Java programming language; though both have a common debt to C syntax. The language was renamed from LiveScript in a co-marketing deal between Netscape and Sun in exchange for Netscape bundling Sun's Java runtime with their browser, which was dominant at the time. The key design principles within JavaScript are inherited from the Self programming language."
Yes, I'm too lazy to find a better source.
Vista? For your kids? What a horrible idea. What's wrong with Windows XP SP2? It's proven and stable. Not so with Vista.
And why IE7? I guess you don't care about the web being open and free?
And the computer may not have sensitive data, but I'm sure you don't want the Internet to gain another node in a botnet or to be a spam delivery node.
Whut we lookin' at it? There an editor that inserts semicolons automatically?
;? nature.
One good reason to use semicolons in Javascript: your code will more likely be parseable by documentation generators and other Javascript-consuming utilities that don't fully implement Javascript's grammar. Most of them don't know about JS's
O lord, bless this thy holy hand grenade, that with it thou mayest blow thine enemies to tiny bits, in thy mercy.
IE 7 runs well and is a safe default for them to work from, particularily since they are running as limited users and don't have install rights. I like Firefox with NoScript, but I have enough knowledge to have some idea of what to enable and what to disable.
Python is an ill fit for a language that's meant to be embedded in a (X)HTML, because (X)HTML does not honor content whitespace (and neither to a lot of related tools) and Python relies on whitespace for structure.
(X)HTML does preserve content whitespace. It's only text display that doesn't, depending on the value of the "white-space" CSS property. Even (some) JavaScript would break if the HTML parser replaced all line breaks with spaces.
The shareholder is always right.
It can host a variety of scripting languages such as Python, Ruby and, surprise, even JavaScript, as well as a couple home-grown languages such as Groovy and the purpose built JavaFX Script
Now before you shriek in horror at the thought of a JVM running in a web browser, Sun have made a renewed commitment to the browser via the soon to be released Consumer JRE, which aims to relieve some of the bloat and provide an improved experience.
Still no official 64 bit browser plugin but the IcedTea folks are working on a substitute.
Of course I have. Quite a few.
However, I'm not aware of any actual HTML tags that Microsoft has introduced on their own or blatantly not suported.
Sure, they don't adhere to anything resembling CSS, their Javascript is broken, and they don't always format the same
The other things in the formatting landscape, yes, their support is usually shitty. But, I stand behind the fact that core HTML is pretty much unchanged. (Though, I'd love a counter example, maybe I've just never bumped into one -- I usually test my web pages on at least two browsers.)
Cheers
Lost at C:>. Found at C.
That's not what I was talking about, though it does have its share of security holes.
What I mean is that you're endorsing M$' proprietary 'standards'. If there's one browser that can be credited as holding back the web because of its wrong and vastly incomplete implementation of web standards, it's IE.
Webmasters know what browser you use to visit their site, and it's because most of the world still uses IE that they won't get their act together and correct their shitty code (which only renders correctly on lax IE), and/or remove their stupid browser detection scripts.
Please support open web standards and use any browser but IE.
Really what is the difference? A radical enough change to Javascript meaning it is in effect no longer Javascript it a new language right?
So unless they are wanting to jump away from the whole family of language that Javascript sits in the totally new language will have lots in common, probably as much as a radical revision?
I can't believe that nobody's pointed this out.
.NET and the CLR.
.NET runtime in the browser. Probably a sandboxed one that can only access the DOM and browser. But you still get all the .NET benefits, like multithreading and bytecode compilation. And all the .NET drawbacks, like you can't implement it outside of IE because it's patented from here to hell and back.
Microsoft wants a new language for client-side scripts. Just-so-coincidentally, Microsoft has this new "language" ready to go for us. It's called
C#, VB.NET, J#. Whatever. Microsoft wants a
See Silverlight? That's the tip of the iceberg.
Open your eyes, people. This is Microsoft.
Have you ever, honestly, been to a website that freezes Firefox?
Yes, I have. There's a dating/forums site called plentyoffish that regularly freezes Firefox for me (at least as of 2.0.0.8). Sometimes the browser recovers quickly, sometimes it recovers slowly, sometimes I give up waiting and kill it.
It's official. Most of you are morons.
There are some issues I have with the fact that there's no simple way for users to set trusted zone and Firefox security tends to throw the baby out with the bath water as far as security goes(no modal windows, no clipboard modification etc, I know why this is the case, but sometimes folks like me have legitimate reasons for these sorts of things). I'm also a bit annoyed with the whole "we'll fix it in 3.0" thing that's going on right now, but that's another story.
This all sounds like a wonderful story for the Mozilla corp, but it's not. While the bundling didn't help, Netscape got beaten by IE because IE was better. It's not now, but that's mostly because Microsoft have been slack bastards and sat on it for years.
I remember the browser wars well. I wasn't on the web for mosaic, but I was on for the browser wars. I know that having bundled IE got a lot of people on the net who wouldn't have otherwise gotten there, and I know that Netscape got bundled by ISPs for a while too. Netscape 4 was a great browser, it was better than IE 4, when I had to choose between those two, I used Netscape. However, Netscape 4 wasn't better than IE 5, and by extension it wasn't better than IE 6.
After Netscape 4 there was pretty much nothing for a number of years. Netscape 6 was an abomination, an unfinished rendering agent(gecko is great now but it wasn't done then). Opera was and is a great browser, probably the greatest browser of that time(might still be haven't played with it in a while) most of the innovations of the new era of browsers came from Opera, but it never caught on. Partly that was because in order to be faster it gave up on all the terrible web kludges and large chucks of the web in those days was terrible kludges. It could also be its linux reliance on QT which was bad back then, or the cost, who knows. You want to find a case for why a good browser failed, look at Opera, but back then Netscape wasn't in it and Mozilla wasn't done.
As for the reason why there are standards out there that nobody complies with, it's because the standards suck.
For the love of god people, stop talking about javscript and java in the same sentence! They're not the same, and not related. http://en.wikipedia.org/wiki/Javascript#History_and_naming
"During My Service In The United States Congress, I Took The Initiative In Creating The Internet." -Al Gore
They're working on it.
The crucial factor is having faith in the technology and convincing backend Java EE experts to endorse a rich client interface over markup based solutions such as struts, JSF or whatever 'framework of the month' they read about on TheServerSide.
This whitespace business being bad for webpages is just bull, and it really bothers me to see it here. If you want to compress something, just compress it! If you want to include a large program, put it in it's own file!
but most of all, tell me difference here:
class FOO:
def __init__(self):
pass
def myfunc(self):
print "hi there"
and
class FOO{
def __init__(self){
pass;
}
def myfunc(self){
print "hi there";
}
}
the point is that the USE OF WHITESPACE OR BRACES IS 100% INTERCHANGEABLE, BY AN AUTOMATED TRANSLATOR. A simple 20 line one at that.
open your minds, people!
CS majors know the time/space tradeoff, but they never get taught the 3rd, crucial, tradeoff of the set: comprehension!
<script type="application/ecmascript; version=4">
No need to change existing pages.There are many implementations of C Oh look, Ruby as well.
Two counter examples come to mind:
The abominable <marquee> is a microsoft invention, while <abbr> is still not supported by IE7.
I'm sure there are plenty more out there.
Sun has new language for client-side scripts.. Just-so-coincidentally, Sun has had a variation of this new "language" available in your browser for a decade! It's called applets and the JRE.
Python, Ruby, JavaScript, Groovy. Whatever. Sun has a Java runtime in the browser, a sandboxed one that can only access the DOM and browser. But you still get all the Java benefits, like multithreading and bytecode compilation. And all the Java benefits, like it's implemented for IE AND Firefox on Mac, Windows, Linux and Solaris. Further, it is available under the GPL, so you can port it to any other platform.
See this web page for details of Sun's leaner faster in-browser JVM.
Eich is acting the ass. Not just because he attacks Wilson personally and Microsoft generally without addressing Wilson's concerns, but because he's ignoring (or ignorant of) engineering rule #2: Make Before Break.
From what I've seen of it, ES4 is pretty good. But Wilson is right: It's too big a departure and should be introduced as a new language (C/C++ anyone?). That assures we don't break a lot of web sites while ES4 stabilizes. The various Javascript instances, with no new features—only bug fixes and performance enhancements—will become rock-solid for those who don't need ES4 capability. Years from now, when all the backward compatibility bugs have been excised from ES4, we can retire Javascript. But not a moment sooner.
I'm a Programmer. That's one level above Software Engineer and one level below Engineer.
Open source and open standards doesn't mean you can't charge for your software, it means you can't milk your customers for money long past your product's usefulness.
From what I've read, XMLHttpRequest was originally just a COM object implementing HTTP that the MS XML library team whipped up as part of building that library. (Hence the "XML" in the name; everything in that library begins with XML.) It got added to the browser because it was built by Microsoft. Any class library is exposed to the web in MSIE if it is flagged as safe for the web, and the mindset is to expose everything (and set the kill bit later when people start exploiting it).
I haven't seen anything substantial that says it was created for OWA. Not saying it wasn't, just that I haven't seen it.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
You must have missed the browser wars then.
anyone?
Blu-Ray vs. HD DVD wasteful standard war that hurts consumers and developers
Nope. All I see is a bunch of people scurrying like Frenchmen trying to make their platform cheaper and better than the other guy, and to do it faster. This kind of corporate freakout is exactly what an economy needs every once and a while.
DATABASE WOW WOW
I think Javascript is fine for any application reasonable to do in a web browser. Rather than worry to much about features I'd rather they work on performance. Javascript performance just isn't good enough for major UI or multimedia work. In some cases threading might help with this but I don't know that it's a major factor.
The only feature I think absolutely needs to be added to Javascript is built-in behaviors. Otherwise, If they're going to add features they should add some functionality for working with multimedia, SVG, and possibly 3D more easily - to fill the hole between current Javascript and Flash.
Anyway, you really shouldn't be using Javascript for mouse rollovers and eye candy unless you have very specific needs that can't be done by CSS.
As a developer that works on many websites I'll side with the creator of Javascript and stick to whatever standard he sets forth. If I have to let Microsoft do without features because they refuse to keep up then I don't mind doing so. I always try to design stuff so that if scripting doesn't work everything will still be usable anyway so it won't really harm my users to much. I already have to provide work arounds to keep IE6 and IE7 working reasonable.
If we're going to replace Javascript then I vote for some variant of Python with built-in DOM support and strong networking features.
Not quite part of the Javascript spec but I'd also like to see a tweak to (X)HTML so that authors can declare that script written outside the HEAD section to be ignored. This would make avoiding XSS issues so much easier and wouldn't be any issue to any developer using behaviors or similar methods to attach their JS as needed. I'd also like to see browsers allow users to select an option to disallow JS outside of the HEAD element.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
The man responsible for IE is in no position to lecture anyone about compatibility and security. Wilson telling the inventor of javascript to shut up and do as M$ says reminds me of this:
We can see where that effort went. Embrace, Extend, Extinguish.
Albatross is a fine name for a blog run by anyone at M$. Everyone who works there has made a deal with the devil and the entire company history hung around their necks. If Wilson wants credit for, "enough intelligence to make my own lies up," he can have it. If he wonders why the world might be hostile, instead of the hotbed of helpful, fuckable pawns his company likes, we can always remind him of what his group did to Netscape.
In 1997, when I was on the ECMAScript standards committee, meetings mostly consisted of Netscape and MS reps shouting at each other while the rest of us twiddled our thumbs.
My only contribution was a scathing indictment of the idea (I think from MS, but I'm biased) of putting a hard memory limit INTO THE LANGUAGE. Guhh.
Is this why my Gmail has been sucking as of late?
....
I've been using it for over 2 years on Firefox and it's been awesome
All of a sudden its slow as hell to just open the inbox page - it just began to suck big time - real laggggy for everything
I just got upgraded to Firefox 2.0.0.9 and it seems better now
---- "Logoff! That cookie shit makes me nervous!" - A. Soprano
Once we can get this one basic feature of JS 2.0 working on all modern browsers, then we're ready to talk about things like ES4.
As for other browsers, I use Opera and Firefox as well as IE. I use Opera as a static HTTP renderer if I am doing something relatively dangerous -- all media off, including images, all scripting off, cookies and cache cleared on exit, etc. I use Firefox with NoScript to handle things like ordering supplies from sites with which I do not want to associate full trust. If I fully trust a site, I use IE trusted zone. No other browser that I am aware of supports the zones model, let alone a finer-grained trust model. Thus, I use the combination of IE with Zones, Firefox with partial trust, and Opera with no trust to control my risk exposure appropriately.
Go read some Douglas Crockford.
Javascript is about as powerful as Lisp or Ruby, and certainly no less powerful than Python.
If it's the syntax that's bugging you, write a preprocessor and shut up.
Don't thank God, thank a doctor!
First prove that the whitespace is a bad idea. You're going to indent like that anyway, isn't it simpler just to...
No, nevermind.
First, prove that this flamewar about whitespace has anything at all to do with the requirements that it be a script, that it be client-side, or that it be in a web browser. For that reason alone, this should be -1 Offtopic.
I can think of a few valid reasons why Python wouldn't work well for this, at least without some serious hacking. Whitespace isn't one of them.
(And if it was, like I keep telling people -- write a preprocessor, if syntax is all that keeps you from liking a language.)
Don't thank God, thank a doctor!
Well, that's basically my point. It's not the language itself, but the tools and libraries often associated with it that give it a bad name.
Table-ized A.I.
Both can be wrapped in libraries. And this has been done.
Trust me on this -- I do HDi (HD-DVD) development. There are fairly big differences between Javascript on HDi and Javascript in a Web browser -- but there are actually a lot of library functions we can port over from the Web, and very little we have to do from one HDi implementation to another. You mentioned Microsoft's Javascript implementation -- actually, that's JScript, so called because they are legally not allowed to call it JavaScript -- but JScript powers some HDi implementations, and completely different scripting engines power others.
I'd say, yes, screw two languages -- but not for the reasons you said. Screw two languages because porting between entirely different languages -- for instance, Perl to Ruby -- can be MUCH more work than porting between Javascript and ECMAScript, or between ECMAScript and HDi, or...
Don't thank God, thank a doctor!
The downside of Silverlight is the possibility of patent issues. If that ever goes away, and particularly, if Silverlight ever gets vetted by a standard body, it looks good.
Here's why:
You want the old Javascript? Fine.
You want the new, Mozilla-sponsored, v4 or whatever of ECMAScript? Fine.
You want Python, Ruby, or Java? Go right ahead.
A bytecode engine in the browser is both long overdue, and this is why. This way, no one gets to bitch about the language in the browser (though I like Javascript just fine for most purposes), as you can run just about any language there.
(Ok, Java did a bytecode engine in the browser, but Java applets sucked. I think Silverlight has the potential to suck a lot less than Java did.)
Don't thank God, thank a doctor!
What is really needed is a new open rich GUI standard that is not necessarily tied to JavaScript or ANY language. Why tie a GUI engine to a particular language? Both proprietary and open-source keep doing this more or less. JavaScript is not the real issue. (But since it is a common web standard, it shouldn't be ignored.)
What's really needed is an open standard that allows rich desktop-like GUI's to be created for a web browser or web-browser-like tool. I'm tired of the limitations and goofiness of DHTML + DOM. They may be fine for e-brochures, but suck for business-oriented GUIs and are too tied to the get/post HTML model to clean up. It's like being stuck with 1984 interfaces. Desktop GUI's roughly reached a pinnacle in 1994, but the web never got there.
Table-ized A.I.
Even if they did, the rules are far more complicated than ;?\n Read the ECMA script spec sometime. The portion on this issue is horrible.
EVERYDAY IS CATURDAY
Even without eval, Javascript alone is sufficient to do this in, provided you start with something that's sufficiently like Javascript.
Maybe you can't change syntax, but with ECMAScript 3 today, you absolutely can muck about with just about anything that's browser-specific, be it in the API itself or in your own (already written) functions or classes -- that's what's cool about a dynamic, prototype-based language -- until you basically have a cross-platform library with all the platform-specific crud in there, and your actual Javascript, while it's executed "natively", is also fairly lightweight, platform-agnostic stuff.
Don't thank God, thank a doctor!
Why?
Don't thank God, thank a doctor!
the point is that HTML already uses indenting to some degree, and has rules that make sequential whitespace unimportant in most cases combined with stylistic constraints like not line breaking inside attributes. embedding a langauge where whitespace is significant inside a markup where whitespace is insignificant is retarded. what happens when you want to invoke python inline in an onclick for example, and need to start a new line? you cant use the HTML's level of indenting because python needs its own, so what do you do? break back to column 1? in a multi-line quoted string? what about when a script tag starts at a certain level of indentation?
basically you're a moron.
As I understand it, the basic way this will work is, if there's no version number requested by the script, some heuristic will be used, in such a way that pretty much any script will end up being run the old way.
The new way would be to specify a version. For example:
<script version="4.0">
This both solves your problem, and makes the Microsoft argument irrelevant. Ok, yes, IE will have to throw resources at it -- boo frickin' hoo, you're Microsoft. Don't you have Developers? Developers? Developers? Developers?
But for the existing Web, everything will continue to work on new browsers. All we'll see is that some new websites will only work on the new browsers, and not on the existing ones. Which is fine, really, as most people are getting auto-updated to the latest browser as a matter of course.
Don't thank God, thank a doctor!
Wow. Sorry about that. Mod me down, hard, please.
Looks like the way it works is, a few things that were obviously broken in Javascript are finally getting fixed. This will break code that relies on the old (broken) behavior, but it should be possible to write code that works on both. (If this is what I think it is, it can be solved with a search and replace.)
And it looks like Microsoft is arguing for what I suggested, while Mozilla (and others) are arguing that any <script> tag should run the new version.
As for "just don't break anything", I think it's worth it, really. Frankly, again, assuming the features are what I think they are (and I don't seem to be batting 100% right now), it's kind of like all that code for x86 which assumed that certain things were 32 bits, or that you could always use an int as a pointer, etc. Notice, also, how there's tons of code that just compiles and runs fine on x86_64, with zero effort on the part of the developer, and really no thought put into supporting it -- they simply used best practices.
Don't thank God, thank a doctor!
And that is why I really, really want the patent issue to go away. It really depends how Microsoft uses those patents.
If they are actually about making a new open standard, and not locking Linux out once and for all, they may eventually give up control of those patents.
In the meantime... Silverlight, if I understand it, can actually do hardware-accelerated vector graphics and animations, controlled from "script". And the "script" is a bytecode language, thus you can have closed code if you want it, or open code in any language that can compile to it, not just Javascript. And, hell, Silverlight can probably do threading, too! (Something even ES4 doesn't seem likely to fix.)
But this just brings to mind... What we really need is PNG.
See, if you remember, back in the day, there was GIF and JPEG. The problem was, GIF was patent-encumbered, and thus, GNU, in particular, refused to implement it, and others did implement it, at their own risk. There was much furor over it -- campaigns against GIF, threats to sue people writing GIF software without paying a $5k fee (at least) for the patent...
Two things happened.
First, the free software community invented PNG, which is like GIF, but better in absolutely every way, except that old versions of IE didn't support it without a plugin, and new versions still don't support it as well as Firefox. Basically, PNGs use a different but better compression algorithm, support all the features GIFs do and more, and are pretty much the only image format you will ever need for lossless images. (If your image is really that big, use Jpeg.)
Second, the GIF patent (actually a patent on the compression involved) expired, way back in 2003. So, we can now use GIFs if we really want to, even though they've been completely obsoleted by PNGs. There's now no legal or convenience reason not to use GIFs, only the technological reasons -- and on technological merits alone, GIF loses. Hell, I do HD-DVD development, which is kind of Microsoft's baby, right? We use PNG images pretty much exclusively. I think the spec might support JPEG, but I doubt it supports GIF.
So, if mono is really doomed to patent bullshit, we need to pull that off again -- invent something like PNG, get it supported in Firefox. I'm not sure we can do it this time, though.
But sorry, (X)HTML5/CSS3/ES4 is not that. In part, it's not that precisely because web standards people don't take your attitude -- each of those components try to be as backwards-compatible as they reasonably can.
Don't thank God, thank a doctor!
That's only one aspect, which is IE's lenient parsing. That doesn't stop M$ from implementing HTML and CSS fully.
And it doesn't address my argument of advocating closed standards. We all know M$ wants to control the web, and we all know how they let their browser rot for almost 5 years because the competition was crushed.
The model you're advocating is broken. No website can be trusted, and IE's model was broken from the start. Web browsers should be relatively secure from the start. They should never expose themselves. Only visiting trusted sites doesn't cut it; trusted sites get hacked with malicious code. The answer is secure browsers.
Yes, let's get the US government in on this, they'll surely fix it.
Who should be the ultimate arbiter of JavaScript's future? Obviously Netscape, the company that invented it.
Since Netscape is no longer with us, MS should obviously inherit its rights. It's traditional and customary: you kill someone, you get to keep their possessions and cast their votes.
I am sure that there are many other solipsists out there.
Because by trying to be backwards compatible, and they'll have to be backwards compatible no matter who wins the pissing match, it's just inevitably going to lead to more browser bloat.
Quite right, Perlscript is the only way forward.
"None are more hopelessly enslaved than those who falsely believe they are free." -- Goethe
If you wanted to include an external *.py script, then yes it would be easy to control the whitespace and indenting as you would have the entire file created ahead of time.
But a lot of times your client scripting code is generated dynamically as a result of code running on the server (through Java, PHP, ASP, etc.). Often, these languages (especially tag-based languages like PHP or JSP) insert whitespace between different tags and it gets difficult to control their output precisely without doing works around the language. If that happens, your server script could put more or less whitespace than you intend into the dynamically generated *.py that would then execute incorrectly in the browser.
This gets even worse if your server code is not all generated in one block, but is assembled by a number of small blocks (like Struts/Tiles) as the small template that you are modifying may be included by another block (which is included by another) and if the indenting changes at the top level, you'll need to know and go find it in all the child levels to modify it.
Ever look at the source HTML to a lot of dynamically generated sites and wonder why there are odd patches of whitespace? Since it isn't (for the most part) significant in HTML, existing web server-scripting technologies have been built without necessarily caring about what it outputs. To suddenly need to care would mean re-working a whole lot of other tech just to make it work.
I'm not knocking Python or even its whitespace significance, but it definitely would introduce a huge problem for browser read scripts that weren't statically generated.
The only practical outcome of this clash is that it wouldn't benefit web developers at all and all development will be stuck at the current level if portability is to be maintained.
An evolution of the language would help, but it should be backwards compatible.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
I really don't care about the implementation details, as long as they maintain excellent compatibility with legacy Javascript. Whether I have to write , who gives a damn!?!
-Billco, Fnarg.com
It's been a long time since I was doing hardcore HTML myself. A sibling post mentions two specific tags. And while I would probably concede that the core HTML tagset is mostly supported, they added in all kinds of quirky layout weirdness, as well as kludgy hacks to compensate for sloppy HTML coders. End result is that a lot of standard and valid HTML pages would either be totally broken or just look weird in IE, and a lot of pages that look perfectly fine in IE look like a table barfed up its lunch in Firefox and it's cousins, or Opera. This is generally a lot better than it used to me, and a lot of it was because of weirdness in their CSS and JavaScript implementations, but I used to see it often enough before CSS was in vogue.
"I'm a Laver, not a Phyto[plankton]"
If you actually take a look at the spec, or if you have spent any amount of time programming actionscript in Flash CS3, you will no doubt have noticed that, with some exceptions, such as JS's dynamic properties, ES4 is basically Java, but where the types are defined as such: var x:int, y:string instead of int x and String y.
The "extra features" part I mentioned was actually me thinking about how great it would be to get that one extra feature in Javascript plus the ability to enforce a certain inheritance model (just for consistency within one project). This all got in to my head after listening to Bruce Johnson talking about GWT on Technometria (and fwiw I thought he said "static typing").
more of the same on Twitter.
Its not a technical battle, exactly - ES4 takes a lot of what's good about JS, from an advanced lanaguage perspective, but loses a lot of some of what makes it good as a lightweight language (IMHO). Which is fine - its increasingly not used as simple glue...
I say not a "technical battle" though, in that Yahoo and MS (or at least their reps on the working group) just seem to believe its not Javascript anymore: The analogy here would be if the there was an attempt in Java's early life to call it "C++ Edition 2". I kind of agree on the merits of that argument, but (though I might change some of the, well, changes in ES4) think that the "open web standards" coalition really needs to go this way *directionally* to compete... more thoughts on this in my JS flame war blog post from a few days ago.
graphically speaking
That sounds like sarcasm, but I don't understand why you think it wouldn't work just fine.
http://outcampaign.org/
K&R C didn't have function prototypes or a lot of other important things. ISO C99 was a massive improvement in standardization over ISO C90.
C++ and C# are not incremental updates of C, they're different languages.
http://outcampaign.org/
Given Google, the rise of Firefox and to a lesser extent Opera, and the growth of new middleware vendors, the paranoid cry "MS wants to control the web" seems rather farfetched to me. THe web is far too large and has too many actors for MS to try and control it.
Treating all web sites equivalently is inappropriate security policy. The question is how do you implement a differentiated fine grained security policy to match your risk and benefit issues. Zones are useful, but too coarse. I have approximated it by using Zones with IE, Firefox with fine-grained NoScript policy, and Opera as a static text renderer.
Thats not accurate as w3schools is a site for those who want to learn html and probably half use both browsers for compatibility.
Grandma uses what comes with her computer and other sites its more like 90/10.
http://saveie6.com/
Very nice language!
...) ... much, much more!
* Iterator protocol (including StopIteration exception)
* Generators (via yield statement)!
* List comprehensions!!
* String slicing
* Native datatypes (Vector, Map,
* Generic function templates
* Classes!!!
* Control over initialization
* Type-reflection
* Clear module and namepsace systems.
* Interfaces
*
What's missing:
* contract programming (pre/post-conditions and invariants)
* built-in unit-testing
* literate (in-code) documentation
* keyword arguments (but they've added var-args at least)
On thing I don't like:
* dropping "return" at the end of short functions. That does not improve clarity at all.
I'm not sure it's so smart to put all this in a browser language, but it's really a great language definition.
No doubt. I printed a copy so I could read it on the train... schlepped it to work/to home for two weeks... what a waste.
Then I found something far better... a CPAN project that implements a Javascript parser, using a YACC-like, Javascript 1.5 compliant syntax definition. Sweeet!!
O lord, bless this thy holy hand grenade, that with it thou mayest blow thine enemies to tiny bits, in thy mercy.
Really? Can I get a link? That would have been godsend last summer.
EVERYDAY IS CATURDAY
Firefox js is slow, maybe by design.
My javascript game HylZee runs very slow on firefox.
I'm not so sure that I'd trust these guys to specify a new version of js.
Hey don't blame me, IANAB
Sure: http://www.corion.net/perl-dev/Javascript-PurePerl-0.09.tar.gz
This did not come from cpan.org, I misremembered, though the authors ought to post it there. Came from here: http://www.corion.net/perl-dev/.
That said, depending on what you're doing w/JS, CPAN's worth a look. There are a ton of new JS projects up there in the last six months, including what looks like a javascript interpreter! (Take that, Rhino!) Suggest searching CPAN, there are a lot of exciting new JS projects.
cheers...
O lord, bless this thy holy hand grenade, that with it thou mayest blow thine enemies to tiny bits, in thy mercy.
I guess so. I always assumed they named it javascript because they were trying to be loosely java-like in the syntax of their scripting language (not that they succeeded in doing so anyways).
11*43+456^2