MS, Mozilla Clashing Over JavaScript Update 521
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."
If you're in there futzing with the code why not.. (Score:2)
About Silverlight? (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
Even if it helps MS, I want Javascript to die, die, die. Now if you will excuse me, I have to go back to writing my 900-line "add a week to a given date" function in Javascript.
Re:About Silverlight? (Score:5, Funny)
function addOneWeek(startDate) {
var oneWeekInMilliseconds = 1000*60*60*24*7;
return new Date(startDate.getTime() + oneWeekInMilliseconds);
}
Re: (Score:3, Interesting)
I would love to see a good javascript replacement. I don't like javascript and find it kind of nasty to write in. I just don't want it to be under the control of Microsoft, Apple, or Adobe.
Re: (Score:2)
Re:About Silverlight? (Score:5, Insightful)
Re:About Silverlight? (Score:5, Insightful)
Those are actually Brendan Eich's words. The extended commentary from which that comes is over here [mozilla.org].
MS do indeed want to close the internet, and the name of the game is "patent encumberance." It's going to be too hard to lock up JavaScript, so they don't want to play with that anymore. They need to have everyone investing in a new MS-proprietary, patent-encumbered language.
Re:About Silverlight? (Score:5, Insightful)
JS as a language is not fundamentally broken!
Re: (Score:3, Interesting)
Another javascript code monkey here. I think we all agree that fundamentally, javascript is quite a nice language. The point I think the GP was trying to make is that while the language itself is nice, the incompatabilities between the browsers, stupid APIs like the DOM, and other similar aspects mean that it would be easier to just start from scratch with another language where all of this goes away.
While there is nothing technically stopping us from drastically modifying javascript, the problem is that a
Re: (Score:3, Insightful)
By "you," are you referring to me, the person who summarized something that I thought was an interesting take on the issue, or to Haarvard, the person who actually made the assertion and discussed it in detail?
Re:About Silverlight? (Score:5, Informative)
And you are precisely echoing all of the lies that Brendan discredited in his post. There is absolutely nothing about ES4 that will break ES3. Nothing. Yet you (probably quite knowingly) propagate the falsehood that it will.
Re:About Silverlight? (Score:5, Insightful)
Because the story being discussed here isn't about Adobe lobbying a standards body in an effort to hold back adding new functionality to an open standard that could provide an alternative to closed add-on technologies like Silverlight and Flash.
If it was, people would be bashing them for trying to push the dominance of their proprietary solution by holding back standard, non-proprietary technology in the exact same way that Microsoft is being criticized here.
Microsoft wasn't criticized for having Silverlight, they were criticized for the manner in which they were perceived to be promoting Silverlight.
Yes, they are.
That's not what the dispute is over. The dispute is over whether Release 4 of ECMAScript should:
1) Include major new functionality, or
2) Include only minor new functionality, with major changes outside of the scope of the standard and left for other languages (either proprietary or part of different standards efforts.)
The first position favors substantial extensions to non-proprietary, freely-implementable standards for the web. The second does not.
A new version of a standard doesn't impose costs; no one is obligated to support the new version. ECMAScript Releases 1-3 won't stop working when a specification for ECMAScript Release 4 is released.
OTOH, more features in the standard means more that can be done within the scope of the standard and without non-standard, proprietary alternative technology.
New standards, even ones that aren't backward compatible, don't break old standards. ECMAScript 3 implementations don't break just because there is an ECMAScript 4 standard.
Re:About Silverlight? (Score:4, Insightful)
Multithreading! (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2)
Re:Multithreading! (Score:4, Insightful)
Disclosure: I am a web developer, but my use of javascript extends only as far as your "simple things like rollovers". (Well, not actually rollovers, that's done in CSS unless you're an idiot, but...) I am not a "proper" Developer. Hence, this genuine question:
To solve the problem of "the UI stalls the processing or the other way around" (which, funnily enough, I only ever really encounter right here on Slashdot), why would the script language need to provide multithreading to the script author (typical or otherwise).
Surely you could solve that particular issue by running Firefox-itself code in one thread, and on-page-javascript-or-whatever-script in another thread (or perhaps one thread per .js, or per site, or per tab, or whatever). You wouldn't need to actually let the script writer work in multiple threads, would you?
Re:Multithreading! (Score:5, Interesting)
Yes, you would. The basic reason is that while, conceptually, you're right that you could use your solution to prevent the browser from locking up, you'd still have to worry about the page locking up.
JavaScript code is generally only executed during events. These events include relatively minor things like scrolling, clicking, typing, or basically any form of interaction with the page. Now you could make the page code "smart" and avoid locking the page if there are no JavaScript event handlers interested in the current event, but you'd still potentially have issues where the page would essentially "freeze" until whatever long-running task completed. Since JavaScript events also fire when the page is unloaded, such a "freeze" could also prevent the user from navigating away from the page.
This leaves us with a potentially responsive browser UI, but a tab that can't be used until its task completes. This is still better than the Firefox situation (and, due to the way Firefox is designed, something that isn't going to change in Firefox for a long while), but still undesirable.
To allow the page to remain responsive while the page is doing some long-running task, you'd have to allow multiple threads so that the event handlers could run.
This is, in a way, the problem that "asynchronous" part of AJAX solves. It doesn't allow another thread to be run via script, but it does allow the page to send the task back to the server to execute, allowing the page to remain responsive while whatever long-running task completes.
I think a similar solution could work via JavaScript: instead of sending it off to the server, allow a script to be executed asynchronously. It would have no access to any information not sent to it when it was started (as otherwise the thread synchronization issues would remain), but it could run a task and then return a result.
There can be some argument over whether JavaScript should ever be used for a "long-running task" but the reality is that more and more web applications are finding that it makes sense to allow certain tasks to run on the client instead of burdening the servers. Most clients have the memory and CPU to spare, and it makes sense to use those resources instead of making the bottle-neck be the server.
Unfortunately the current solutions cause the page to become non-responsive while JavaScript executes and, in the case of poorly designed browsers, cause the entire browser to be non-responsive.
Re:MOD PARENT TROLL (Score:4, Informative)
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.
To me, this seems vaguely pointless for browsers (Score:5, Insightful)
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.
Re:To me, this seems vaguely pointless for browser (Score:5, Insightful)
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.
Just don't break things! (Score:4, Insightful)
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!
But the thing doesn't really work. (Score:2)
Not sure about this... (Score:3, Insightful)
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.
Re: (Score:2)
Re:Not sure about this... (Score:5, Insightful)
All current-day JavaScript will continue to work! Backward compatibility has been the number one goal during the development of ECMAScript 4. But Microsoft is scared - web applications have finally started fulfilling the original promise shown by Netscape, making the OS largely irrelevant. And so Microsoft is throwing up any- and all roadblocks it can think of, stalling for as much time as possible in order to create enough lock-in with WPF e.a. that they'll remain relevant. Understandable, of course - they're a company, trying to survive. But a really bad thing for the open web, and something which must be overcome.
Re: (Score:3, Informative)
Sorry, but this is BS.
Re:Not sure about this... (Score:4, Informative)
[...]
Syntax
Some identifiers that were legal names in ES3 (let, yield, cast, is, and a few more) are keywords in ES4. Other keywords in ES4 were future reserved words in ES3, and correct ES3 programs do not use them (class, interface, public, private, and many others), though some implementations allow them to be used as names. Sometimes the new keywords are contextual and can continue to be used as names, but in general an ES4 implementation that must be able to process all ES3 programs must be told which dialect--ES3 or ES4--it is looking at, so that it knows whether to treat these identifiers as keywords or not.
The mechanism that supplies the dialect information will depend on the environment. In a web browser the information comes from the MIME type of the script or from a version parameter on the SCRIPT tag in the document. New web pages that choose to use ES4 will have to specify the dialect.
np: Savath & Savalas - Tormenta De La Flor (Golden Pollen)
What's this all about? (Score:5, Interesting)
I don't see anything about closing the web or stomping on the little guy or anything like that. Where's that coming from?
Re:What's this all about? (Score:4, Interesting)
The existing Javascript/ECMAScript has a large installed base. Thus if you simply extend the existing spec in a backwards-compatible way, you allow developers to
keep using Javascript and upgrade with new features at their convenience. This keeps everyone using Javascript and *should* be a smooth and gradual transition.
However, if you switch to a require a separate mechanism to execute or a incompatible language, you force developers to rewrite their code in order to take advantage of the new features. This may be philosophically cleaner, but doesn't have the continuity benefit of the other approach.
Now if you're Microsoft, which situation do you prefer? The second one, because it fragments the installed base and therefore the influence of the platform you don't control. That gives you an opportunity to sell people on using your technology platform instead, since they'll have to rewrite either way to use new advanced features. But if they don't have to rewrite completely, it makes more economic sense for developers to stick with Javascript.
Now there may very well be other technical arguments too, but the above is why people are suspicious of Microsoft's arguments. After all, Microsoft knows very well the power of an installed base and the benefits of having control over common technology platforms.
Wishes (Score:3, Funny)
*sigh*
Re: (Score:2)
Wanna do more than dream? Leave <tables> behind. Unless you're displaying tabular data, of course.
Re: (Score:3, Informative)
Re:Wishes (Score:5, Insightful)
Is there a non-elitist reason to not use tables for a layout?
There are many. Let's try a few:
Is that good for a starter? I'm about out of time to spend on this...
I don't think that browser support for tableless layout is perfect. It's awful in older browsers, but getting better all the time.
In any case, it's the browser's job to render the standard properly, not yours to break the code for the browser. I find the middle-ground is to keep the layout pretty basic to get broadest browser support, and tolerate browser differences. I'd never promise pixel-for-pixel cross-browser support. HTML isn't designed to do that.
brand new language (Score:3, Interesting)
Of course this is all just speculation. Wouldn't be the first time I'd be wrong, still, the smell is really strong.
Unfortunately, Microsoft has a point (Score:3, Insightful)
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.
Re: (Score:2)
Microsoft's point seems to be that something new should be given a new name: "so we could continue supporting existing users as well as freeing the new language from constraints." That's a pretty good argument. In fact, I'd say it's an awesome argument.
Now, granted, this is probably being suggested so Microsoft can say "We support JavaScript/ECMAScript, but not XyzScript." Bah. But the point about naming incompatible things differently (or, inversely,
Re: Unfortunately, Microsoft has a point (Score:4, Interesting)
We already have a hypertext web that works very well with XHTML and CSS (not that they don't have their flaws, as you rightly point out, but they certainly work). What people are looking for with AJAX and Silverlight and what not is ways of delivering programs over the Internet in a secure manner, and Java already has that problem solved with both applets and Java Web Start. Java is also both an open specification and open source and it has a number of interpreters for almost any platform you can beg for, it has been around for far over a decade, and is very mature by now.
I don't see why people are not using Java. What's the problem? There are the obvious problems with Java being a horrible language to work in, but even so, it's probably still better than AJAX, Silverlight and Flash.
Microsoft appears to be spreading FUD (Score:5, Insightful)
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 [burningbird.net] 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.
Re:Microsoft appears to be spreading FUD (Score:4, Insightful)
How come IE uses "innerText" and Firefox uses "textContent"? Right there is a little compatibility function nearly every single Javascript in the world needs to write to work correctly.
Why is there no "GetElementsByClassName?" Another function nearly every Javascript needs.
How come the various "geometry"-returning functions have some baffling results? How come it's so hard to answer basic questions like, "did the user scroll to the bottom of the webpage?" What the hell is a "userAgent" anyway? Does the measure of it include toolbars? Status bar? How come the screen functions return different results for IE and Firefox on multiple-monitor systems? How come the screen functions don't even *support* multiple-monitor systems?
Why does Firefox insert blank text nodes into the DOM while IE doesn't?
How come my Javascript can't tell if a TextArea has text selected or not?
How come the internationalization features suck so much?
Why does "XMLHttpRequest" have such a strange name? Are acronyms supposed to be in all-caps or not, because that function shows it both ways.
There are a hundred problems, not necessarily with Javascript, but with Javascript's interaction with the DOM and browser. I think it's clear that both IE and Mozilla are right in that *something* needs to be done. Whether it's a new language or a new direction for JS, I dunno. (I like the language itself, for the record.)
Re: (Score:3, Informative)
butterfly effect (Score:2)
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.
lets call it (Score:2)
I agree with MS (Score:2)
In Other Words... (Score:2, Troll)
I mean, and what the fuck is wrong with updating a fucking language? Christ, they've been doing it with C for the better
MS Trying to undo the Outlook Web Access Mistake (Score:5, Interesting)
MOD PARENT UP (Score:4, Insightful)
STOP OVERSTATING MICROSOFT'S CONTRIBUTION (Score:5, Insightful)
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 [yafla.com], 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.
Language Plugins (Score:3, Interesting)
Who needs Silverlight? (Score:4, Interesting)
I agree (Score:3, Interesting)
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.
Seriously, MS has it right (Score:3, Insightful)
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!!)
.NET for client-side script (Score:3, Insightful)
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.
Re: (Score:3, Interesting)
Re:Either way... (Score:5, Interesting)
Re: (Score:3, Insightful)
I say IE and Mozilla battle it out, release the product, and may the best man win.
Unfortunately, if that happens, the best man won't win. Firefox doesn't have NEARLY the market penetration required to actually stand toe to toe agains IE in something like this. Thats why there are "standards" out there that nobody complies with; because IE doesn't.
:).
There needs to be a third pary arbitrator here.
And hopefully that arbitrator tells them all to just STFU up and use python
Re: (Score:2, Insightful)
Sure (Score:3, Interesting)
Re: (Score:3, Funny)
I believe I have spotted the flaw in your argument.
Re: (Score:3, Insightful)
You know the same way Apple and Microsoft force you to get new computers if you want to run the "New And Improved With 25% Fewer(?) Gaping Security Holes Operating System"
But that would require organizing developers into some form of union.
Re:Either way... (Score:5, Insightful)
Yes, a language that parses whitespace like Python does would be great for client-side scripts run from a web browser.
Re: (Score:3, Funny)
<script type="text/python">
from template import *
who='Slashdot'
if not (who == ""):
s=Template('Hello, $n!').substitute(n=who)
else:
Re: (Score:3, Insightful)
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,
Re:Either way... (Score:4, Informative)
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.
Re: (Score:3, Informative)
Re: (Score:2)
So I can't see MS having anything to do with it, unless there's some convoluted plotting going on.
Re: (Score:3, Insightful)
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.
Re: (Score:3, Insightful)
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 an
I love designing to multiple standards (Score:2)
Re: (Score:2)
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
Re: (Score:3, Informative)
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
Re:Either way... (Score:4, Informative)
Re: (Score:2)
Re: (Score:2)
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 ECMA [wikipedia.org]Script, and not NISTScript or ANSIScript.
Re: (Score:2, Insightful)
Re: (Score:2)
It only makes sense for all browsers to support it.
Re: (Score:2)
On the other hand, I would really hate to start seeing VBScript used in webpages.
Ug. (Score:5, Insightful)
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.
Re:Ug. (Score:4, Insightful)
Re:Why not both? (Score:4, Insightful)
Re:Why not both? (Score:4, Insightful)
Re: (Score:2)
Seriously? (Score:3, Insightful)
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.
Re:Why not both? (Score:5, Insightful)
Re: (Score:3, Insightful)
Or they could create a very basic, low level bytecode interface to a browser and the DOM and then have any scripting language JIT compiled to that low level representation... at the script-standard bytecode-native compilation stage you can use program transformations to move towards your browser's native structure
Go one step further and provide some helpful jit compilation operations and somebody could just say <script language="{http://www.me.com}myscript}"< and the browser could download a jit com
Re:Why not both? (Score:5, Informative)
Go check it out and decide for yourself.
Re: (Score:2)
Re:Flash-bashing equivalent (Score:4, Informative)
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. =(
Re: (Score:2)
Re: (Score:2)
How about starting over from scratch? (Score:3, Insightful)
Re:How about starting over from scratch? (Score:4, Insightful)
- have know been widely field tested, their strenght and shortcomings are known, there are hundreds of implementation of them that have been heavily tested and debugged, this is extremely precious
- it is widely adopted, switching represents a huge cost for the whole industry (not only it pro but all the people in the world who live by selling html developpement)
While starting from scratch looks pleasant, for big things (and html is *big*) gradual changes are more appropriate.
Re:Opera is the Ron Paul of browsers (Score:4, Funny)
Re: (Score:2)
but you never see mention of it in the "real world," and this article is part of that trend. Why?
I think it depends on where you look in the "real world". I've seen Opera mentioned a lot, just not always when it comes to the desktop. While I use Firefox on my desktop and laptop, I use Opera on my PDA, cell phone, and Wii. Last I checked, IE and Mozilla/Firefox weren't available for any of these devices (at least, with respect to the devices I own).
Also, this article is focusing on the discussion between
Re: (Score:2)
because the add-ons for Firefox are simply too good to pass up. The rest of the population doesn't know about either Opera or Firefox and just uses the pre-installed IE on their Windows machine. Seriously though, the add-ons for Firefox add a TON of value to the Mozilla platform. Is there anything like the range and quality of available add-ons for Opera? I don't know, but I would bet the answer is probably
Re: (Score:2)
But can anybody trust MS on anything?
History has proven that you can't trust MS.
Re:Forgetting that it's Microsoft for a minute... (Score:4, Interesting)
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).
Re: (Score:3, Informative)
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 inherite