Slashdot Mirror
Google Brings Chrome Renderer, Speedy Javascript To IE
A month after we discussed Google's bringing SVG to IE, several readers let us know that Google is expanding the beachhead by offering Chrome's renderer and speedy Javascript execution in an IE plugin. This effort is in service of allowing IE to participate in Google Wave when that technology's preview is extended in a week's time. The plugin, currently in an early stage of development, is called Google Chrome Frame.
and IE?
...if Google is going to pull the embrace, extend and extinguish routine on Microsoft. I hope I live to see that day.
Ballmer must be about ready to throw the *desk* this time. Google is taking the initiative to 'fix' their competing product. The plot thickens!
Funny may not give karma, but +5 Informative never made anyone snort coffee out their nose.
I'd use this new browser to watch Steve's fit when hears google is subverting IE.
Google are taking the matter into their own hands and actually putting resources towards improving IE, because they know that MS will not do it in any reasonable way.
Last I checked, webkit browsers other than Chrome for Windows have some pretty hefty security holes and dire vulnerabilities. The question is whether google is dropping in a tiny webkit panel or a full chrome instance within this tab. Their implementation here is very important because they may end up simply shattering IE 8's security model and leaving an exploitable hole in users' systems.
Google better take this very seriously before advertising this on their search and mail pages, etc.
I think I see Google starting a new tag... "letmefixthatforyou"
"Most people, I think, don't even know what a rootkit is, so why should they care about it?"
First they ignore you..
Then they laugh at you...
Then you make plugins for their browser.
A lot of the fancy shit you see on the internet today is javascript, the reason much of it wasn't there before was because javascript was so damn intensive to execute. It's nothing like machine code, it's not even like repackaged interpreter language. Javascript is run straight from the script, and it is a terribly inefficient way to do things, but it is much easier to distribute along with HTML.
JS isn't exactly the future of all websites, but it's certainly easier to work with for light effects than flash.
I'll show you why you want JS to run better... go to ebay.com and press CTRL-F5 and count how long it takes to load. Then, disable Javascript execution and press CTRL-F5 again. I'm sure someone else can suggest a more JS intensive site, but that's all I got right now.
"Most people, I think, don't even know what a rootkit is, so why should they care about it?"
It's the 8 hours a week that really powers Google's innovation. For those who don't know, Google employees are supposed to dedicate 8 hours a week of company time to some personal project. Those 8 hours have been responsible for Docs, gMail, Maps, Earth, code search, scholar search, etc., etc. People have ideas, give your employees a chance to explore them a bit and you might be surprised what they come up with on their own.
Facebook would be a good example of this. In IE, rendering time allows the full page with images to be loaded before displaying it. I used to have up to 70% of my CPU eaten by IE7 trying to display the page (just to resituate, this was on an Eee PC 701). Chrome on the other hand displays the page much faster, and images are still loading after the page render. CPU utilization was also lower, hovering around 20%. I did not time both browsers and I don't have my Eee anymore. But I think it is (or was) a good example of a Javascript heavy website. Gmail is also a good example of a Javascript-loaded website.
Google is the wind beneath my wings.
Adblock+ and NoScript is win :)
I concur, but it's a depressing state that it should ever even be necessary to add to the work necessary to do less work in a realm where usability should be paramount.
"Most people, I think, don't even know what a rootkit is, so why should they care about it?"
HTML 5 is not done yet by any means. I wouldn't even say they have what you might call a working draft.
In Firefox, this page shows "W3C Working Draft" along the left side.
Microsoft isn't necessarily behind so much as they are not working off the Mozilla and Apple webkit mailing lists when they implement features to their browser.
A lot of the features that Acid3 tests aren't new proposals in any sense; they've been around for years. WebKit (basis for Chrome and Safari), Gecko (Firefox and SeaMonkey), and Presto (Opera) all score above 90/100, which handily beats IE 8's 20/100.
"IE isn't done till Frame won't run."
I'm sure someone else can suggest a more JS intensive site, but that's all I got right now.
Slashdot.
Perhaps not as intensive as ebay.com, but without javascript enabled, Slashdot loads faster and generally works better. You could say it's "less filling".
The only people I could see using this are people who aren't allowed to install / use a different web browser. And I highly doubt IT departments that don't allow third party browsers will allow this plugin to be installed. So this seems like a gigantic waste of time.
I run Fx as well, but I'm not very happy with it. Chrome is a pleasure to use except for the lack of adblock (and a working osx implementation). Worst with Fx right now (besides feeling a bit slow at times) is the way its tabs work. It is so much worse than the competition it's embarrassing (drag between windows and such).
Google is working on these plugins to ensure their platform has the broadest install-base and give them a way to influence current or future compatibility issues.
This is a pretty smart move for them to maintain and grow their reach. Also - as long as they keep their plug-ins open - a positive move for whole web-app, software as a service 'movement'. (I'm not sure if it's considered a 'movement').
Boy, the people at Microsoft must be pissed about this. When Bill Gates "discovered" the internet back in 1994, the first thing he realized is that eventually people were going want to replace Microsoft desktop software with programs that run on the web.
So Microsoft's strategy ever since then has been cripple IE to keep that from happening. That's why IE innovation came to a screeching halt once IE crushed Netscape. And that's why IE runs javascript so poorly, it's not due to bad programing, it's a strategic decision.
Now Google comes up with a new technology, Wave, that out-performs a whole slew of desktop applications, and to help it out adds a plug-in that uncripples IE. What do you bet there will be an IE update in a few weeks that blocks it?
Is there an ongoing "my Javascript is faster than yours ha-ha" competition in the browser market?
Uhm... Yes?
Javascript is the one client-side programming language that is always guaranteed to be there, on anything that can reasonably be called a browser. Anything that can be called a web application is probably at some point going to care about Javascript speed. And faster Javascript opens the door to some things you might not have thought were possible in a browser.
When looking for a browser, it isn't just speed people are looking for; They want security
Chrome runs each tab in a separate process, meaning it can theoretically sandbox each tab using standard OS techniques -- for example, on Linux, my Chromium does seem to be running things as an unprivileged user, and chrooting them out of the way.
Other browsers are playing catch-up.
add-ons, customization
The Chrome extension API isn't finished, but it's just Javascript and HTML. It's the kind of thing that a web developer could learn in an hour. It won't run Firefox extensions (yet), but it seems likely that it'll have plenty of extensions Firefox won't, just because of how much easier it is to get off the ground.
If I want top speed, I'll use chrome. If I want an all-around great browser, I'll use Firefox.
We don't care, this isn't about you. (And for what it's worth, Firefox is working hard to improve javascript, security, and reliability to match Chrome.)
This is about the 80% who still use IE, and about the rest of us not having to care anymore. I can build a web app that works in Chrome, Firefox, Safari, Epiphany, Galeon, Konqueror, Opera, in every browser, ever, with minimal effort -- figure an extra 5-10% development time to make it work on browsers other than the one I develop for. IE will fuck it up and add easily 20-50% to my development time.
Doing it this way means that at some point in the future, hopefully, something like YouTube will force IE users to either switch browsers or install this plugin -- at which point, I can forget that IE exists, and let it all melt away like a bad dream.
Don't thank God, thank a doctor!
IE's not done till Chrome won't run!
The race isn't always to the swift... but that's the way to bet!
Toyota and Ford could easily work together, and haven't been averse to the idea in the past..
In Australia, under government-sponsored reforms intended to reduce duplication of effort and make the local car industry more sustainable that started in the mid-80s, there was a lot of collaboration between the local GM subsidiary and Nissan and Toyota. The Family II engines, as used in a number of Holden and Opel and Vauxhaul models (sorry, not familar with what they went into in the US), were sold to Nissan for use in various locally-built models. Locally-built Toyotas were badge-engineered and sold as Holdens to fill a small-to-mid-size niche. Holden's Commodore was at one point badge-engineered to become the Toyota Lexcen.
If Ford asked Toyota for engines, they'd probably get them. And that goes both ways.
LOL! Your a retard, nice Troll.
Chrome sure has things FF doesn't (Even though protected tabs and multi-threading JS are coming in new releases), but FF has things chrome doesn't as well (The add-on store).
Nobody gives a flying fuck if Chrome loads pages a minuscule amount faster than FF.
Well, if the page isn't mostly Javascript, that's not true. In my recent personal testing, prompted by a desire to leave FF behind, I found that only Opera (seriously) loaded html faster than FF. IE was tied with FF. Chrome and Safari made Javascript sing, but were much slower at loading and scrolling (my pet peeve) html.
"I zero-index my hamsters" - Willtor (147206)
Firefox apologists:
"Unless you browse the internet non-stop, all day, this won't be a problem."
IE apologists:
"Unless you browse dangerous sites, this won't be a problem."
The irony is hilarious.
Opera is faster than FF, which is faster than Chrome, for loading Slashdot, news sites, blah blah etc. I guess I don't do much with Javascript, but when I tried to switch to webkit I couldn't get past the sluggish html rendering.
"I zero-index my hamsters" - Willtor (147206)
First, sneak your interface into the browser, then you could change the Windows desktop environment, then change the kernel and before you know it we're running 100% open source software.
"Opera is faster than FF, which is faster than Chrome, for loading Slashdot, news sites, blah blah etc."
Go away idiot.
What is wrong with them exactly.
Drag into a new FFX window to move it into a new FFX window or onto the taskbar to create a new window with that tab.
Frankly if this is your biggest complaint then you need to take a teaspoon of concrete and harden up. FFX will do what the vast majority of users want to do and does it good enough for the vast majority of users.
Calling someone a "hater" only means you can not rationally rebut their argument.
Why I'm talking about the Nissan Silvia S15 of course!
They hide behind their flaky "emission" excuse, but you know they give a rat's ass about those. It's all just an excuse!
Google are taking the matter into their own hands and actually putting resources towards improving IE, because they know that MS will not do it in any reasonable way.
Yeah, in other words, pretty much what everybody else has been doing over the last decade with their collection of hacks, their CSS reset sheets, and their javascript libraries.
One wonders what the cost of the lost productivity involved in working with the deliberately broken portions of Microsoft's software is... or how much more productive the industry as a whole would be if IE faded away...
Tweet, tweet.
This whole thing should be very embarrassing for Microsoft... but apparently it isn't. Microsoft is co-sponsoring a conference about SVG, which is being held in Google's Mountain View complex, of all places. That in itself is disturbing enough, but to think that the one company that's prevented SVG from gaining traction on the web is now pretending to be interested in SVG (as opposed to promoting their Silverlight tool as the only *real* solution) is, excuse me, fucked up.
If they really want to help the advancement of SVG, they should finally release a browser which implements it natively. Apparently every other browser vendor can do it. For IE, at the moment, we have to rely on a fragile JavaScript/Flash workaround provided by Google.
I'm really not ranting about Microsoft just for the fun of it; I'm usually pragmatic, bordering on stoic. But I (like many others here) have spent weeks and months trying to work around Microsoft products' shortcomings, and this kind of hypocrisy is making me angry.
CJ
Ah, arrogance and stupidity, all in the same package. How efficient of you. -- Londo Mollari
... if Google Chrome will become something like this or this some day? I mean, it will expose all cookies, history and stuff including all your pr0n when people use IE to surf Google?
For the record, I too have observed that Opera 10 renders slashdot significantly faster than firefox 3.5, with no adblocking and all default scripting options with both.
Firefox is a turd in comparison to Opera's snappyness.
"His name was James Damore."
HTML 5 is not done yet by any means. I wouldn't even say they have what you might call a working draft.
"The publication of this document by the W3C as a W3C Working Draft ...".
(And the first public working draft was published Jan 2008).
Microsoft isn't necessarily behind so much as they are not working off the Mozilla and Apple webkit mailing lists when they implement features to their browser.
I don't work off these lists either, but I'm aware of a numer of high profile parts of it, say, the Canvas element. I'm sure Microsoft is too.
IE still has a very enterprise-oriented development cycle
Is this what we call their six year hiatus from actually working on their product?
In the late 1990s they showed they were quite capable of aggressively expanding IE's features, including new if raggedly incomplete support for emerging standards, when they decided it was in their interest to do it.
the bleeding edge feature explosion we see in most open source browsers.
A lot of the features discussed for HTML 5 have had visible implementations for 3-4 years. You could call them bleeding edge in 2006, maybe 2007. 2009? Not without looking pretty silly.
I don't think IE needs to catch up so much as Microsoft simply needs to release an unstable browser in addition to their platform browser if they want to compete with the rest of the non-standard "standards" cult.
The competing products seem to do just fine at keeping a comparable level of stability along with the pushing the envelope. In fact, given how much Opera, Mozilla, and Safari, have been able to do with resources that are orders of magnitude smaller, there's really no excuse.
Except of course if you're talking about CSS 2.1, where it is the best.
Can you defend this claim? Because based on my experiences *using* CSS over the last 7 years, there hasn't been a time when any version of IE could even claim they weren't maddeningly, brokenly worse.
Tweet, tweet.
This is Google at its best, IE is the lowers common denominator when it comes to browsers and Microsoft knows it.
Microsoft is not fixing IE to slow Google down in the WebApp space.
This is Google's shots across the bowel. Basically fix Microsoft or we will.
Chrome was shot one, develop a browser that's half done.
That does the things IE can not do, speed and standards.
This is shot two, A plugin which users hate installing, I need a plugin to use Google Wave? How come I don't need it with Firefox,Chrome,etc?
I bet this will be heavy on Google branding just to rub it in.
Shot three ChromeOS, This is just to piss off Microsoft, Google is becoming Microsoft to beat Microsoft, A one stop solution for software and the OS is just the perfectly integrated tool.(I know this was announced before the plugin)
Google are stepping on all of Microsoft's toes, browser, mail, OS, Office.
It's the marketing war of the century and Google hates Microsoft, the only other company I have seen with a blind hatred of Microsoft was Sun, but Google could win.
Google is the Do No Evil, relaxed, community giving, freebie galore, cool web tools company.
While Microsoft is the stuffy, evil empire,broken software,lax security,uninventive company.
Microsoft took out IBM and Google will take out Microsoft (offcourse they will live on is some form or another, but a shadow of their former self's)
Microsoft is the new IBM big, blotted, slow thinking, and Google is the new Microsoft a small company with inventive ideas.
Google will become the next evil empire and in 15 years Google will be on the road to a slow death at the hand on a new company.
It plays out like a Greek myth, The father will kill the son and so on.....
IE is only supporting finished standards.
SVG was a finished recommendation before IE 7, yet Internet Explorer 8 doesn't display SVG without a plug-in.
> Google Chrome Frame is an early-stage open source plug-in
But where can I get the source code of the plugin itself? (I mean, not the rendering engine for this plugin, but the IE plugin part that glues it to IE)
Can't find it in the Google Code page.
The Chrome extension API isn't finished, but it's just Javascript and HTML. It's the kind of thing that a web developer could learn in an hour. It won't run Firefox extensions (yet), but it seems likely that it'll have plenty of extensions Firefox won't, just because of how much easier it is to get off the ground.
The fact that Chrome extensions will be based only with HTML + Javascript means that it will be less flexible and less powerful than Firefox extensions which is based on XUL + CSS + Javascript + DOM.
The plugin runs as an opt-in, so existing sites will still use the native IE renderer and javascript execution. Therefore, it doesn't need to support IE plugins.
Now if only they bundle this with manufactures.
I'm amazed that nobody else has commented on how huge a deal this is. Microsoft are *not* going to be happy.
Google have basically said that it's too much of a nuisance to develop for IE. They want to focus their development on a single web platform, and released a tool to allow them to do that.
But what nobody seems to be mentioning is how this could transform the browser wars. If Google take the logical next step of releasing this as a general purpose development tool, there's no need to develop for IE any more. Web developers can just optimize for Chrome and run the code on either browser. And that negates Microsoft's advantage of having the dominant browser, it breaks the vicious circle that is Microsoft's browser monopoly:
Microsoft's 90% hold on desktop browsers -> Developers have to focus on IE -> Users and corporations use IE
With Googles plugin, that 90% hold on the desktop becomes far less relevant. Google can give developers the choice of developing for their browser, without reducing the available user base. After all, Microsoft have spent years training users to install any ActiveX control a website needs, what end user isn't going to trust a plugin from Google? :-)
This gives the market the freedom to choose to develop for Google Chrome without worrying about Microsoft's majority share on the desktop.
And make no mistake, that's huge.
I wonder what percentage of IE6 users have the authority to install an ActiveX control on their system.
FireFox have like serious issues when dealing with JavaScript. I use it in Windows and Linux, just awful for some stuff i use.
For example, try http://en.wikipedia.org/wiki/List_of_j%C5%8Dy%C5%8D_kanji
If you try to sort by the first column for example (#), in Firefox it just stops responding and CPU is at 100%. This happens in Windows and Linux.
If i use Chrome, it takes maybe 2-3 seconds to sort everything? Even using the development snapshot in Linux for Chrome, just works, fast. So it is not the OS but the implementation in the JavaScript engine. I clearly see the improvement in other sites using AJAX and the like.
This sort of course is using JavaScript. And i doubt it is performance issues as i use an AMD Phenom II X4 955 which is a Quad-Core running at 3.2ghz and 4gb RAM. I really think that is ENOUGH processing power to sort around 2000 rows in a table.
Turns out that 100 mbit fiber is capped at 20 gigs per month. Time to move.
Doesn't it take about 50,000 years to use 20 gigs (GigaBytes) at 100 milli-bits per second?
"FireFox have like serious issues when dealing with JavaScript. I use it in Windows and Linux, just awful for some stuff i use. For example, try kangi If you try to sort by the first column for example (#), in Firefox it just stops responding and CPU is at 100%. This happens in Windows and Linux"
I just tried it in FF under Ubuntu running off a USB device and - not a problem - it sorted in just over a second. Where Java is problematical, it's usually a slow or buggy site, where everything is stuck waiting on a javascript to finish. That's why I use noscript.
Keep your friends close and your enemies closer.
If they slip this plugin with every Googleware installer 'in order for your computer to work with the software' then it's golden.
Here be signatures
I agree with the other response here. I'm running Ubuntu on a somewhat elderly laptop (AMD Turion, 2 meg RAM)... and it took approximately 3 seconds for Firefox 3.0.14 to sort your table. I don't know what your machine's issue might be.
Regardless, if you're unhappy with Firefox for any reason, real or imagined, then why use it? I think the whole point of this Google plugin is to "liberate" people who are trapped with IE due to company policy, or due to being too computer-illiterate to download an alternative browser. However, if a person is using Firefox already than neither of those two concerns apply... so there's no point in releasing a version for Firefox. If you like Chrome, and trust Google's handling of your data (this is the hang-up for me), then just use that and enjoy.
I'm probably going to sound clueless here, but what does XUL do that this doesn't? Because this is CSS+Javascript+HTML+DOM, so it's pretty much down to XUL vs HTML.
It's also got a large-ish positive effect for web pages -- for example, Chrome extensions use HTML5 local storage, rather than inventing its own dedicated storage API. This means that anything I need for an extension, if it's reasonable to do so, will likely be exposed to regular web pages.
And when I said "just", I mean that's only what's required -- though beyond that (so far), they seem to be talking about the plugin API. That is, if you need something HTML+Javascript won't give you, you could (for example) use Flash (ew) in your extension, just as you can in any webpage -- or roll your own plugin.
Don't thank God, thank a doctor!
Prepare for unforeseen consequences ;)
With XUL, you can basically gut Firefox programming (whether the GUI or the back-end code etc) without actually having to dive into the source code itself (C/C++). You can completely replace the download manager (like Download Statusbar), add features like mouse gestures (it will be very difficult to replicate FireGesture functionality with only CSS+Javascript) and more.
AdBlock Plus extension functionality can be duplicated, but I have concerns about its performance.
Flashblock should be easier.
DownloadStatusbar should be doable, although with many features missing such as virus scanning etc.
FireGestures mouse gesture extension will be very hard to duplicate. Or any other XUL-heavy extensions like Screengrab or god- forbid, Tab Mix Plus.
XUL is not only feature Firefox extension API has, it also has XPCOM. These two alone makes Firefox to become like a mini-operating system. XUL+XPCOM+HTML+CSS+Javascript+DOM combination is magnitudes more powerful than Chrome's HTML+CSS (limited from my observation)+Javascript combination.
Will Google allows developers to mess around with the the operation of the Webkit rendering engine or the JavaScript is something that I want to know. The API is still not final yet anyway.
"A lot of the fancy shit you see on the internet today is javascript, the reason much of it wasn't there before was because javascript was so damn intensive to execute."
Hell... NO!.
We use to avoid javascript for everything, but "decoration", so everything still work if a guy has javascript off.
Nowdays javascript is considered more or less "standard", and theres much more interesting that can be done with it, thanks to CSS and the AJAX object.
So using javascript NOW make sense, but using javascript a few years ago was a bad idea. Is still a bad idea to make a website depends on javascript for the sake of it. As there are people out here with NoScript and stuff. But nowdays we have tools and strategies to make websites with javascript and working for these people.
-Woof woof woof!
You can completely replace the download manager
Ok, this would be difficult -- at least, I don't know how to hook into something being downloaded. I also don't know how to hook into the local filesystem -- but then, I'd almost consider that a feature, as extensions can be limited in what they can access, meaning I don't have to trust an extension nearly as much to install it.
But then, downloads already happen in the status bar anyway.
it will be very difficult to replicate FireGesture functionality with only CSS+Javascript
...really? I doubt it -- you've already got mouse move and click events, and you've got the possibility to intercept an event anywhere on the document. What's difficult?
AdBlock Plus extension functionality can be duplicated, but I have concerns about its performance.
The one I developed works pretty well. Remember, this is Chrome.
Flashblock should be easier.
It is indeed very easy.
Or any other XUL-heavy extensions like Screengrab or god- forbid, Tab Mix Plus.
I'm not sure how to replicate screengrab.
However, at least some of the features of Tab Mix Plus should be possible -- there is a Tab API exposed to Javascript. Many of the features of Tab Mix Plus are built in -- like, undo close tab.
XUL is not only feature Firefox extension API has, it also has XPCOM.
There's my answer. Because XUL by itself is just UI markup, right? It's the API that's exposed to a firefox extension that is (so far) much better.
Will Google allows developers to mess around with the the operation of the Webkit rendering engine or the JavaScript
What kind of tweaks to Webkit?
And it can certainly mess with Javascript, to the extent that a content script is similar to a Greasemonkey script (but more isolated), so it can alter anything about that page, likely including other scripts on the page.
The API is still not final yet anyway.
True. But even in its current stage, it does prove one point which I don't think you've disputed:
It's much easier for me, as a web developer, to write an extension for Chrome than for Firefox. I've never really gotten off the ground with Firefox, but I wrote an ad blocker for Chrome in an afternoon, including learning to use the extension API.
Don't thank God, thank a doctor!
"Libertarianism: Rich wolves and poor sheep deciding who to have for dinner"
Fixed that for ya.
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
...really? I doubt it -- you've already got mouse move and click events, and you've got the possibility to intercept an event anywhere on the document. What's difficult?
Can you use HTML or Javascript or CSS to paint a mouse trail? Is there anything in the current version of the Chrome API that will allow you to capture mouse movement in high precision (DPI)? etc.
However, at least some of the features of Tab Mix Plus should be possible -- there is a Tab API exposed to Javascript. Many of the features of Tab Mix Plus are built in -- like, undo close tab.
Tab Mix Plus can save sessions, paint the tab with user-specified color, format tab title texts, can save tab opening order and can do tab mouse gestures (different one than FireGestures). These features are just some features that XUL allows you to do. Is the Chrome tab API has any functions for tab mouse gestures? This is not part of Firefox but is possible because of XUL (and XPCOM).
There's my answer. Because XUL by itself is just UI markup, right? It's the API that's exposed to a firefox extension that is (so far) much better.
XUL is for user interface just like you say. But a pertinent point that you should not forget is that Firefox uses XUL as the layout for its user interface while a peek at Chrome source code shows that it uses C++ or maybe C for its interface. Firefox allows you to create an extension that will radically alter the Firefox user interface as you wish, but Chrome will not allow you to do the same thing (unless I missed the memo that I will be allowed to use C++ to write Chrome extensions that will hook straight to the user interface). If Google give me the same freedom the way Mozilla gives to me, I can make an extension that will put the tab bar at the bottom of the browser window, or maybe a tree-structure tab column at the left-side of the browser? Or even erase the Google logo at the top-right of the browser? This is without having to have mess around with the source code at all.
What kind of tweaks to Webkit? And it can certainly mess with Javascript, to the extent that a content script is similar to a Greasemonkey script (but more isolated), so it can alter anything about that page, likely including other scripts on the page.
PrefBar is a Firefox extension that comes to mind when it comes to messing around with the behaviour of Gecko, that comes to my mind now.
True. But even in its current stage, it does prove one point which I don't think you've disputed: It's much easier for me, as a web developer, to write an extension for Chrome than for Firefox. I've never really gotten off the ground with Firefox, but I wrote an ad blocker for Chrome in an afternoon, including learning to use the extension API.
Whoa, you have written an ad-blocker for Chrome? If you can use the AdBlock subscription list that would be swell. The lack of ad-blocker is apparently the excuse many Firefox users use to justify not trying Chrome.
Can you use HTML or Javascript or CSS to paint a mouse trail?
The short answer is, yes.
The long answer is, you might need the HTML5 Canvas element if you're wanting some sort of line behind the mouse, as opposed to a series of progressively-more-transparent mouse shadows. And of course, Chrome supports Canvas.
Is there anything in the current version of the Chrome API that will allow you to capture mouse movement in high precision (DPI)?
Higher than pixels? Not that I know of, but I also can't imagine when I'd want to, or what kind of Firefox extension would do so.
Tab Mix Plus can save sessions
Yeah, I can do that. I can't necessarily save the state of each tab, but I can certainly save the URL, even the current values of the form fields.
paint the tab with user-specified color, format tab title texts
Probably can't do that yet.
can save tab opening order
What does that mean? The one reference I see to that is actually describing exactly how Chrome tabs work, by default. If that's what you mean -- that is, tab opening behavior -- that wouldn't be terribly difficult.
can do tab mouse gestures (different one than FireGestures).
How are they different?
I could certainly do mouse gestures over the page. I'm not sure I can catch mouse events that wander off into the tabs or navigation bar.
These features are just some features that XUL allows you to do.
Sigh.
Again: Are these XUL or XPCOM?
And is there any reason XPCOM couldn't be exposed to privileged HTML and Javascript?
Show me some XUL to illustrate your point -- otherwise, I'm going to continue with my assumption that XUL provides none of these benefits on its own.
But a pertinent point that you should not forget is that Firefox uses XUL as the layout for its user interface while a peek at Chrome source code shows that it uses C++ or maybe C for its interface.
Probably somewhat true, though not entirely. Opening a new tab currently shows a page called "new tab", which contains a list of recently closed tabs, along with thumbnail links to your most frequently visited websites.
Just for fun, if you've got Chrome installed, visit that page and hit ctrl+U. See? HTML/javascript. Same with about:plugins. Same with chrome://extensions, with a recent build.
Firefox allows you to create an extension that will radically alter the Firefox user interface as you wish, but Chrome will not allow you to do the same thing (unless I missed the memo that I will be allowed to use C++ to write Chrome extensions that will hook straight to the user interface).
You seem to be either misinformed or downright unimaginative about what an API could expose.
Let's pretend the Chrome UI is entirely C++, and let's pretend, for a moment, that there's no way (currently) to customize the settings dialog.
Now let's pretend we can write C++ extensions. What would the C++ API look like? I'll leave this as an exercise to the reader.
Go ahead, I'll wait. Build some sample applications. Use pseudocode, if you like.
Now, look at your API, and ask yourself why this couldn't be exposed to Javascript.
To take another, much simpler example: Webkit is probably written in C or C++, right? It's native code that parses HTML, and native code that generates the DOM, right? But I can manipulate the DOM with Javascript just fine.
And given that there just isn't that much UI -- that much chrome -- to Chrome, I wouldn't be surprised to see a more complete API in the future. As it is, the usual pattern for an extension that wants, say, a dialog box, is to pop up a new window pointing to some page inside the extension.
Oh, and yes, you c
Don't thank God, thank a doctor!
The short answer is, yes. The long answer is, you might need the HTML5 Canvas element if you're wanting some sort of line behind the mouse, as opposed to a series of progressively-more-transparent mouse shadows. And of course, Chrome supports Canvas. Higher than pixels? Not that I know of, but I also can't imagine when I'd want to, or what kind of Firefox extension would do so.
High precision mouse detection is needed so that. for example, you do not have to actually do a 90 degrees down-right mouse movements to close a tab. Else, a user has to perform the gesture several time just to get the command to execute. Kinda like Opera's early iterations of their built-in mouse gestures, which is harder to use than the version they have now.
can do tab mouse gestures (different one than FireGestures).
How are they different? I could certainly do mouse gestures over the page. I'm not sure I can catch mouse events that wander off into the tabs or navigation bar.
That's exactly what I am talking about. Can you catch mouse gestures (in Tab Mix Plus example, they consists mostly of mouse-click combinations) that is executed over the tab bar? FireGestures captures mouse gestures executed over the web-page, but Tab Mix Plus captures the ones executed over the tab bar. Really convenient when you have several rows of them. Of course, Firefox by its own do not have any stinking APIs that will allow developers to do that of course.
Sigh. Again: Are these XUL or XPCOM? And is there any reason XPCOM couldn't be exposed to privileged HTML and Javascript? Show me some XUL to illustrate your point -- otherwise, I'm going to continue with my assumption that XUL provides none of these benefits on its own.
HTML+Javascript combo cannot be used to access XPCOM. Javascript, yes. HTML, no (this is by design). Extensions that uses HTML usually does so only for presentation/display. And with most developers preferring to use XUL in the first place for such purposes (in Firefox, XUL is faster at compositing and displaying UI than HTML), it is rare actually to see HTML being used, after all, XUL can access XPCOM and HTML can't (well, not directly).
You seem to be either misinformed or downright unimaginative about what an API could expose. Let's pretend the Chrome UI is entirely C++, and let's pretend, for a moment, that there's no way (currently) to customize the settings dialog. Now let's pretend we can write C++ extensions. What would the C++ API look like? I'll leave this as an exercise to the reader. Go ahead, I'll wait. Build some sample applications. Use pseudocode, if you like. Now, look at your API, and ask yourself why this couldn't be exposed to Javascript. To take another, much simpler example: Webkit is probably written in C or C++, right? It's native code that parses HTML, and native code that generates the DOM, right? But I can manipulate the DOM with Javascript just fine. And given that there just isn't that much UI -- that much chrome -- to Chrome, I wouldn't be surprised to see a more complete API in the future. As it is, the usual pattern for an extension that wants, say, a dialog box, is to pop up a new window pointing to some page inside the extension. Oh, and yes, you can embed plugins inside your extension, which means you can use whatever language you like to make plugins -- probably C++ -- but you probably can't dig that deeply into the browser itself from that plugin.
A C++ API is probably kinda like gcc libraries that you can use instead of having to write your own functions. So a Chrome API in C++ may allows you to mess around Chrome parts that are not HTML+Javascript based. And of course, you will be able to dig deeply into the guts of Chrome just like you can do to Firefox. About the DOM manipulation you describe above, in Firefox, you can actually have an extension that will make Gecko output the DOM (already modified) you
High precision mouse detection is needed so that. for example, you do not have to actually do a 90 degrees down-right mouse movements to close a tab.
That's not a property of precision, that's a property of your logic for interpreting the gesture.
HTML+Javascript combo cannot be used to access XPCOM. Javascript, yes. HTML, no (this is by design).
If you mean, HTML can't access it without the help of Javascript, well of course. But I see no reason you couldn't draw the UI with HTML and add the behavior with Javascript, just like you do for a web app.
in Firefox, XUL is faster at compositing and displaying UI than HTML
That suggests Firefox's HTML rendering should be improved -- but more importantly, I bet C++ is faster at displaying UI than XUL. Why did they use XUL?
I think you'll find that reason would also apply to HTML.
XUL can access XPCOM
I keep trying to get you to be clear, and you seem to be unable. So please answer this question first:
Is XUL a Turing-complete lanugage?
If not, then let's be clear and say that Javascript, attached to a XUL view, can access XPCOM.
So a Chrome API in C++ may allows you to mess around Chrome parts that are not HTML+Javascript based.
If they expose it. They probably don't.
And of course, you will be able to dig deeply into the guts of Chrome just like you can do to Firefox.
Have you actually done this with any program other than Firefox?
No, most C++ applications don't let you do that, without actually editing the source. Technically it's possible, but without a plugin/extension API, it's not easy, and will break with the next update.
So, I know Chrome exposes the Netscape Plugin API (the same one Firefox uses) via C/C++. I haven't seen it expose any other C/C++ API.
About the DOM manipulation you describe above, in Firefox, you can actually have an extension that will make Gecko output the DOM (already modified) you desire that need not be touched again by XUL or Javascript for modification.
In other words, you can modify the DOM before it's output, as opposed to after, right?
Why is this better?
This is why depending entirely on API will constrain you from adding new features.
Really? Because that's what you're doing with Firefox. I realize this is hard for you to understand, but unless I'm missing something, XPCOM is an API.
If it's more flexible an API than the Chrome API, that's another discussion. But it's still an API.
Don't thank God, thank a doctor!
That's not a property of precision, that's a property of your logic for interpreting the gesture.
And implementing the logic via Javascript only will be hard. After all, after more reading of the Chrome API, apparently you cannot use all features of Javascript to make a Chrome extension. You will need to hope that Chrome has an API for it (which it seem that they have), else doing it will be hard. Now, can you make a mouse gesture extension that is as good as FireGestures but without using the gestures API in Chrome? Maybe doable, but it will be hard. There are no gestures API in Firefox, and FireGestures developers has to create their own gesture recognition engine. I imagine that doing the same will be hard in Chrome, unless you have an API for it. Well, if you have an API exposed, you are scot-free, but what if you don't?
If you mean, HTML can't access it without the help of Javascript, well of course. But I see no reason you couldn't draw the UI with HTML and add the behavior with Javascript, just like you do for a web app.
You cannot draw UI for Firefox extensions using HTML and have it be interactive with the guts of Firefox itself. At best, HTML UI is only good for display while for interactivity, XUL for UI is needed. What you have envisioned may be possible in the current beta of JetPack, but not the mainstream extension platform.
That suggests Firefox's HTML rendering should be improved -- but more importantly, I bet C++ is faster at displaying UI than XUL. Why did they use XUL? I think you'll find that reason would also apply to HTML.
XUL is used because it is easier to do cross-platform development with it. Ever wonder why Chrome is not available officially in Mac OS X/Linux yet, even after a year when Windows binaries comes out? If Google use XUL for Chrome, we may have official builds for Linux and OS X today, not in some beta form. Imagine the riot that will happen if Mozilla released Firefox 4 only for Windows first while keeping users of OS X/Linux waiting for 12 months (and counting) to get it (meanwhile, they can only use betas for the time being). Gecko is not that bad at spiting out HTML, this is not IE after all. But considering that they already use the faster XUL for UI, might as well use it for the extension platform,.
I keep trying to get you to be clear, and you seem to be unable. So please answer this question first: Is XUL a Turing-complete lanugage? If not, then let's be clear and say that Javascript, attached to a XUL view, can access XPCOM.
Apparently you did not know what XUL is. To make it simple, XUL is XML + CSS + Javascript. Why would XUL need to be attached to external Javascript scripts just to access XPCOM? XUL can access XPCOM by itself, it has Javascript within it. Maybe HTML in Chrome extensions need to be attached to a Javascript script to access the Chrome API, but XUL doesn't have to to access XPCOM. Yes you can attach Javascript to it, but it is not mandatory.
Have you actually done this with any program other than Firefox? No, most C++ applications don't let you do that, without actually editing the source. Technically it's possible, but without a plugin/extension API, it's not easy, and will break with the next update. So, I know Chrome exposes the Netscape Plugin API (the same one Firefox uses) via C/C++. I haven't seen it expose any other C/C++ API.
I have not done this outside Firefox, and yes you are correct that C++ applications doesn't allow you to do that without source editing. That's why extensions in Firefox are powerful, and also can be extremely dangerous (that's why Mozilla will only sanctioned people to get extensions from their SSL-enabled website). Chrome doesn't have this, and this is why Chrome extension platform is less powerful than Firefox's.
Really? Because that's what you're doing with Firefox. I realize this is hard for y
implementing the logic via Javascript only will be hard.
Harder than what?
apparently you cannot use all features of Javascript to make a Chrome extension.
News to me. Which features can you not use?
There are no gestures API in Firefox, and FireGestures developers has to create their own gesture recognition engine.
Let me guess -- they wrote it in Javascript. Or, I'm sorry, XUL's XML + CSS + Javascript.
You cannot draw UI for Firefox extensions using HTML and have it be interactive with the guts of Firefox itself.
This seems a fairly arbitrary limitation of Firefox -- especially because the HTML can talk to the Javascript, and if the Javascript has access to the same APIs that XUL Javascript does, the only difference is XUL's XML vs HTML in Gecko.
XUL is used because it is easier to do cross-platform development with it.
Also true for HTML.
Ever wonder why Chrome is not available officially in Mac OS X/Linux yet, even after a year when Windows binaries comes out?
Given that this is exactly what I'm doing right now, yes, I do wonder. Chromium has been on Linux for awhile, and official builds of Google Chrome exist.
If Google use XUL for Chrome, we may have official builds for Linux and OS X today
You're assuming that it was UI that was the issue, and that doesn't seem to be the case.
Imagine the riot that will happen if Mozilla released Firefox 4 only for Windows first
Because Firefox 4 would be a new version of Firefox 3. Chrome was a brand-new browser.
To complete your analogy... Wasn't Netscape only for Windows, at first? Certainly, Mozilla took time to get a Linux port working, though they might've had it by public release. It certainly wasn't "free", as they had to develop their cross-platform XUL engine first -- just as Chrome leans on Google's cross-platform GUI libraries and the cross-platform Webkit.
Gecko is not that bad at spiting out HTML, this is not IE after all. But considering that they already use the faster XUL for UI, might as well use it for the extension platform,
And they already have the faster C++, thousands of lines of which are now cross-platform.
In short, I don't see why they'd use XUL for speed, but not C++ for speed. I don't think they chose XUL because of speed. I think they chose XUL because when it was developed, HTML wasn't anywhere near ready to do this kind of thing by itself.
Apparently you did not know what XUL is. To make it simple, XUL is XML + CSS + Javascript. Why would XUL need to be attached to external Javascript scripts just to access XPCOM? XUL can access XPCOM by itself, it has Javascript within it.
Ok, then.
Why not build a variant of XUL which uses HTML + CSS + Javascript, withaccess to XPCOM? It's just replacing the XML part of XUL with HTML.
That was my point.
Maybe HTML in Chrome extensions need to be attached to a Javascript script to access the Chrome API
Well, the parts that are done in HTML can just use normal script tags, if that's what you mean by "attached".
There are a few places where you can plug in Javascript, but not necessarily HTML/CSS -- but you can certainly pull these in with Javascript, easily enough, as the Javascript can get a URL to anything else in your extension package.
Speaking of which, the extension package is just a signed zip, which I love. What's the XPI format like?
you are correct that C++ applications doesn't allow you to do that without source editing.
And Firefox is, at least in part, a C++ application.
That's why extensions in Firefox are powerful,
XPCOM is a framework, not str
Don't thank God, thank a doctor!
Harder than what?
Harder than using XUL (which has Javascript in it) with XULConnect and XPCOM. It is kinda like writing software using Notepad/vim/emacs or Eclipse/Visual Studio. It is doable in both, but with the latter it is easier.
News to me. Which features can you not use?
Not all Javascript functions can be bound the Chrome API.
Also true for HTML.
And why is then Chrome did not use HTML to render its UI? Apparently, the UI is still C++.
Given that this is exactly what I'm doing right now, yes, I do wonder. Chromium has been on Linux for awhile, and official builds of Google Chrome exist.
Chromium != Google Chrome. It is like saying Google Chrome == Safari just because they use WebKit. Chromium is not Chrome just like SRWIron is not Chrome. Chromium is like Iceweasel (without the controversy) to Firefox as it is to Google Chrome.
You're assuming that it was UI that was the issue, and that doesn't seem to be the case.
Then please explain why after 1 year and three major version in Windows, why Google Chrome (not derivatives like Chromium) in Mac OS X is still developer preview? Is it really that hard to make a port?
Because Firefox 4 would be a new version of Firefox 3. Chrome was a brand-new browser. To complete your analogy... Wasn't Netscape only for Windows, at first? Certainly, Mozilla took time to get a Linux port working, though they might've had it by public release. It certainly wasn't "free", as they had to develop their cross-platform XUL engine first -- just as Chrome leans on Google's cross-platform GUI libraries and the cross-platform Webkit.
When Firefox 1 was released, it is already available for Linux and OS X. And BTW, Netscape is not written by Mozilla, Netscape is written by Netscape Communication. Mozilla Foundation does not exist until this decade. Netscape doesn't even use XUL until version 6 (prior to that Netscape is completely C++), so where did you find evidence that Netscape is having to create the cross-platform XUL for Netscape 1?
And they already have the faster C++, thousands of lines of which are now cross-platform. In short, I don't see why they'd use XUL for speed, but not C++ for speed. I don't think they chose XUL because of speed. I think they chose XUL because when it was developed, HTML wasn't anywhere near ready to do this kind of thing by itself.
Apple choose WebKit over Gecko for one reason only: cross-platform support. The current Gecko is still not crossplatform-friendly, but better than the early version of the rendering engine. XUL was chosen because using it will simplify Mozilla's heavy burden of making Firefox/Seamonkey cross-platform friendly. Considering the limitations of Gecko when it comes to cross-platform support, Mozilla can be commended for having released Firefox 1 on time for Linux/OSX users, instead of making them wait for 12 months as Google has done. Mozilla use XUL for cross-platform compatibility, not speed. And HTML is never designed to be used as UI anyway, unlike XUL who are explicitly design to be used as UI compositing.
Ok, then. Why not build a variant of XUL which uses HTML + CSS + Javascript, withaccess to XPCOM? It's just replacing the XML part of XUL with HTML. That was my point.
Why would Mozilla replace the perfectly fine XUL with another variant that uses HTML? If you want some HTML action, why do you take a look at Mozilla Jet Pack, which is yet another way to create extensions for Firefox? Look at https://jetpack.mozillalabs.com/
Well, the parts that are done in HTML can just use normal script tags, if that's what you mean by "attached". There are a few places where you can plug in Javascript, but not necessarily HTML/CSS -- but you can certain
I just went and installed it (stuck w/ IE here by fiat), and see no difference whatsoever. From a quick reading of the avilable docs, it looks like their renderer just sits there in the background twiddling its thumbs unless it hits a website with the special "Google, save me!" tag embedded in it.
Unless and until a large percentage of the web chucks the "Google, save me!" tag into their pages, this isn't liable to affect you as a user. However, it is nice for web developers, as they can now "support" IE by checking for support of the tag, and kicking IE users without it to the Chrome plugin install page.
Harder than using XUL (which has Javascript in it) with XULConnect and XPCOM.
In other words, using Javascript is harder than... using Javascript? WTF?
I don't see what XULConnect or XPCOM add, API-wise, to make sensing mouse movements any easier or more accurate than DOM events. I don't see what XUL XML adds to the situation at all.
Not all Javascript functions can be bound the Chrome API.
I'll try to put this as gently as possible...
Use complete sentences, please. I have no clue what you meant just then.
And, if you're saying what I think you're saying, please provide an example of a Javascript feature which is not available in Chrome extensions, and where it is available. If you use the words XUL or XPCOM in your answer, remember that we were talking about Javascript features here, not Firefox-specific features.
I'm pretty sure Chrome extensions have access to the same valid EcmaScript engine that webpages do, when viewed in Chrome.
And why is then Chrome did not use HTML to render its UI?
Actually, I don't know, but I am seriously considering writing a browser that does just that.
But again, it does use HTML to render pieces of its UI. What isn't done by HTML isn't much -- just the tab bar and the config pages, really. Even the download manager is HTML.
Chromium != Google Chrome. It is like saying Google Chrome == Safari just because they use WebKit.
*facepalm*
Actually, Chromium is Google Chrome. It lacks exactly two things found in Google Chrome:
And you can still use ffmpeg codecs, it's just not legal -- whereas Google actually does have licenses to things like h.264, etc.
Chromium is more Google Chrome than Mozilla was Netscape, because Netscape really did add a ton of proprietary features on top of Mozilla -- things like spellcheck, which Mozilla had to write their own version of.
Then please explain why after 1 year and three major version in Windows, why Google Chrome (not derivatives like Chromium)
Chromium is exactly as much a derivative of Chrome as Mozilla is a "derivative" of Firefox. (Hint: It's the other way around.)
But please explain why it matters whether it's Chrome or Chromium. If the supposed issue is using C++ and Google's portable graphics API, shouldn't this affect Chromium as much as it affects Chrome?
Is it really that hard to make a port?
It is when you ignore facts, and continue to make statements like this:
When Firefox 1 was released, it is already available for Linux and OS X.
I don't believe there was an OS X port of the original Phoenix browser when its developer previews were released. And remember, this was a fork of Mozilla, which was already cross-platform. And it was a fork which removed things, so it should've been easier to port, if anything.
Netscape is not written by Mozilla, Netscape is written by Netscape Communication.
However, the original Mozilla was open source code that came from Netscape. I'm talking about Mozilla the browser, not the Mozilla Foundation.
Netscape doesn't even use XUL until version 6 (prior to that Netscape is completely C++)
Indeed, because XUL was one of the first innovations of Mozilla, which Netscape 6 was built on.
XUL was chosen because using it will simplify Mozilla's heavy burden of making Firefox/Seamonkey cross-platform friendly.
Yet Netscape (and Mozilla) were already massively portable before XUL. Maybe XUL made it easier going forward, but it certainly wasn't needed.
I do have to admit that I was wrong about XUL being required for that portability -- meaning it was
Don't thank God, thank a doctor!
I'm posting this with the cf:http://tech.slashdot.org url. (I'm using the Google Frame plugin in IE8).
I used the cf: on acid3 and 100% wow !!! This is destabilizing !! :-)
Now i tested my banking account site that usually work only with IE and have issues with Google Chrome. So in entered the cf: and accessed my site and was able to make some account payment with it. Great. And fast.
This is the kind of test we need to make to full-proof this plugin.
Yes let's all start eating concrete instead of expecting a responsive UI.
The thing I am talking about mostly is how Fx closes your tab and delays of a noticeable amount of time before relaunching it in a new window. It also loses the state of running flash applications like videos (which Safari and chrome handles). The whole experience gives me the feeling that it is a hack emulating chrome and safari rather than stable functionality.
Like I said, you have no valid complaint it's just that things aren't to your liking.
The thing UI zealots don't want to admit is that it really isn't that important. The best you can come up with is that there is at best a 2 second wait between opening new tabs (which personally I've never noticed). As long as the UI works its good. A great UI has no advantage over a good UI, if it works (as in allows a user to accomplish their desired task) it is good enough for 99.9999999% of users. The engine of the browser is more important, I'm not going to fret over a second lost here, FFx's engine is a solid performer that can handle a wide variety of plugins and handle aberrant behaviour in the browser without bringing down the entire browser (error handling), this is more important to most people then a "snappier" interface (I really hate buzzwords, can someone quantify snappier?).
As I said in a previous post, give me a legit complaint, backed up by replicable evidence not feelings. In my experience Chrome and Safari do not play well with proxies that require authentication where as Firefox will. With ISA, Firefox will use the accompanying firewall client (which passes authentication info to the proxy) where Safari crashes and Chrome asks for authentication as it uses IE's proxy settings.
But here's the brilliant thing, no one is forcing you to use Firefox, so if the UI is not to your liking then uninstall and use a different browser. Please stop wasting others time with frivolous complaints.
Calling someone a "hater" only means you can not rationally rebut their argument.