JavaScript Standard Library Revision
After the success of my old JSL project I learned more about JavaScript and I found some trick to solve different problems such setInterval and extra arguments for Internt Explorer, a function to evaluate code in a global scope with every browser as Internet Explorer does with its proprietary execScript.
Since these days We're waiting for ECMAScript 4th Edition, aka JavaScript 2 but since We always don't know when it should be really usable within productions, I choosed to create a revisited version of JavaScript Standard Library.
I removed Internet Explorer 4 support but I modified a lot of common prototyes to make them faster, more standard and more scalable than ever.
You can use, for example, every JS 1.6+ Array.prototype with HTMLCollections too as it's possible from many Years with FireFox or Safari:
Array.prototype.forEach.call(document.getElementsByTagName("div"), function(node){
alert(node.innerHTML);
});
I fixed different standard behaviours and I implemented setTimeout and setInterval.
I add execScript, not standard, but really useful when You need to evaluate JavaScript in a global scope with FireFox, Safari, Opera and every other as Internet Explorer does from many years with its own execScript global function.
JSL creates a quite totally standard JavaScript 1.6+ enviroment adding prototypes only to browsers that don't support them or that have different behaviours and everything in a hilarious size of
With JSL You can forget your own not always standard prototypes implementations so every library size could decrease its code quickly, basing them on standard JavaScript 1.6+ enviroment and increasing performances for every standard browser like FireFox or Safari (about 40% of users ... growing up every day!).
This is the last chance to have a more standard Internet Explorer implementation because if We need to wait their fixes We should go better to sleep.
Have fun with JSL Revision and a quite real ECMAScript 3rd Edition enviroment.
9 comments:
I've just updated JSL, removing toExponential (not so used and not perfect in my implementation) and both reduce and reduceRight.
These last two methods are not yet standards and my implementation was not perfect.
JSL now has a demo page too to test Your browser with JSL prototype list.
Great work :) Just a couple of notes: in your JSL page you don't say how to use the library (I, for myself, know how, but...). Finally, you should state how JSL behave within the use of other libraries (the most common one, of course). I think JSL is neutral, but I'd like to know if you have tested it :)
Thank you :)
@enebish ... how to use is quite simple, however it's wrote inside old version but You're probably right, I should specify them.
About other libraries, if You add JSL on top of your page You'll don't have any problems while if You wirte JSL tag after other libraries You should have some problkem with every other script that don't respect JavaScript prototypes standards.
At the same time other libraries dont need their prototipes (redundant) since JSL has its own standard prototipes but compatibility is always the best You can find.
JSL is not a library, it's just a "normalizer low level code", fell free to use them ;-)
Hi Andrea,
I notice that this revision of JSL is missing some components, like (non-exhausive):
- undefined
- encodeURI
- decodeURI
Any reasons for removing them?
Hi chenghong,
the undefined value is truly defined (whatever it means) only for old browsers (look at the first try catch in open source version) while I think that encodeURI and decodeURI aren't absolutely useful because you have better encodeURIComponent and decodeURIComponent that are standards (and probably only JSL implements these function correctly for every unicode char).
If you need for backward compatibility decodeURI or encodeURI just write something like ...
encodeURI = encodeURIComponent;
and that's all, isn't it? :-)
encodeURI/decodeURI may not be all that useful but since you are promoting JSL as the 'low level normalizer', and the fact that IE5.0 does not come with these functions, I think you should still include them. Same goes with a few of the obscure Number prototype methods.
Besides, encodeURI is not the same as encodeURIComponent. =)
Please read title ... A quite standard enviroment.
encodeURI and decodeURI are not standard, ok? ... You don't need them in a standard enviroment and I perfectly know that these aren't the same of URIComponent (look at old JSL, it has these too).
For number proto you are right, but toFixed a part few people uses others.
Andrea,
I'm not sure what you mean by they are not standard. encodeURI/decodeURI are in the ECMA-262 Edition 3 specification, implemented since Javascript 1.5. That's about as standard as it gets.
Anyway my point is not to argue with you. I'm just curious why they are dropped. So I should be able to port over these functions from the old JSL?
What I mean is this:
Note that encodeURI by itself cannot form proper HTTP GET and POST requests, such as for XMLHTTPRequests, because "&", "+", and "=" are not encoded, which are treated as special characters in GET and POST requests. encodeURIComponent, however, does encode these characters. These behaviors are most likely not consistent across browsers.
encodeURI and decodeURI are not consistent and don't encode/decode correctly all range \u000-\uFFFF.
If you need to encode a string use encodeURIComponent, if you absolutely need encodeURI create a wrapper for encodeURIComponent and replace encoded chars ("&", "+", and "=") with unencoded one.
This library is Mit Style, if there's something you need, add them :-)
Post a Comment