As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am new to JavaScript. I am referring to a page on JavaScript framework: What is a JavaScript framework?
I know JavaScript is for the web client side. It is a object-oriented script language. The link above writes:
Using JavaScript, however, is not an easy task, primarily due to the complications that arise when trying to provide support for multiple Web browsers.
Like HTML and CSS, different browsers have separate implementations of JavaScript, and it can be a nightmare to ensure that your JavaScript code is cross-browser compatible.
The second part says different browsers has different implementations. Why?
Since JavaScript is just a language like Java, C etc. Why do different browsers need different implementations?
As long as the JavaScript language specification is released, each browser should follow the language requirement. So why they have different implementations?
What does the implementation here mean?
EDIT:
JavaScript is NOT a object-oriented language! It is a language based on objects!
"Implementation" here is the engine that was implemented by a browser vendor according to ECMAScript specification.
As long as the java script language specification is released, each browser should follow the language requirement
And they do
So why they have different implementations?
Because they follow the same specification but build their own engine.
That's just the way it is. Not every browser uses the same JavaScript engine, click the link if you want to read some interesting history.
They all try to be the fastest. And yes they should all follow the exact same specification, and I'm sure they have followed the exact same specification, but there are still people involved, and they might interpret the specification slightly differently.
These engines are being developed in parallel (at the same time), as none of their developers have time to wait for the others to develop something first, and then check to see if they can comply with the exact same interpretation of the specification as their competitors.
JavaScript is an ECMA standard programming language and does not need to run in a browser. The browser has a JavaScript enginge that runs the script for you but not all browsers run it the same way.
Notabley is the way IE and other browsers handle events and new features are sometimes not supported. IE implemented things like innerHTML wich was not ECMA standard but because of it's popularity other browsers adopted it. It might be part of the standard now but I'm not sure.
The reason for this is that when NetScape came with JavaScript support IE implemented it as well but with other (extra) features. Since they both try to compete to be the "better" browser they didn't work together on making a standard.
A good source for JavaScript usage in browsers is MDN It usually shows you browser support for JS methods and properties as well as some code to add some support for browsers that don't support certain features (like DOMParser parsing text/html)
In the last couple of years IE has made a move to be more ECMA complient so hopefully in the future we would have to rely on less and less feature detection in our JavaScript code.
You still have a problem that JavaScript is a still evolving language and more and more features are added. When they are new than browers will still implement it differently or not implement all featueres (like webcrt). You might also have to support browsers that are a couple of years old and a lot of things change in a couple of years.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
We are working on a web application which only supports "modern" browsers (basically IE9 and up, and any other browser which has roughly the same amount of modern features).
Our web application will also work on mobile devices like tablets and smartphones.
Since this is a web application (as opposed to a normal website), we are okay with some users being left out in the cold for some of the advanced features which rely on modern features (i.e., older browsers).
However, we want to at least display a message letting them know.
We want to maintain basically two lists: "supported browsers" and "unsupported browsers", with a third implicit list "not supported browsers" (i.e., browsers that are on neither least).
If the browser was on the supported list, we wouldn't show anything.
If it is on the "unsupported" list, it will always show a message which says "This browser is unsupported, please upgrade blah blah".
If the browser is not in either, it will display a message (which can be almost-permanently dismissed) which says something like "This browser isn't tested directly against our site and some features may not function as intended. If you experience any issues, please report them blah blah".
Building this and what not isn't an issue. However, I was wondering if there was some site/service out there with an API that already did this sort of thing, or at least maintained lists of browsers which I could pull from. (If not, I just plan to use manual testing combined with info from sites like "Can I use..." and Modernizr).
Any ideas?
Poking around online all the resources I've looked at say that you should essentially never use browser detect. It's better to test for features you know DO NOT exist in the browsers you can't support instead of trying to look at the user-agent string.
http://www.quirksmode.org/js/support.html (If you want to know whether the browser that views your page supports certain objects you want to use in your code, you should never EVER use a browser detect. )
http://api.jquery.com/jQuery.support/ (Rather than using $.browser to detect the current user agent and alter the page presentation based on which browser is running, it is a good practice to use feature detection.)
So I think your approach with modernizer is probably the best.
You don't need a service.
The 'supported' list contains only those browser/device/OS combinations that you actually test.
The 'unsupported' list contains those browser/device/OS combinations that you know don't work (i.e, they failed your tests)
The 'might work' list is implicit as you've mentioned.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
It seems with HTML5/CSS3, there is a larger push towards CSS-only animations, effects, navigations, etc.
Is this purely because of the tendency of C/Java/etc developers to use JavaScript 'incorrectly' (mostly in a semantic sense, I guess)?
Or is there an advantage of CSS over JavaScript? If so, why would CSS be better? Is it faster?
Also, semantically-speaking, shouldn't CSS only be used for styling/positioning? So is CSS starting to go outside the bounds of what it was designed for?
Is this purely because of the tendency of C/Java/etc developers to use JavaScript 'incorrectly' (mostly in a semantic sense, I guess)?
No, you've just about missed the point by a mile. The main reason people use JavaScript is because they want to support as many browsers as possible. CSS3 is a new technology, which only the latest and greatest browsers understand, whereas JavaScript has been around for decades.
Or is there an advantage of CSS over JavaScript? If so, why would CSS be better? Is it faster?
Yes, because the browser knows best how to make use of system resources to perform animations, and it can do that job best when implementing them natively using CSS (e.g. hardware acceleration). With JavaScript, you're relying on a browser's scripting engine to calculate animations for you, which can get very expensive.
But as mentioned above, the greatest drawback is lackluster support.
Also, semantically-speaking, shouldn't CSS only be used for styling/positioning? So is CSS starting to go outside the bounds of what it was designed for?
Broadly speaking, it has always been meant for presentation — separating that as a concern from content and structure, when HTML was riddled with presentational attributes munged all over the place, spelling development hell for any frontend developer of their time.
All these fancy effects you describe can easily be categorized under presentation (i.e. they don't have anything to do with application logic, business logic, content, data, etc), so it would seem apt that they should be done with CSS. And that brings us where we are today.
So, to summarize:
JavaScript is used when browser support is a foremost priority (and in business applications it almost always is). It is also often maintained as is if it's too costly to convert or migrate to another technology.
Otherwise, CSS is used. Of course, a JavaScript fallback is often provided. You'll often see this in experiments or new/startup projects.
I can't see a VS here. Actually I think a great web app should be made mixing both of them!
I like to think about JavaScript for user interactions and CSS for design. That's how I decide which one I should use for a specific purpose.
Now days you have a lot of great works from brilliant people in order to solve the compatibility issues. E.g.: http://modernizr.com/
One major issue is that not everyone's browser has Javascript enabled. So if you can achieve the same effects with HTML5/CSS3 it has the advantage that it will work on all modern browsers regardless of whether or not they have Javascript enabled.
Yes, css is faster than javascript.
In addition, javascript require additional http request, while you can avoid that if you'll use only css.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
OK, so I'm trying to learn JavaScript properly so that I can write good, clean client-side code, but whenever I think I'm making progress, something stops me dead in my tracks!
I want to know:
What is the different between JavaScript, ECMAScript and JScript?
Which should I focus on learning?
If these are versioned, which version should I be supporting?
Are there any really good references (web / books etc) that are a must have/read?
How do I ensure that what I write will be compliant with all major browsers (IE, FF, Safari, Chrome, Opera etc.) ?
MOST IMPORTANTLY...Is there a reference of the core objects (Array, Number etc) so I know what is implemented already and what I need to do myself?
Thanks.
Javascript is the original name when the language was developed by Netscape.
JScript is Microsoft's name of their own implementation.
ECMAScript is the name of the language standard developed by ECMA, from the original Javascript implementation.
So, it's just one language, with different implementations.
The implementations of Javascript and JScript differ somewhat in what they support, but each version supports what's in the corresponding version of the ECMAScript standard. Generally you just use what's supported a few versions back, so that it works in all the browsers that are still in use.
One reference is the Mozilla Developer Network, as Mozilla is the current developer of Javascript. For each method and property you can find which version it is supported in.
JScript is documented at the Microsoft Developer Network, and has similar information about support. (Note that all Microsoft documentation is there, not only JScript, so for example you would need to search for "jscript array" rather than just "array".)
Using a library like jQuery is useful to avoid dealing with some of the compatibility problems between browsers.
ECMAScript is the scripting language standardized by Ecma International in the ECMA-262 specification and ISO/IEC 16262. The language is widely used for client-side scripting on the web, in the form of several well-known dialects such as JavaScript, JScript, and ActionScript.
Depends on you, but I think most commonly used for web dev is JavaScript
JavaScript was formalized in the ECMAScript language standard and is primarily used in the form of client-side JavaScript
I would recommend this book
By learning more and more about the language itself and writing tests
Look here
It is important to understand, that ECMAScript is a standard, defined in the last century. :D Whereas Javascript is derived from ECMAScript. Derived in a sense, that it implements the standard.
The big difference is, that Javascript actually only exists within the Browser, saying, it is by no means a standard in itself. Every browser can (and a lot do) implement it's own methods.
So, if you seriously want to learn it and write clean code, then IMHO you have to first get familiar with the ECMAScript standard.
To 3: Since Javascript is implemented by the browser, this really depends on what browsers you want to develop code for. Older browser may have to be dealt with trought some seperate handling in your code.
To 5: Again, javascript can check what browser (or what client software in general) requestet the page it is loaded in. Meaning: If bad comes to worse, you can deal with each browser seperately in your code. But most of the time they are pretty compliant (at least the later versions)
On 4 and 6 I'd have to check first for myself.
Hope I could help you out a bit.
Regards
ECMAScript is the language, JavaScript and JScript are dialects
I would, personally, look at and learn JavaScript.
It depends on what browsers you want to support, easily googled.
MDN is a pretty good web source. JavaScript: The Good Parts and JavaScript: The Definitive Guide are both very good books, the first short and concise the latter very detailed.
JavaScript libraries like jQuery is very good for this reason. It all comes down to learning all the quirks of the browsers. Google is your friend.
MDN.
Wikipedia please.
Javascript is a language, this is probably what you want to learn rather than a spec.
Welcome in hell, all. Modernizr and jQuery exists for a reason. Unless you are doing Javascript on the server side with Node.js for example, in this case you can focus on only one JS Engine (V8 for Node).
MDN
Test, Test, Test and re Test. Try never to use too recent features and use libraries.
MDN tells you which browser supports what.
They're one and the same - for an history on JavaScript watch the Douglas Crockford webcasts on YouTube.
http://youtu.be/_DKkVvOt6dk
http://youtu.be/hQVTIJBZook
2,3,4. Start with this http://eloquentjavascript.net/
Libraries like jQuery do a good job in normalising behaviour across browsers.
I think this is what you are looking for http://dochub.io/#javascript/
In Coders at work, Douglas Crockford discusses how bugs in browsers cause Javascript to be a complex, clunky language and fixing it is a catch-22. In Beginning JavaScript with DOM scripting and Ajax Christian Heilmann says something similar "[The] large variety of user agents, of different technical finesse [...] is a great danger to JavaScript."
Why doesn't JS have a breaking new version? Is there something inherent n the language design where backwards compatibility becomes a must?
Update
Why can't javascript run with multiple engines in parallel? Similar to how .NET runs versions 2, 3 and 4 on the same machine.
Lazy copypasta at OP's request:
JavaScript is just a programming language: syntax and semantics. It has no built-in support for browsers (read: the browser DOM). You could create a JS program that runs outside of a browser. You (should) know what an API is - the DOM is just a JavaScript API for manipulating an HTML page. There are other DOM APIs in other languages (C#, Java, etc.), though they are used more for things like XML. Does that make sense?
Perhaps this MDC article can clarify further.
Well a breaking change would break a lot of existing websites, which would make a lot of people very angry :)
Backwards compatibility is important because of the large number of browsers deployed and the wide variety of versions of those browsers.
If you serve a new, incompatible kind of Javascript to old browsers, they all break.
If you invent a new language that is not considered to be Javascript by existing browsers, then it doesn't work with the majority of browsers. Very few users will be willing to download a new browser just to work with your new language. So web developers have to keep writing compatible Javascript to support the majority of the users, no matter how great the new language is.
A lot of people would like to see something better than current Javascript be supported by browsers, but it just isn't going to happen any time soon. All the makers of browsers and development tools would have to support the new thing, and continue to support the old Javascript stuff too. Many interested parties just wouldn't consider the benefit to be worth the cost. Slow evolution of Javascript seems to be the only viable solution.
As a matter of fact, ECMAScript 5 is not fully backwards-compatible for the very reasons you mentioned.
Inertia.
Making a breaking change would break too many sites, no browser vendor would want to deal with all the bug reports.
And PHBs would be against targeting a new version, why should they have their developers write javascript for the broken and the fixed languages? Their developers will have to write it for the broken version anyway so why bother with 2 implementations (which from a developer perspective sucks too since now they have to update, support and debug 2 separate trees).
Ecmascript 5 has a "strict" mode. I think this strict mode is intended to combat the problem you mention. Eventually you'd mark scripts "strict" that you want to use the new engine, all others get run in an old crufty VM, or with un-optimized codepaths or whatever.
This is kind like IE and Mozilla browsers having multiple "modes" of rendering websites (IE even swaps out rendering engines).
See this question about it
Javascript has subtle differences across different browsers. This is because each browser manufacturer has different sets of responsibilities to their users to support backwards compatibility (if any). If I had to pick, I'd say the biggest barrier to the advancement of javascript is older versions of Internet Explorer. Due to service agreements with their users, Microsoft is contractually obliged to support older browsers. Even if other browsers cutoff backwards-compatibility, Microsoft will not. To be fair, Microsoft does realize how terrible their browsers are and will hopefully push IE 9.0 very hard. Despite the inconsistencies of javascript across different browsers, they are subtle enough to make cross-browser programming more than feasible. Abruptly cutting off backwards-compatibility would be a practice that would make web development a nightmare. Incrementally cutting of backwards-compatibility for specific aspects of javascript is feasible.
There is much more else wrong with JavaScript. You can't be fully backwards-compatible with things that were never fully compatible when they were fresh... Say, the length of the array [1,] is reported as 2 by at least older versions of internet explorer.
The biggest fault of JavaScript is that is comes with a tiny, incomplete and pretty much unusable standard library. That is why everyone retreats to using jQuery, Dojo, Mochikit etc. - these offer mostly functionality that should be part of some standard library included with the browsers instead of floating around in thousands of copies and versions. It's actually what makes .NET and Java so popular: the language comes with a reasonable standard library. With C and C++, you have to dig out the nice libraries (Boost e.g.) yourself.
But other than that, the ECMAScript standard occasionally is updated.
Google is also trying to do this bold step forwards and redo JavaScript in a slightly more sane way. The efforts are known as Dart: http://www.dartlang.org/
For all I can tell, Dart largely uses the syntax of JavaScript minus a couple of its quirks. Apart from that, it also is nicer for the virtual machine and will thus likely run faster (unless of course you compile Dart to Javascript and use a JavaScript VM; which is offered as a compatibility option). But of course any hardcore JavaScript nazi^W enthusiast will not like anything that claims to be better than JavaScript. Whereas for me, they don't go far enough. In particular, they still don't provide enough "classpath".
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
From searching SO, this question was already asked, almost a year ago now.
So now with the new FF, Opera, IE, is it finally time to start developing sites with HTML5 or is it still a little premature and will cause compatibility issues?
Is using HTML5 just going to require us to use more and more JS on websites to 'trick' older browsers into working properly?
It's a great idea if used in a "Progressive Enhancement" way. ie. Code your website to work in "standard" HTML 4.01 mode, and then add some fancy HTML 5 bits to give it some extra flourishes in browsers that support HTML 5
If you add nice features to your site, it is possible it will be talked about and reach the news sites for some free publicity.
Aside from that, It would make a good beta site and give you a head start for when it becomes the new technology. However, until HTML 5 enabled browsers are widespread (at least 20% of the market, possibly 50%) it makes little sense to alienate nearly the whole internet.
If there is a feature in HTML 5 would be useful for the project you are working on, then it is worth considering using it.
You will need to weigh the benefits against the possibility of the specification changing, the less mature testing tools available for HTML5 validation and the probability that you will need to use JavaScript to fake support in older browsers (of course, the HTML 5 spec gives a roadmap that someone else may have already followed in writing such JS).
If HTML 4.01 gives you everything you need — stick with that.
Assess your target audience. Are they likely to be early-adopters? Is it critical that all visitors to your site are catered for? Or will a few not mind being met with an inconvenient, yet polite "please upgrade your browser" message?
For business sites I'd say no. Not yet, anyway. You probably can't afford to lose users of older browsers.
For a personal website or project, why not? It'll be great experience learning the latest HTML5 features, and you'll be ahead of the curve when it does become mainstream. Besides, more people writing sites conforming to HTML5 means more pressure on users of older browsers to upgrade, benefitting all of us in the long run.
The answer is most certainly YES. Firefox, Safari, Chrome and Opera make up more than 30% of the market and they support many HTML5 standards:
Audio & video tag
New tags (footer, header, section, etc)
Canvas
HTML5 doctype (<!DOCTYPE html>)
validator.w3.org supports HTML5 validation (it's experimental, but it seems stable)
For IE you can use these things to make some HTML5 elements work:
HTML5 shiv: http://ejohn.org/blog/html5-shiv/ , this allows you to style new tags in IE
Fallbacks for IE when using the video tag: http://hacks.mozilla.org/2009/06/html5-video-fallbacks-markup/
ExplorerCanvas: http://code.google.com/p/explorercanvas/ , allows the use of canvas in IE
And IE supports the HTML5 doctype, it simply renders in strict mode, which is fine.
Hope that helps, and gets you started using HTML5!
Bruce Lawson of Opera gave an interesting presentation on this at OSCON, see his slides; the verbal conclusion was that it's OK, though there was some debate. Of course that's from somebody working for a browser maker so they're going to be less worried about older browsers (since everybody upgrading is to their advantage;-). The more you need to worry about older browsers, the worse your life is in general of course, but html 5 wouldn't help you there, sigh!-(
I have begun developing pages with the new HTML5 DOCTYPE:
<! DOCTYPE html>
This new DOCTYPE essentially puts the browser into a sorta "standards-based mode." Obviously this is all pretty new to most browsers but creating pages under this DOCTYPE will allow sites to last longer than ever. This also degrades gracefully within every browser I have tested in and no noticeable HTML or CSS downsides.
W3C has began using an experimental validator for HTML5 which can be used the exact same way as all of their other validation engines. An intersting side note: According to the W3C validator, you do not need to close the BODY or HTML tag at the end of the page; allowing for very minimal load time decreases.
As HTML5 continues to make its way to the forefront, I plan to begin implementing more advancements that just the DOCTYPE. For now that seems to be all that is new and widely supported.
Hope this helps.
-B
This site has a pretty good HTML5 shiv for IE. Just include it on you page and you can then style the HTML5 elements.
http://html5.adamhunter.me/examples/html-shiv