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.
Related
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/
I was doing a research about HTMl5 and This 2 comes out. One call Modernizr and the other one is Boilerplate. I want to know:
1.What is the different between Modernizr and Boilerplate?
2.Is it possible to run those together?
Modernizr is a feature detection library: it contains a range of tests you can use to determine whether a client supports various HTML5/CSS3 features. This allows you to use the standard features where available and fall back on hacks or shims when necessary.
Boilerplate is a collection of 'best practices': a CSS reset, some server config and so on, all with good sound defaults for HTML5 development.
You can and should use both in your HTML5 projects.
I want to make an application for J2ME phones.
In that application I want to use HTML5,
how I can do this?
I worked on LWUIT. Does LWUIT support HTML5?
Or give me any other browser info.
LWUIT/Codename One support HTML5 but not on J2ME.
There's no built-in HTML5 (or any HTML version, for that matter) parser or renderer in J2ME. There's some sort of HTML viewer support in the LWUIT library, but I suspect it is reasonably limited in general, and also in particular regarding specifically HTML5 support. In any case, research LWUIT and see if it is enough for your needs or not (hard to say without knowing your real/actual requirements).
It is also not very practical to write your own HTML parser and renderer (especially if you also need to be able to handle CSS and JavaScript). In essence, you'd have to write your own complete web browser in J2ME.
You can, of course, use platformRequest() to launch the default browser, but not that many mobile phones have HTML5 support yet.
If you also manage the server-side (where the HTML5 pages come from), and all you really need is the data, then write the server code to return/send the data to your J2ME MIDlet as either XML or JSON, which are much easier to handle.
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/
Is there reliable a way to detect such browser capability from the user agent string?
HTML5 isn't a server-side language.
Anyway, there isn't a way to reliably detect UA capabilities, for instance they could have Javascript turned off, addons installed, etc. etc.
You could use some SS methods such as PHP's Browser Detect, but aside from that there's nothing more you can really do. This is not at all comprehensive at all, though!
Everything such as this should really be done client side in Javascript, as you can easily detect what's available and what isn't. There's a number of libraries out there that will do this, but it's very simple to do yourself if you know what you want so using one shouldn't really be required. Furthermore, you should never want to do this based on User Agent strings, as I mentioned before there's addons available that can modify behaviour etc. You should literally just check for the feature you wish to use rather than restricting yourself to a certain version of the browser.
Not reliably — you’re stuck with figuring out the browser version from the user-agent string, and maintaining a list of which browser versions support the API.
You could, however, detect it on the client side using JavaScript:
Modernizr
Mark Pilgrim’s suggested History API detection code
and then do a redirect via JavaScript (i.e. by setting window.location) to let the server know whether the API is available or not. That would be the usual way to redirect to a URL starting with # (as per your comment on rudi_visser’s answer.
This is not server side (so it probably does not answer your question, I thought it would be helpful though):
Have you looked at Modernizr
It is a javascript file you include in your HTML page. You can then use its properties to detect if a particular HTML 5 tag is supported by the browser.