Related
I am working on a project to convert a web site that is fully functional in Internet Explorer 8 and lower, but does not work well in Firefox or Safari.
A lot of what will need to be changed is going to be javascript-related (aka methods that exist in IE but not in other browsers).
What I want to know is whether anyone is aware of a fairly comprehensive list of common things that have to be changed to work accross all browsers.
I am starting with quirksmode.org but I don't think it will have quite everything I'm looking for. If anyone knows of a list please let me know.
Your best option here is to go with a Javascript toolkit/library like jQuery, MooTools or Prototype. Such a decision will save you a monstrous amount of work, and all three are constantly being updated which gives you a large degree of safety against future compatibility issues. Especially for DOM manipulation or AJAX, a library is the way to go.
If you absolutely mustn't use one, quirksmode is a good start. I've never found any single source that is comprehensive enough to keep me from running back to Google for each problem area.
Quite honestly, if you don't have lots of experience doing cross-browser development, I suspect the best way to fix your app is to set up a good test environment on each target browser and starting finding where it breaks. You're eventually going to have to test it on each target browser anyway, so you might as well start there. Once you find out what code is failing you for a particular bug, you can do more targeted searches for how to work around that issue in a cross browser way.
You will, over time, build up a good internal knowledge base of what is safe to use in a cross browser way and what is not. Even experienced developers still run into new issues on every project that are only found with testing. One advantage of experience though is that you start to learn when to suspect that something might or might not have cross browser issues and either avoid it (find a safer way) or explicitly test it in several browsers before you use it.
I find that http://jsfiddle.net is awesome for creating very efficient self-contained test cases to either proactively try something in other browsers or to troubleshoot something that's been giving you a problem.
As others have said, one huge advantage of the various browser libraries like jQuery or others is that they have solved a lot of these compatibility issues for you and, in general, if they document a function in the library and don't explicitly warn you about cross-browser issues, then they've already done their homework to make it safe for you.
You may also find out that using a javascript framework such as jQuery, ExtJs, Prototype, Mootols, ... would be very beneficial in writing cross browser javascript.
a web site that is fully functional in Internet Explorer 8 and lower,
but does not work well in Firefox or Safari
I would strongly recommend to develop with a browser that meets the standards (e.g. CSS3).
The process should rather be: to develop with FireFox or Chrome - and fix all IE versions later on.
Well, this is my daily bread... and ordinary it's IE b*tch which makes me loose time...
In my website I have developed a lot of CSS3 transitions. I have found that in old computers the transitions are lagging. The lagging lower the user experience of the website. Is there a way of determine which compueters are lagging and not using javascript?
Is there a way of determine which compueters are lagging and not using javascript?
Yes, both of these methods require some way to log your visitors and their capabilities on the server-side. An 'analytics' tools will probably tell you who has javascript and who does not (or you can manually check using tricks like a <noscript><blah src="log-that-my-ip-doesnt-have-javascript"/></noscript>).
Measuring responsiveness is a much more subjective matter. If you were up to the task, the "correct" way to do it would be to write a client-side responsiveness profiler in javascript, which sent back statistics. For example, perhaps a setInterval of 100ms that checks to see if the current time is more than 100ms since the last call (indicating UI lag).
Personally, I would not worry about it if it's a personal website.
The real question is, what would you do with such information? It might be unwieldy perhaps to support two different versions of the site, but such information would in fact you to disable "sexy" effects, and is a very interesting idea. I might use it myself; good luck!
Maybe I'm misunderstanding what you're asking, but what do CSS3 transitions have to do with JavaScript? If you want to detect whether a browser supports CSS3 using JavaScript, have a look at the resource over here:
http://net.tutsplus.com/tutorials/html-css-techniques/quick-tip-detect-css-support-in-browsers-with-javascript/
Only the most modern browsers have good support for CSS3, so to those using powerful browsers on an old system, I'm not sure what you're going to do about that. Other than detecting operating system, there's really nothing you can do (easily) to determine how much taxing of system resources a browser is going to do by rendering transitions.
My personal preference would be to not have many transitions. Sure, they're "fancy" and "eye candy-ish," but I don't want to use a website that's making me wait to watch those fancy things happening. I think it detracts from the overall web browsing experience and you might lose visitors because of it. That's not to say that they can't be useful in some cases, just don't overdo it.
You need to seriously consider browser support before using technology in web development. Depends on whether you're okay or not with having your site break down for many people. Consider CSS transitions support listed here: http://www.deepbluesky.com/blog/-/browser-support-for-css3-and-html5_72/
I want to program my xhtml Web Applications without javascript.
What are the alternatives for creating interactive xhtml web applications?
Perhaps java applets which do the tasks of javascript?
Or is there another way?
Thanks for any help!
Javascript is hard to debug, is dynamically typed, strange OOP, could be replaced by any other language when that language will be cut to work at a browser.
I would also like some typesafety in my code what can discover many bugs before running the code.
--EDIT 2--
Have a look at http://www.scala-js.org/.
---EDIT---
So for now there is no real alternative to javascript what is as flexible, widespread and applicable.
What i think is applicable are frameworks/tools who compile one language to another like GWT or coffescript.
Thank you for the detailed answers. The reason for my question was, that web development is getting more complex every day. I prefer languages like Java for stable error outlining and type safety. JavaScript on the other hand is (in my opinion) mysterious in its ways and hard to debug (browser incompatibilities, silent errors, unintuitive operands, dynamic typing,....). I developed Websites with JS for years now and it feels horrible to me due to such debugging problems and code management. Yet the libraries are quite powerful and ease much of the work.
To have an interactive site you need something that can execute code on the client machine.
This is (at the moment) usually JavaScript. In the past this would have also included Flash or Silverlight (both of which are now on the wane).
JavaScript has a big advantage in that it can easily manipulate the HTML elements directly. While it is possible to do that with Silverlight it's not as easy as Silverlight is designed primarily to build self-contained objects.
Google Web Toolkit GWT lets you write java code which compiles to client-side xhtml+javascript. It relinquishes the page-based standard web approach for a more desktop-like interaction (if I remember correctly the API is somewhat similar to many desktop windowing toolkits).
You may (but don't have to) also develop the (java) server logic and have some client-server communication baked in for you by the compiler.
Have a look at http://code.google.com/intl/it-IT/webtoolkit/
Some JavaScript alternatives:
Flash
Silverlight
Java applets
This is not a recommendation, just a list.
If you're really that allergic to JavaScript, there are a number of frameworks that let you write server-side code which generates the JS for you, as other answers mention.
Check out Google Dart - it has reached 1.0 recently, and has started standardization process few days ago (ECMA TC52). It also compatible with currently available browser via highly optimizing dart2js translator, so you can start using it right now :). Much more sane language than JavaScript, IMO.
More can find more information on the official page here: https://www.dartlang.org/ (tools, documentation, sample code, tutorials), and there is also nice introductory video on the YouTube: http://www.youtube.com/watch?v=FqsU3TbUw_s.
As well as applets you have Adobe Flash, Microsoft Silverlight, shortly Chrome NACL. None of these interact with the HTML DOM as seamlessly as JavaScript though.
One thing you can do is simply have the server-side code do all of the processing. You limit yourself to having only CSS available for interactivity, but you can still do just about everything by loading a new page.
If you're considering java applets, then I guess it's necessary to mention Flash and Silverlight (*).
Of course, there are "interactive" web applications that don't use javascript... they use postback. But I don't think this is what you mean.
If you want to target just Internet Explorer, you can use VBScript (Microsoft's proprietary javascript) or even ActiveX. But I doubt that's what you mean, too.
So the onus is on you to answer — why not javascript?
(*) I guess.
I'd be very interested to know what your reasons are for not wanting to use Javascript? The answer to that question will make a big difference to how your question should be answered.
The Javascript language is actually quite powerful. Yes, it does have some quirks, but so do all other languages. A lot of the perceived "problems" with Javascript development in the browser are actually people having issues with the DOM rather than Javascript itself. The DOM, on the other hand is where a lot of the shortcomings and the cross browser issues crop up.
If this is where your problems lie, then you may be better off using a Javascript library such as JQuery, which abstracts away a lot of the direct access to the DOM, and resolves a lot of the cross-browser issues.
If you're using the latest browsers, a lot of the simple effects that previously required Javascript can now be done using CSS. drop-down menus, tabsets, fading, rotation and transition effects. All of this can be done with CSS. However most of them are quite new, and not available in all browsers currently in common use, so you would be better off sticking to Javascript for at least some of them for the time being. Even when they are ready for mainstream use, you'll still need some Javascript to hook them all together.
If you do really have a burning desire to develop using a language other than Javascript, then as you already pointed out, there are other options for programming on the web, such as Java applets. There's also ActiveX controls, Flash and Silverlight, and a few others. However none of them are universally available to all users in the way that Javascript is.
All of them require browser plug-ins of one sort or another, and all of them have issues with users who don't want to install them or corporate environments that don't allow them to be installed. In the case of technologies like ActiveX, they may only be available on certain browsers and operating systems, and (again like ActiveX) they often have security issues.
The only real reason that most of these other technologies existed in the first place was to fill a gap in the capabilities of the browsers at the time. All of these capability issues have now been resolved -- with HTML5 and related technologies driven by Javascript, Flash and Silverlight have been rendered obsolete; ActiveX controls were considered obsolete long ago; and when was the last time you saw a Java applet in mainstream use?
The bottom line is that the browser world is moving very rapidly away from any client-side code other than Javascript, and there are very good reasons for that.
Use pyjamas (google it), you can write normal python code and have it compiled as javascript so you get the best of both worlds, the power and expressiveness of python and the ubiquity of javascript.
Also keep an eye on the Falcon project by Adobe, it's an experimental compiler which translates actionscript 3 (a very powerful language compared to plain javascript) and the flex framework to javascript.
You can also try GWT by Google, where java is used as the client side building code (and yes, it also gets compiled to native javascript).
If it runs on the client's computer and can modify the DOM, it can work. JavaScript is the most widely supported so it'll work out-of-the-box for many people.
Basically, anything which functions like JavaScript can replace it.
Flash can perform basically everything that JavaScript can (graphically, but it can't modify the DOM), but if the user doesn't have Flash Player installed, you're out of luck.
Java can also work, but the same concept applies: if the user doesn't have JRE (or a similar machine)
Silverlight is similar to Flash, but much less supported (I can barely get it to work on my Linux box)
Just curious: why are you looking to replace JavaScript with something else?
This may seem inane, but I actually like using jQuery much better than JavaScript. It makes event handling and Ajax very simple.
I'm not a JavaScript wiz, but is it possible to create a single embeddable JavaScript file that makes all browsers standards compliant? Like a collection of all known JavaScript hacks that force each browser to interpret the code properly?
For example, IE6 does not recognize the :hover pseudo-class in CSS for anything except links, but there exists a JavaScript file that finds all references to :hover and applies a hack that forces IE6 to do it right, allowing me to use the hover command as I should.
There is an unbelievable amount of time (and thus money) that every webmaster has to spend on learning all these hacks. Imagine if there was an open source project where all one has to do is add one line to the header embedding the code and then they'd be free to code their site per accepted web standards (XHTML Strict, CSS3).
Plus, this would give an incentive for web browsers to follow the standards or be stuck with a slower browser due to all the JavaScript code being executed.
So, is this possible?
Plus, this would give an incentive for web browsers to follow the standards or be stuck with a slower browser due to all the JavaScript code being executed.
Well... That's kind of the issue. Not every incompatibility can be smoothed out using JS tricks, and others will become too slow to be usable, or retain subtle incompatibilities. A classic example are the many scripts to fake support for translucency in PNG files on IE6: they worked for simple situations, but fell apart or became prohibitively slow for pages that used such images creatively and extensively.
There's no free lunch.
Others have pointed out specific situations where you can use a script to fake features that aren't supported, or a library to abstract away differences. My advice is to approach this problem piecemeal: write your code for a decent browser, restricting yourself as much as possible to the common set of supported functionality for critical features. Then bring in the hacks to patch up the browsers that fail, allowing yourself to drop functionality or degrade gracefully when possible on older / lesser browsers.
Don't expect it to be too easy. If it was that simple, you wouldn't be getting paid for it... ;-)
Check out jQuery it does a good job of standardizing browser javascript
Along those same lines explorercanvas brings support for the HTML5 canvas tag to IE browsers.
You can't get full standards compliance, but you can use a framework that smooths over some of the worst breaches. You can also use something called a reset style sheet.
There's a library for IE to make it act more like a standards-compliant browser: Dean Edwards' IE7.
Like a collection of all known
javascript hacks that force each
browser to interpret the code properly
You have two choices: read browser compatibility tables and learn each exception a browser has and create one yourself, or use avaiable libraries.
If you want a javascript correction abstraction, you can use jQuery.
If you want a css correction abstraction, you can check /IE7/.
I usually don't like to use css corrections made by javascript. It's another complexity to my code, another library that can insert bugs to already bugged browsers. I prefer creating conditional statements to ie6, ie7 and such and create separate stylesheets for each of them. This approach works and doesn't generate a lot of overhead.
EDIT: (I know that we have problems in other browsers, but since IE is the major browser out there and usually we need really strange hacks to make it work, css conditional statements is a good approach IMO).
Actually you can,there are lots of libraries to handle this issue. From the start of the time, javascript compliance issue always was a problem for developers and thanks to innovative ones who developed libraries to get over this problem...
One of them and my favorite is JQuery.
Before JavaScript 1.4 there was no global arguments Array, and it is impossible to implement the arguments array yourself without a highly advanced source filter. This means it is going to be impossible for the language to maintain backwards-compatibility with Netscape 4.0 and Internet Explorer 4.0. So right out I can say that no, you cannot make all browser standards compliant.
Post-netscape, you can implement nearly all of the features in the core of the language in JavaScript itself. For example, I coded all methods of the Array object in 100% JavaScript code.
http://openjsan.org/doc/j/jh/jhuni/StandardLibrary/1.81/index.html
You can see my implementation of Array here if you go to the link and then go down to Array and then "source."
What most of you are probably referring to is implementing the DOM objects yourself, which is much more problematic. Using VML you can implement the Canvas tag across all the modern browsers, however, you will get a buggy/barely-working performance in Internet Explorer because VML is markup which is not a good format for implementing the Canvas tag...
http://code.google.com/p/explorercanvas/
Flash/Silverlight: Using either of these you can implement the Canvas tag and it will work quite well, you can also implement sound. However, if the user doesn't have any browser plugins there is nothing you can do.
http://www.schillmania.com/projects/soundmanager2/
DOM Abstractions: On the issue of the DOM, you can abstract away from the DOM by implementing your own Event object such as in the case of QEvent, or even implementing your own Node object like in the case of YAHOO.util.Element, however, these usually have some subtle changes to the standard API, so people are usually just abstracting away from the standard, and there is hundreds of cases of libraries that abstract away.
http://code.google.com/p/qevent/
This is probably the best answer to your question. It makes browsers as standards-compliant as possible.
http://dean.edwards.name/weblog/2007/03/yet-another/
Perhaps I'm just unaware of the competitors, but it seems when it comes to client-side scripting in the browser and DOM, Javascript is it. I know there's VBScript, but it really isn't even in the same ballpark as JS (not even cross platform, for starters).
I'm just curious about how this came to be. Surely there would be a general desire for a new language to replace Javascript: built from scratch to do all the things Javascript has been bent and moulded into these days (look at the reliance on JS Libraries).
Momentum. JavaScript has been around for 15 or so years, and browser manufacturers have worked for 15 or so years to make it work in their browsers.
If a competitor came along, it would need to really bring something new to the table in order to convince everyone to a) adopt it, b) live with locking out all the users of older browsers like IE7, Firefox 3.0, Chrome 1.0 etc. and c) find replacements for all existing libraries like jQuery, prototype, extJS etc.
In short: we don't need another Standard, let's rather improve JavaScript and build on the rich foundation that already exists instead of starting back from stone age again.
There is! Ones that spring to mind are Flash, ActiveX, and Java... But these all have their drawbacks. Mainly security and integration with the browser/DOM.
Flash and Java live in their own little world, by design (and to address security issues). They can't alter the HTML around them. ActiveX has access to the DOM, but also everything else on your computer.
JavaScript seems to have found a nice balance between flexibility and security, it can trivially interact and alter the pages HTML/CSS, do "safe" networking, has a decent standard library (which has things like JSON, XmlHttpRequest'sih networking, DOM manipulation, and so on). Most importantly, it's available in basically all vaguely-modern browsers, on all platforms, in a consistent manner (compared to CSS)
There are problems with JavaScript, but nothing major. The biggest is the performance. Load a comment page on Digg and watch your CPU usage. Chance are it will be 100% of one CPU core. There are projects to improve this, like SquirrelFish, TraceMonkey, and other strangely named things. But the performance is adequate to do some extremely impressive things (Google Spreadsheet, for example).
Basically, JavaScript is great, and it's drawbacks aren't nearly as big as the other competitors.
JavaScript won because it was introduced by Netscape in the period when they had above 90% percent market share. IE and other browsers had no choice but to support it also.
If a new language should be introduced, it would have to be either by agreement between all major browser vendors, or in a period where a single browser have enough market share to push it through.
Microsoft could probably have pulled it off some years ago when IE has an extremely large market share (before the rise of Firefox and Safari), but they chose instead (for strategic reasons) to let the browser stagnate.
Today, a new language would require agreement between at least Mozilla, IE and Safari to gain traction, and I think that is highly unlikely. The browser vendors have invested a lot of ressources in optimization, compatibility testing and so on for JavaScript - why should they want to start from scratch with a totally new language - and have to support two languages in parallel for decades to come? The cost greatly outweights any benefits.
Anyway, it is quite unrealistic to believe that a new language designed from scratch could be significantly better than JavaScript.
Show me another language that isn't reliant on libraries?
C, C++, C#, VBs, ... all rely on libraries. The only difference is that they often come with a standard set of libraries.
So do we really want is a standard set of libraries? What we're currently getting is a range of library sets (JQuery, prototype, extjs, mootools, etc). This is a good thing since we the developers get to choose one that suits our needs. In addition these libraries can be included and evolved without changes to the client-side component.
I can think of no compelling language feature missing from Javascript. By compelling I mean so earth shatteringly important that I'd be willing to alienate those browsers that do not support it.
Standardized (ECMA-262)
Common syntax and relatively simple to master
Good browser support
Extendable
Still being developed
Relatively quick based on how much data it needs to process sometimes.
If a good competitor had arrived before 1999 (ECMAScript 3), it would probably be a tie between those two.
There are other languages for client side scripting, but AFAIK, none are integrated into a browser.
Both Flash and Silverlight have their own Languages. Flash has ActionScript, while Silverlight has many and all that work under the DLR including Python and Ruby.
To your second point as to why, more specifically you mention reliance on JS libraries as a flaw in the language; Libraries are popular, not because the language if broken, but because the standard API is broken. The existence of such great libs builds on the power of the language.
There is nothing particularly wrong with JavaScript, it has some features that up to very recently would have been esoteric or academic. First class functions for example.
Also, ubiquity / mass existing runtime deployment is a very compelling feature. ;)
I recommend you to view Douglas Crockford’s presentation about “The JavaScript Programming Language” to learn about the history of JavaScript.
I think Javascript (ECMAScript) with its C like syntax is so popular for some of the reasons C is:
Relatively small number of language
keywords (easier to learn).
Concise and efficient syntax (quick to write).
Easily extendable
through external libraries and APIs that do
not pollute the basic language (ie Browser DOM,FilesystemObject etc).
Creating a new language that will provide many of the current libraries "built-in" is always risky as it starts to limit future applicability of the language and makes learning the base language harder.
This would be even more problematic for a client side browser language because the language designers can't possibly know how the language may be used in the future.
I think Javascript the language is fine in its current role as the "glue" that links so many other client sode technologies.
There are no other competitors because while Javascript is not perfect, it does the job.
I guess because the demand for it would have to be huge for browsers to implement it.
After all, it's the browsers that process and run the JavaScript and you'd have to have a large amount of sites using the language in order to make the browsers interested in implementing it. Then again no-one would use it if there was no browser support in the first place.
i'd say that this is because client side web development is still a very young branch of programming.
if you look at it only now it has become more widespread since we moved to faster "intertubes" :) and we're not using modems anymore.
and the problem for clent based web development is that it's not up to the developer what platform he'll use but it depends on the browser manufacturers.
and they change slow.
VB script's demise was in my opinion its VB-innes. too much unnecessary stuff.
As for javascript it will mature, but it's a start.
Browser support. If its not an MS tech the it most likely will not go into IE. If it's not in IE then no one can use it. If it is an MS tech, then most likely only IE will have the right to use it as it will be closed source and proprietary. If only IE supports it then only some developers will use it.
To challenge JavaScript it must work just as easily and more consistently across all of the major web browsers. Without browser support any new client side web tech is destined to fail.
I think it has to do with standardization, because durring the last browser-war (ie v. netscape) there were two, Netscape's ECMA (+1 Geek point for you if you knew this was the real name for JavaScript) and Microsoft's JScript, obviously ECMA (JavaScript) won out and became the defacto standard.
Now, we have another browser-war in progress and each of the 2 (3 if you count Chrome 12% FFS) major competitors 3 fully (with a few edge-cases) support JavaScript.
My guess is that its ubiquity and ease of integration in any new user agent project. It comes built into almost all browsers so you dont have to download/install/configure anything to have it running. once you look at user agents off desktops (wii, iphone, windows mobile, n95 etc) the availability of any of the contendes dries up quick - so you code for html and javascript becuase it will work most of the time.
I agree with Michael, we should improve Javascript, not worry about competitors because there aren't going to be any, in fact even Javascript 2.0 seems so far from reaching reality.
Since Javascript is such an ambiguous language, we're able to create libraries (jQuery) and even abstractions (Objective-J) and not worry about all the problems that Javascript has at its heart.
After so many years we don't even have CSS implemented same in all the browser, same goes for the JavaScript, IE has one model and rest of browsers has another Model (I mean like Event Handlers and attaching events).
If new competitor comes, it has no chance, neither it has so much time as css and javascript had.