I've seen it mentioned in a few places that Browserify isn't compatible with IE8 and below (here, here, and alluded to here).
I don't see anything official about this in the docs. It looks like it may be the use of Function.prototype.call() but I can't tell for sure.
Does anyone know for sure:
how far back IE is supported
what code (if any) is incompatible with IE8
any recommended workarounds for IE8 specifically
I use Browserify for my library http://github.com/pllee/luc to build all of the browser code. My tests pass on IE6 and I am using ES5 shim but I don't think that would make Browserify work (chicken and egg situation). Those links you show are quite old and I know Browserify has changed its implementation since then.
You can see on their official page that they do support IE7 and greater.
Related
IE11 does not and will not implement ES2015 Proxy objects. Yet IE11's end of extended support is October 14, 2025.
Is there any way to polyfill Proxy objects for IE11? All other browsers support Proxy already.
If yes then we would all be able to use it in production today. If not then we'll have to wait almost a decade...
Edit: I'm asking specifically for IE11 as I know IE to usually have IE specific features that I'm often not aware of.
Edit2: I'm particularly interested in being able to implement a catch-all interceptor. Similar to __getattr__ in Python. It only has to work in IE11.
Best you can get is github: GoogleChrome/proxy-polyfill
According to Babel docs:
Due to the limitations of ES5, Proxies cannot be transpiled or polyfilled.
There's quite a concise answer for this question on Quora
Proxies require support on the engine level and it is not possible to polyfill Proxy.
Most major JS engines have yet to implement support. Check out the ECMAScript 6 compatibility table.
You may want to use Object.observe instead, possibly with polyfills for browsers other than Chrome, but even then the proposal has been withdrawn, and it has been announced it will be removed from Chrome in a future version.
I personally haven't tried the Object.observe solution but it might be a good place to start.
Good luck!
EDIT:
Thank you to Matt Jensen in the comments for pointing out there is infact a way to polyfill some parts of ES6 Proxy using this package: github.com/GoogleChrome/proxy-polyfill
AWESOME
Direct solution for polyfilling ES6 Proxy in environments without support this feature, of course is impossible - if storing some polyfill function info window.Proxy is meant. But if thinking this way, most modern features of ES6 can't be supported, because they will raise syntax error for old-version ECMAScript engine.
That's why you should use transpiler, which perform preceding wrapping ES6 code into specific constructions, and then evaluate transformed code on old engine. In current case, just use one Babel plugin: https://www.npmjs.com/package/babel-plugin-proxy
Of course, while using this solution, you should configure Webpack to segregate target bundles for different client agents / browsers, depending on it's feature set discovery. See details here: https://gist.github.com/newyankeecodeshop/79f3e1348a09583faf62ed55b58d09d9
I don't understand the best way to use "let" keyword...
In IE11 and Chrome45 I can use it fine
In Safari8.0.4, like in older versions of Chrome, it gives the error "unexpected use of reserved word 'let'"
In Firefox the let keyword only works inside <script type="application/javascript;version=1.7"/>, but this script type isn't even recognized as Javascript in IE11, Chrome45, Safari8.
Here's a JSFiddle that shows it in action: https://jsfiddle.net/p6cgtyg6/1/
So -- I don't mind requiring users to use modern versions of their browsers.
And I don't mind excluding Safari if there honestly is no version of Safari that supports this keyword. (Is that really true? Why does everyone spend all their time griping about IE when Safari seems so much worse in ES6 terms? Have I missed something?).
But how should I allow "let" to work in Firefox while not preventing Chrome/IE? (I haven't yet found links from people griping about how Firefox script tag behaves differently from Chrome, and I'd have expected more complaints, so I figure I must have missed something obvious...)
Concerning Safari 8, it's just not supported ; for that browser, I'd recommend using Babel.
If you have the gut feeling that this bug won't be fixed anytime soon* then you could have a script that detect Firefox which would then inject your script(s) with the appropriate value for the type attribute.
As a side note, I would advise not to use let blocks—unless you wanna use this transpiler—nor let expressions which will be dropped.
* fixed in Firefox 44
let is a part of ECMAScript 6 specification, and ECMAScript 6 itself is in 'draft' status. Even in its incomplete form its features aren't supported fully by actual browser versions.
Since you want to dive into ES6 today for production, your best bet is to use ES6 to ES5 transpiler, most prominent ones are Babel and Traceur, which are available as both CLI and packages for the build system of your choice. There are online tools for Babel and Traceur to try them out. And Scratch JS extension for Chrome uses both Babel and Traceur and is excellent for developing and compiling ES6 scripts if the build system is not an option.
Here is up-to-date comparison table that embraces ES6 feature support in both browsers and ES6 compilers.
And here is a great collection of ES6-related tools.
See browser compatability of this ES6 keyword.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let#Browser_compatibility
Also see this SO post for ES6 feature detection.
Underscore.string seems to provide nice features for javascript string manipulation.
It seems to have all the good points:
license : MIT
dependencies : none, it is an extension for Underscore.js but it can be used as standalone, without underscore.js
weight (minified & gzipped): 4KB
community, contributors: 58 contributors on Github
history, contributions: since mid 2010 on Github, contributions seem rather stable although pretty quiet since 2014
Except one point for which I am missing info: the "browser support/compatibility". I am especially worried about older version of IE.
I could find some issues (who have been fixed) on Github for various browser versions, but I could not find any clear statement regarding the browser support:
https://github.com/epeli/underscore.string/pull/37
https://github.com/epeli/underscore.string/issues?q=IE8
https://github.com/epeli/underscore.string/issues/115
I also searched on StackOverflow & did some googling but no luck.
I assume there is no "official" support for browsers so if anyone has experience in using Underscore.string in a production environment where users are on old browsers (IE8+) that would be great.
EDIT:
I also added a question directly on Github to try to get an answer, I'll update this page if I hear anything from there. See https://github.com/epeli/underscore.string/issues/304
As pointed out by epeli on the issue I posted on the Github project: running the test suite on IE8 seems a good way to find out if this library is supported by IE8.
Hence I did so, and found out that the result was positive: IE8 is supported by Underscore.string javascript library.
See the result of my test below
I'm really interested in finding out about ES6 Template Strings and have been doing a little bit of reading on the feature.
However now that Chrome Canary does not support it (although maybe I'm wrong about that!) is there anywhere/anything I can use to try out this new functionality? Any browser beta around that does?
I've already enabled Experimental Javascript Features inside chrome://flags
It's only supported in Traceur at the moment.
You can play with it in their REPL.
es6fiddle.net doesn't seem to support it yet, but probably will soon.
Mozilla is working on it so expect to see it in nightly builds soon as well.
It's Supported in
Edge
Firefox
Chrome/Opera
Webkit
Missing in safari ;( though
cough safari is the new ie cough
source
Regarding template strings and support for ES6 features
I would also use traceur to play around with most ES6 features, but have a look at this ES6 compatibility table, it's invaluable when you want to find out which platforms/transpilers support which features.
For anyone else landing on this question, go and check out tagtree's videos onn ES6 features.
To see template strings, arrow syntax and desctructuring, have a look at this free tagtree tutorial screencast, no registration is required.
1.3.0 — Jan. 11, 2012 Removed AMD (RequireJS) support from Underscore. If you'd like to use Underscore with RequireJS, you can load it as a normal script, wrap or patch your copy, or download a forked version.
Why have they done it? Does anyone know? Because they added it only few month ago (in October), and AMD (Asynchronous Module Definition) is said to be far superior to CommonJS modules.
Update: As of December 2013, this has been supported again.
Jeremy gave his reasoning in the comments of the commit:
Yep. Not supporting a particular script loader will definitely make it easier for all of them to work properly.
I apologize for merging the support in the first place.
He also tweeted a bit more on the change (link from a later comment):
… because AMD support is breaking regular Underscore embeds on pages that also happen to use Require.js …
The developers of Underscore thought that having AMD support would break support on non-AMD enabled scripts. This is actually not the case, as you can have a script that is both AMD-enabled but also works as-is on a non-AMD deployment.
There is now a drop-in replacement for Underscore: Lo-Dash. Which, along with other features not in Underscore, includes AMD/non-AMD duality.
I felt the need to add to this fairly old question.
Both Backbone and Underscore now support AMD:
Underscore commit
Backbone Commit
Discussions (albeit Backbone's one is a bit puzzling as there is a clear discrepancy between the tone of the discussion and the actual outcome):
Underscore Issue
Backbone Issue
ES5-shim provides many of the same features as underscore and lodash (array.forEach(), array.map() etc).
ES5-shim natively supports AMD, unlike underscore and lodash, doesn't add extra copies of things your browser probably already provides. Rather it adds native ES5 features to older browsers.
When IE8 and other older browsers die out, you can simply remove the ES5-shim dependency without having to port code like you would with lodash or underscore.