I would like to know what the members of this great community think of developing and adjusting their web apps and sites in general to recent Google Chrome beta browsers on Linux and Mac OS X and of course Google ChromeOS.
Do you think it's too early and I shouldn't waste my time adjusting myself to something that might change due to bugs resolutions?
Thank you.
Since Google Chrome uses Webkit you could also (as an alternative) test against Safari or Konqueror instead. Chances are your test results will be very portable across these browsers.
I think you answered your own question. While it is good to test against multiple browsers, there is very little point in testing against a beta browser - especially one with as little marketshare as Chrome.
With that said, the only reason I could see testing against a beta browser, is that you want your website to look good in it as soon as it is released and becomes mainstream. But, I really only see this need arising for the browsers that, again, are more popular.
Code against the standard, if you code it right the browsers will move toward you - rather than you constantly playing catchup.
Related
I have been debating whether using polymer in my chrome extension is worth while.
Here is the scoop. (or should I say scope, haha bad programmer jokes)
My extension relies heavily on web components which have been available natively in chrome since the release of chrome 36
Now, if the browser statistics listed here are correct, then logically, there isn't much of a reason to polyfill web components since only a small percentage of chrome users use versions earlier than 36 (and lets face it, chances are they aren't using extensions).
What do you guys think? Are there any other reasons using polymer in this case which I fail to see?
I am looking for a framework with which I can create browser extensions (namely a toolbar), for all browsers (IE, Firefox, Chrome).
I have searched for a relevant solution, but none which I found were what I need:
CrossRider - no good since it can't be self-hosted. The same would apply to companies like Conduit, and nearly all other solutions I've encountered.
Kango - this does look exactly like what I need, but the license is too expensive IMHO.
Does anyone know a framework which will allow development - using js & html - of a cross-browser toolbar?
I've never tried it myself but I remember a colleague of mine talking about firebreath a while ago.
Google has taken up the implementation of WebRTC in Chrome very seriously as indicated by the frequent updates in the Canary and Beta channel of Chrome. Are there any other browsers who are upto implementing this?
Firefox/IE/Opera are working on it. No word from Apple/Safari or Microsoft/IE, although IE is unlikely at best, because they're working on their own standard unfortunately. Crazier things have happened, but I wouldn't count on it. Apple has been fairly mum on the subject.
If you want support for those other browsers, we built a solution for it # Frozen Mountain (I work there) using IceLink.
Opera Mobile does offer support to WebRTC. And according to this article, Mozilla isn't all that far behind either. Ericsson Labs has their own custom browser which supports WebRTC. But it runs only on Ubuntu as of now. WebRTC itself is still under development and I'm sure that we can see complete support from all major browsers in some time.
Mozilla is far along in implementing WebRTC, and we're leading the design and implementation of DataChannels within WebRTC, as well as Identity work. We're working on a project-specific repo right now (alder), but pieces have already moved over into mozilla-central, such as initial support for getUserMedia.
I'm someone who wants to be up on the latest web technologies but also appreciate that alot people still use IE6/7/8. Is it a waste of code/time if half of it wont be displayed on most browsers? Is it just a case of using different style sheets, or just use one style sheet and if a browser doesnt support text-shadow, then screw it, they can see it without the nice effects. What are peoples thoughts?
It depends on your userbase. I am an intranet developer and my company still uses IE6(!!!) so we have no choice but to support IE6. I also develop some public facing websites and we use Analytical tools to see the which Browser is being used more and ignore ones which are less used. in this case IE6 was the least used Browser.
I won't go for HTML5 and CSS3 till Internet Explorer 9 or Firefox 4 (absolute release, not alpha or beta) is released, because these two browsers make up the most of web traffic (afaik, correct me if I'm wrong) and using html5 or css3 will be a big loss.
And yeah, it depends on your userbase too.
I'm developing a small-business oriented online app and decided to support only IE8, FF and Chrome. I also went for one stylesheet that degrades nicely (text-shadow, rounded corners). IE8 users will see square corners but it doesn't make the site unusable in any way.
I just think that the cost of making everything look perfect in all browsers (and maintaining it!) is much higher than the benefits.
The above also applies to HTML5 IMHO - unless you know that vast majority of your users will have an HTML5-compatible browser there's no need to invest in it right now. Unless the whole point of your site is to use one of the newest features.
Just tell yourself what problem of your users you are actually solving and solve that one.
I want to display a message to users with unsupported browsers, as opposed to having the site fail in an ugly manner.
What's the best way to do that?
GWT also provides browser detection using the .gwt.xml file. Have a look at this:
http://code.google.com/p/google-web-toolkit-doc-1-5/wiki/DevGuideDeferredBindingReplacement
It's an interesting solution, but I'm not sure if it's the best solution in your case. It could be very useful for creating a simplified version of your application which would automatically be loaded in unsupported browsers.
The GWT team does not provide a list of unsupported browsers, only supported browsers, and it's a vague list at that "most recent versions of Internet Explorer, Firefox, and Safari. (Opera, too, most of the time.)".
If you have a good idea yourself of what browser/version won't work you can use this code:
public static native String getUserAgent() /*-{
return navigator.userAgent.toLowerCase();
}-*/
to learn what browser is being used and perhaps cook up a work-around.
On the other hand, browser rendering of web pages can fail in many subtle ways ranging from mildly annoying to catastrophic, and there is often no way to know where your page falls on that scale. One of the major reasons for GWT is that you can stop worrying about this sort of thing. At least until it happens.
If you want to make it simple and stupid, check with some javascript code in your main html file, before GWT is loaded. Novertheless, I would rather trust GWT to handle things more or less quirky. You could also just recommend chrome or firefox.
I realise this is an old question, but I had the same problem, and wanted to share a new solution for it.
Today with GWT2.7 "obsolete" browsers try to download undefined.cache.js. This obviously fails and the client is stuck forever.
You could patch GWT itself setting fallback compile steps, but the easy solution is to simply provide a (manually crafted) undefined.cache.js and place it where the other generated files are.
Inside you put this one line:
xxxxxxx.onScriptDownloaded(alert('This browser is not supported anymore.\nPlease upgrade to a more recent browser.'));
where xxxxxxx is your module basename (from xxxxxxxx.gwt.xml).