I'm building a website which my target group is very general (ages 13-oo, so hello IE9, hello ancient android browser), so I need polyfills for some stuff (viewport, calc etc). Before I used Modernizr and some conditionals user agents to target IOS 6-7 etc. Then with yepnope.js I was loading the specific polyfills.
Now that modernizr 3.0 is out, I noticed that the Modernizr.load() is deprecated. Also the yepnope.js library is deprecated. As they say on their website
"There are new best practices that you should likely follow instead."
But I can't find any of them. After googling for some time everyone recommend Modernizr and Yepnope. But this issue is so fresh (the deprecation, the new version of Modernizr), and I can't find any new alternative method.
Maybe using of some module loader (like require.js) will do the job? And if yes, how?
I maintain the polyfill service at https://cdn.polyfill.io which may meet your needs. We have a library of around 800 polyfills, which are bundled selectively and served only to users that need them. You can run the service yourself or just load the polyfills from our CDN.
The most comprehensive write-up I've seen on this technique is Philip Walton's Loading Polyfills Only When Needed. It's too long to quote any parts here and should be read in its entirety so I'm not going to copy/paste sections into this answer.
I've spent my morning figuring this out myself. You can use jQuery's getScript method. I just answered a similar q here: https://stackoverflow.com/a/34518146/411436
from the yepnope repo
When it comes to loading things conditionally, we suggest that you
output a build for each combination of the things you're testing. This
might sound like it will generate a lot of files (it might), but
computers are pretty good at that. Then you can inline a script into
your page that only loads (asynchronously!) a single built script that
is tuned to the features of that user. All the performance win of
conditional loading, and none of the latency problems of loading 100
things at once.
Related
I chose Vue.js for a new project because it seems to run natively in the browser, as opposed to something like React that has to be compiled/transpiled via Node. Is there any reason I couldn't just link to a CDN like this in my production code?
<script src="https://unpkg.com/vue#2.2.1"></script>
A co-worker suggested that may be for development only, and that unpkg is simply transpiling on the fly (which doesn't sound good for performance). But other than that it seems to work fine. I could also link to a more robust CDN such as this one, but just want to make sure I'm not violating some sort of best practice by not using a Node build system (e.g. webpack).
Is there any reason I couldn't just link to a CDN like this in my production code?
No, there is no reason not to use a CDN in production. It's even a preferred way for serving content in production mode, especially with common packages like jQuery, because most of the people would already have loaded and therefore cached this resource.
A co-worker suggested that may be for development only, and that unpkg is simply transpiling on the fly (which doesn't sound good for performance).
This is absolutely not true - that's why it is a CDN! :) It's a matter of choice, but you have to keep in mind that most of the time you should work with specific version of the library that you are using during development. If you just add the latest version of any code, you are vulnerable to all changes pushed to that repository, and so your clients will start receiving updated code, which you haven't tested yet.
Therefore fix to a specific version that you develop with, open a beer and have a good sleep :)
Updated (18.10.2022): Global caching no longer works
Actually, this one's been around for a while, but the answer was never updated. The short story is that caching works per site. Longer version can be found here (thanks to #Baraka's comment).
Either way, using CDN for production deployment is still much preferred!
These maybe help:
<!-- development version -->
<script src="https://unpkg.com/vue"></script>
<!-- production version -->
<script src="https://unpkg.com/vue/dist/vue.min.js"></script>
And it will keep current version of Vue.js automatically.
This question already has answers here:
Why is jQuery not integrated within the browser
(7 answers)
Closed 4 years ago.
It seems like a good idea to me. or add the additional features to Javascript itself?
Because it's just one library of many. It may be popular but it's far from being the only choice. And it would also cause it to freeze at a particular version and make improvements much slower.
Plus there is little advantage anyway. It's fairly small and you can set it to be cachable indefinably by the brower so it will only be downloaded once anyway - if you have a new version it will have a new filename, so there is no harm in making it never expire.
I think this question should be a bigger discussion, but these answers are all bogus.
This is also 2 years later of course.
"it's just one library of many" - include the top 11 then.
"couldn't agree on common standard" - Kind of making jQuery a standard of it's own at this point.
"updated more often than browsers" or "make improvements slower" - So the browser won't have jQuery-1.9.x until next browser update, just don't put it in your project yet.
"Cache anyway" - Sure, it's still a transfer that doesn't have to happen, and there are a lot of people that haven't done a lot of surfing on their new device that you still want your site fast for and so on.
The thing is it is totally doable and would be better for the internet load; by how much is debatable. I could really see chrome at least replacing any net transfer to their CDN with a local copy, but I'm sure there is some legal, security or net neutrality issues with that. Just like I'm sure the main reason has something more to do with such matters and not these lame technical excuses that are obviously not thought through.
This could benefit other libraries too if developers could rely on the speed and availability of a complete library of tools like dojo, and not have to pick and choose just to cut weight. And also as most libraries have adopted the AMD or requireJS approach to package their projects, I believe there is a good argument for the enabling the browser to at least be informed of it's dependencies.
jQuery exists just because they (browser makers) couldn't agree on common standard.
You can consider jQuery to be a JavaScript plug-in. And browsers do not ship with plug-ins, otherwise the purpose of plug-ins would be irrelevant.
Plugins get updated more often than browsers - within a week the browser version of jQuery would be out of date :)
There's also the issue of versioning. Certain sites and extensions of jQuery require a certain version of jQuery. Right now it's up to the application to decide which version to use.
Probably because browsers are hard to update. Some freature of JQuery may eventually make their way into javascript, and I believe some of it has just recently. (well the idea's anyways) It takes years to add a feature to something like javascript, where the JQuery library can just release a new version.
There is actually a firebug or firefox plug in that allows you to inject JQuery into the page.. but thats just a development tool
Adding jQuery [type] functionality to the browser's in-built JS implementation (or making it a 1st-class plug-in) would overcome one basic problem:
As many have said, jQuery is a JS library - meaning, in case the penny didn't drop - that it is written in JS and has to be interpreted at run-time.
Embedding it would mean that it could be written in native code for the OS, making it much more performant.
In my application, I allow users to write plugins using JavaScript. I embed V8 for that purpose. The problem is that developers can't use things like HTTP, Sockets, Streams, Timers, Threading, Crypotography, Unit tests, et cetra.
I searched Stack Overflow and I found node.js. The problem with it is that you can actually create HTTP servers, and start processes and more things that I do not want to allow. In addition, node.js has its own environment (./node script.js) and you can't embed it. And it doesn't support Windows - I need it to be fully cross platform. If those problems can be solved, it will be awesome :) But I'm open to other frameworks too.
Any ideas?
Thank you!
There is CommonJS, which defines a "standard" and a few implementations available of that standard - one of which is node.js.
But from what I can see, it's still fairly immature and there aren't many "complete" implementations.
In the end, I built my own library.
I am currently half-decided to use Kohana + Zend as needed for the PHP part. What I would need next is an excellent base for JavaScript code. There are a bazillion of contenders here and choosing isn't exactly as easy as with PHP.
I would need practically everything from form posting and retrieving results to skinnable widgets and animations. For this reason using multiple libraries will probably be a must, as no one framework can do it all. The requirements I have would be this (initial list):
Good browser support. WebKit-based is hardly an issue and Firefox 3+ is good. However, I'm looking at you Internet Explorer. IE 6 can be ditched, seriously, but 7+ support is needed.
Good performance. While WebKit has had a stupidly fast JS implementation for quite a while (and Chrome even before), Firefox has only recently got TraceMonkey and don't even get me started on Internet Explorer. While it is true that you can't do much about IE as anything will be slow, I don't want to try running Chrome Experiments in the others either.
Excellent support. This is a total must. The better the support, the more inclined will I be towards a library.
I am currently looking into jQuery as it is a very neat library, but the quality of plugins is questioned by some. Processing.js looks extremely promising, but IE does not support canvas, thus something has to be done about that and I am not sure how it could be replaced.
Go with a known library that is used by many sites. This will ensure all 3 of the points you have mentioned.
Personally, I would go with jQuery for these above reasons:
Great cross browser support
Good performance, as it is a thin api layer
Excellent support. Good documentation, loads of other devs
Although jQuery seems to be the most used library these days, there are other very good candidates as well.
One of them are YUI Library.
YUI has excellent documentation, and support. And the source code is really good.
YUI is developed by Yahoo!, where Douglas Crocford is architect (the author of JavaScript: The Good Parts, and the man behind JSON). Yahoo! is well known for their focus on JavaScript development.
YUI has good browser support and is fast and robust.
If it's war simulation and you have custom objects that you want to animate beyond the simple CSS effects and animations, then canvas tag is your best bet. It's as close as you can get to Flash but much more smoother. Processing.js looks really good for manipulating the canvas.
If that's the core component of your game, then I see the other libraries as adjunct to Processing.js that can be scrapped out without any deep commitments. That said, jQuery is great if you're dealing heavily with the DOM. It has really good support and community. MooTools is highly modular and has been traditionally strong with animations. YUI is a great library too, but a little verbose for my taste. Thought, Yahoo has made heavy changes with v3 to fix that. And a bunch of other libraries, that I don't use at all.
Dojo is a great library for writing web applications; however, never having written a game, I'm not sure if it is well suited for that sort of application. I must warn you though that the Dojo documentation is crap. Absolute crap. On the other hand, things like dojo.hitch, dojo.require, and dojo.partial are absolute joys.
I would try to avoid using cross-cutting libraries (like Dojo+jQuery) as much as possible. There's not really a good reason to do it and will create bloat and confusion in your application from day one.
That said, using multiple, non-overlapping libraries does make sense for a project like this. You might want to look into using Processing.js for visual needs and either Dojo or jQuery for your core.
Some other things to consider. Targeting IE, even IE8, for JavaScript game development is a bit ridiculous because of its slow performance and lack of canvas support. Also, according to John Resig, developing games in JavaScript is hard.
Have you considered being a pioneer (wink) and trying something out in 03D?
Given the iPhone's 25k limit for caching of files, I'm wondering if there's interest in an iPhone optimized javascript library that makes caching a top level goal. Since it'd be iPhone only it could get rid of most cross-browser cruft and rely on safari specific capabilities, hopefully cutting down some of the girth and staying with 25k.
John Resig discusses this briefly, although mostly to dismiss it, it seems. He does mention:
if you're particularly excited about
breaking jQuery down into little
chunks you can grab the individual
pieces from SVN and build a custom
copy.
Anyone tried that?
Dojo implements a 6k version that seems to rely on deferred loading. I'm mostly a jQuery user so I haven't given it a try, but it looks interesting.
Overall: what do you think about a safari/iphone specific javascript library that implements, say, the top 90% most used APIs in jQuery (or your other favorite library)?
Newer update: looks like Zepto is the way to go these days.
Found XUI, looks like what I was looking for, although I haven't given it a try yet.
You should check out QuickConnectiPhone. It may do what you want. It can be found at https://sourceforge.net/projects/quickconnect/. It also lets you write your app in JavaScript, CSS, and HTML and yet install it on a device.
There is an API that will allow you to make calls down to the Objective-C layer as well for phone vibration, GPS locations, accelerometer information, and some more. You can even extend this to other native phone behaviors as well.
The development blog for the framework is found at http://tetontech.wordpress.com
I'm experimenting with XUI as well, looks promising, seems to follow JQuery-way of doing things.
The same people also created 'lawnchair' for persistant storage of data in json format, XUI+lawnchair looks like a great combination for cross-platform (as in at least iphone+android, maybe webos, symbian, blackberry and ms as well) mobile development.
I think it would be fantastic, but it would be hard to match the testing and reliability of jquery unless someone really picks it up and runs with it. If there was a lightweight, safari only version of jquery that was completely compatible with the plugins and documented methods, it would be a godsend.
Given the increasing popularity of the iphone, I think it would be a really useful thing, it might be possible to remove the cross browser stuff and get it down to size.... however, it would be even more useful if the iphone had a more realistic cache limit.
It does make me wonder if the cache limit in the iphone was determined by the capacity of the hardware or the business needs of the carriers. A 50K cache limit would reduce a lot more carrier usage...