I am using a babel transpiler for react ecma6 projects ,but It seems that chrome already supports ecma6 functions, methods and syntax. Is the transpiler really needed. syntax wize, what is the traspiler part in the workflow? Which functions or methods arent supported in chrome?
Refer to http://caniuse.com/, a site to check compatibility/implementation status.
Personally, I would still transpile at this time as not everyone uses Chrome as their browser. If you know you only have Chrome clients (intranet for example), you can use most ES6 features.
A huge feature for me are imports and exports which are not part of most browsers at this time, so your mileage may vary.
I agree with Mario about http://caniuse.com/, and you can get more detail on https://developer.mozilla.org/en-US/docs/Web/JavaScript for each browser feature you may need.
Always consider your lowest common demoninator. Usually IE, but sometimes that depends these days with FF, Safari mobile, etcetera. If your lowest required browser/platform does not support the feature, you can use something like a Babble module to transpile on-the-fly, or just grab the polyfills from MDN which usually has well written and maintained code.
About polyfills - in case you venture to write your own:
http://www.codeproject.com/Articles/369858/Writing-polyfills-in-Javascript
http://javascriptplayground.com/blog/2012/06/writing-javascript-polyfill/
Related
As a lone developer with limited resources, I made the decision some time ago not to continue support for IE8 and IE9.
To manage the situation I use IE's conditional comments - I now also use Modernizr to detect support for individual features, which the above browers do not support anyway.
Javascript is also a given for me - if you don't have it, then sorry but we can't do business.
I was therefore considering removing conditional comments and letting Modernizr/javascript do the job.
Conditional comments do break a lot of things that scrape the site - for instance CopyScape will not work - there's also testing software I use that breaks and/or gives out false signals.
Does anyone have any cast iron reasons NOT TO remove them or TO remove them?
Given that support for conditional comments was removed from IE10, I would recommend against using them at this point in time. It's 2017; time to move on. (That's my take, anyway; YMMV.)
I would consider providing a bare bones version of the site designed for any browser other than your preferred one (which, conveniently, also helps you support experiences you didn't plan for).
Assuming I already have valid code, is there a tool or plugin that I can use to evaluate my website code and highlight areas where different browsers could potentially display the code differently? I am aware of websites like browsershots and I have VMs to test, but I'm wondering if there is something to shortcut the process by looking at the code and warning of well known cross-browser compatibility red flags.
For example, when using CSS which is not universally supported yet. The following is valid CSS 2.1:
display: run-in;
Validators which are aware of CSS 2.1 will pass it with flying colors, but really, a red flag should be thrown, indicating that it does not work in Firefox 3. On the other hand,
border-radius: 10px;
is actually pretty well supported in updated browsers, even though it is CSS3.
This is new in Javascript, but is also passed by validators:
getElementsByClassName();
but it would be better if a warning popped up notifying me it won't work in IE8.
Another example is well known rendering bugs, which can be triggered by weird (valid) situations. I understand there is no replacement for opening up the website in every single browser on every system to really see how it works, but I am just wondering if there is some tool that can help check that I'm writing interoperable code as I go, so that I can test more frequently in the development process and spend less time working out bugs later.
Unfortunately, the answer is no.
I once started looking into creating a tool exactly as you describe. The reality is that most libraries like jQuery actually make use of browser incompatibilities and different interpretations of standards (or ignoring the standards).
So, if you're using any of the standard libraries then you'd receive tons of warnings and actually get very little out of it. The amount of spam simply will shadow the actual bug you might have introduced.
What matters more is whether the incompatibilty actually affects the end result. Hence we went for what-you-see-is-what-you-test method instead of static code analysis.
My question is borne out of my confusion on (still incomplete, with existing features still evolving?) HTML5 support in different browsers, all the resources available on how to implement existing features and simple practicality.
1) How do you go about implementing HTML5 only features in your web-site? Do you do some kind of browser/version check at first access and notify user that he should install some other browser (though cumbersome and uncomfortable to the user)?
2) Is there a way to check availability of HTML5 features in user's browser dynamically (version X of Chrome does not support it, next might and it should work then) and easily without some significant computing overhead and significant coding?
3) Assuming the answer to 2) is yes, what to do about changes in spec that might occur in the future? (The check would say fine, the browser does implement e.g. WebGL, but my implementation would run into errors as there would be some changes between the spec I had used during development and spec that was enhanced in the W3C process and would make my implementation incompatible)
to start using html5, make sure that the first line in your html is <!doctype html> this tells the browser that you are speaking in the language of html5
this google-hosted html5 shiv helps to ensure that the new html5 tags work in older browsers and as someone already pointed out, you can and dare I say it, should use modernizr to test the browser's CSS rendering capabilities
This is just something you need to keep abreast of yourself unfortunately ;) The way I look at it, if the spec changes in a big way, lets say they decided to remove the <article>, there will be a lot of chatter online and you are likely to read about it
I recommend that you take a look at html5-boilerplate. It's a A rock-solid default for HTML5 awesome.` It's a starter kit with template html, CSS and Javascript files for building an html5 website.
This is useful: http://www.modernizr.com/
As for 3: I think that's just a risk of using a technology before it's out of spec.
Take a look at modernizr, it's a js library that will do various feature detection tests and gives you a way to query whether or not to use a particular feature. You can also load specific js files with modernizr.load based on whether a feature is supported in the browser.
http://www.modernizr.com/
Tutorial: http://www.alistapart.com/articles/taking-advantage-of-html5-and-css3-with-modernizr/
Both seem to be used in web development circles, see e.g. HTML5 Cross Browser Polyfills, which says:
So here we're collecting all the shims, fallbacks, and polyfills...
Or, there's the es5-shim project.
In my current project we're using a number of these, and I want to stick them all in the same directory. So, what should I call this directory---shims, or polyfills?
A shim is any piece of code that performs interception of an API call and provides a layer of abstraction. It isn't necessarily restricted to a web application or HTML5/CSS3.
A polyfill is a type of shim that retrofits legacy browsers with modern HTML5/CSS3 features usually using Javascript or Flash.
Answering your specific question, call your directory shims if you want to keep the directory generic.
Shim
If you are familiar with the adapter pattern, then you know what a shim is. Shims intercept API calls and create an abstract layer between the caller and the target. Typically shims are used for backward compatibility. For instance the es5-shim npm package will let you write ECMAScript 5 (ES5) syntax and not care if the browser is running ES5 or not. Take Date.now as an example. This is a new function in ES5 where the syntax in ES3 would be new Date().getTime(). If you use the es5-shim you can write Date.now and if the browser you’re running in supports ES5 it will just run. However, if the browser is running the ES3 engine es5-shim will intercept the call to Date.now and just return new Date().getTime() instead. This interception is called shimming. The relevant source code from es5-shim looks like this:
if (!Date.now) {
Date.now = function now() {
return new Date().getTime();
};
}
Polyfill
Polyfilling is really just a specialized version of shimming. Polyfill is about implementing missing features in an API, whereas a shim wouldn’t necessarily be as much about implementing missing features as it is about correcting features. I know these seems overly vague, but where shims are used as a more broader term, polyfill is used to describe shims that provide backward compatibility for older browsers. So while shims are used for covering up old sins, polyfills are used for bringing future enhancements back in time.
As an example there is no support for sessionStorage in IE7, but the polyfill in the sessionstorage npm package will add this feature in IE7 (and older) by using techniques like storing data in the name property of the window or by using cookies.
From what I understand:
A polyfill is code that detects if a certain "expected" API is missing and manually implements it. E.g.
if (!Function.prototype.bind) { Function.prototype.bind = ...; }
A shim is code that intercepts existing API calls and implements different behavior. The idea here is to normalize certain APIs across different environments. So, if two browsers implement the same API differently, you could intercept the API calls in one of those browsers and make its behavior align with the other browser. Or, if a browser has a bug in one of its APIs, you could again intercept calls to that API, and then circumvent the bug.
Citing Axel Rauschmayer from his book Speaking JavaScript:
A shim is a library that brings a new API to an older environment, using
only the means of that environment.
A polyfill is a shim for a browser API. It typically checks if a browser
supports an API. If it doesn’t, the polyfill installs its own
implementation. That allows you to use the API in either case. The
term polyfill comes from a home improvement product; according to Remy
Sharp:
Polyfilla is a UK product known as Spackling Paste in the US. With that in mind: think of the browsers as a wall with cracks in it. These
[polyfills] help smooth out the cracks and give us a nice smooth wall
of browsers to work with.
A fantastic article written about this from a few years back that explains this well:
What is a Polyfill?
In the article the (2) are simply contrasted as such:
Shim: a piece of code that you could add (i.e. JavaScript) that would fix some functionality, but it would most often have it's own API.
Polyfill: something you could drop in (i.e. JavaScript) and it would silently work to mimic existing browser APIs that are otherwise unsupported.
Polyfill is just a script that will check a certain API existence in the browser, ok?
If the API doesn't exist in the browser polyfill(which is a simple script) will act something like this:
for example, I'm gonna use Bluetooth API in the browser and I know some browser doesn't have such API so I will write something like this in order to check my API existence:
if(!navigator.bluetooth) { // write polyfill here }
Shim is a script as well which mostly provided as a plugin or library and how it works?
Actually, it will override an already existing API and implements a different behavior in order to support new APIs in older browsers.
It worth noting that Shims mostly are used for backward compatibility.
i was wondering what would be the best way to code a browser plugin that is for multiple browsers.
Due to the fact that each browser uses other ways of implementing plugins there should be a library or something with the basic functionality and a wrapper for each browser. So, to be more precise, with which language the library should be programmed?
The plugin shall implement functions like: Retrieving files from another server (via SSH) and sound playback.
Regards
macs
It's all about common denominators when you're doing cross-platform stuff. You need to pick the things that you know will work on all your targets. This will require some research on your part. I know this answer is a bit vague, but you don't state exactly which list of browsers you wish to support. Is it just Firefox, IE, and Safari? Opera as well? These are things you have to think about.
That said, your best bet is to pick a language that is supported by each browser you wish to target.