Closed bcherny closed 8 years ago
No thanks - it's 2016, nobody should be doing anything without a module loader / build process.
:/ and here i was thinking the point of a shim is to support old systems without requiring additional code changes...
The point of shims is to support writing new code that works on old browsers - in no way does that mean you wouldn't have to (or want to) use a build process.
it seems to me that people supporting old browsers are the most likely to also be supporting legacy systems, which may be expensive to rewrite to use a module loader.
if you ask me, it's better to let engineers stuck with legacy systems enjoy es7, than tell them "you have to go to jquery/mootools/lodash/other library for that cool feature you want". better to have more people using standard es7 syntax.
You are welcome to run es7-shim
through browserify and include the output in a vendor
directory, for example - there's no reason anyone can't do that at install time.
they can, of course (they can also write their own versions of the shim!). but traditionally, the burden is on the library author to do that.
to me, it's strange to support specifically commonjs (which is only standard for nodejs), but not
all of which are defacto standards, until es6 modules are broadly adopted.
anyway, your library, your call!
ES6 modules don't yet exist because there's no loader spec. Once it does, you'll need a build system to be able to use it on older browsers anyways.
AMD is dead, node-style commonJS won ¯(ツ)/¯
Globals are a hugely bad practice; the community has been moving away from them for years; and a module system is the preferred approach.
This module has a browserify entry point - traditionally consumers of npm modules browserify their own entry points and it grabs up all their dependencies, which is how this one works too.
If you are wanting a script link to place in an html file to load relevant polyfills, I think polyfill.io sounds like the project you are wanting to use. If a polyfill is missing from there that you require, you can file an issue for it to be added :-)
Also so as not to promote just one of these services, there's also https://wzrd.in/standalone/es7-shim@latest - so "i don't have node installed" isn't an excuse.
@ljharb First of all, thank you for your work on this shim library. Secondly, you should package and distribute this library in a way that makes you happy because I'm not going to tell somebody who's pouring their free time into making the community better how to do that.
Thirdly, I'm one of the cave-people that writes JavaScript in 2016 without a module loader. I work on many small Rails projects and I use the Asset Pipeline by default because I'm not always writing enough JavaScript to warrant the overhead of adding Browserify or Webpack. Furthermore, I'm our JavaScript practice lead so I'm ultimately responsible for the build process in all of our Rail apps and we've got a bunch of them here at Table XI, and adding module loading to all of them just isn't economically possible. So even though I'm using a build system, that doesn't mean that I'm using a module loader. Maybe I'm the only JavaScript specialist on the planet who's in this situation.
No thanks - it's 2016, nobody should be doing anything without a module loader / build process.
Finally, the web is a massive place and there are huge amounts of JavaScript written every day. I'm guessing that many if not most individuals writing JavaScript aren't even using crude build systems like I am but are just including script tags.
All this is to say, it might be worth considering putting a link to a service like https://wzrd.in in the readme given how very large the frontend JavaScript tent is.
I was scratching my head for some time, wondering how to include es7-shim in my jsfiddles (or other fiddle equivalents). I'm glad I found this issue and the link https://wzrd.in/standalone/es7-shim@latest
Shame I'm getting error 502 the very day after I find it. :( Any CDN known to be hosting this?
for usage without a module loader