Should I use the .es6 file extension for ECMAscript2015? [closed] - javascript

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.

Related

What are some advantages and disadvantages for embedding JavaScript in HTML or saving it externally? [closed]

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'm looking for simple bullet point answers please. I've tried looking all over, Googling, other questions here but I can never find both advantages and disadvantages for each method.
This is the answer I got from W3Schools pertaining to external javascript files
Pros
It allows separation of concerns - which is not a big deal in simple pages but as the script grows larger you can have a monolithic html page. Big files in general are not ideal for maintainability
It allows caching - when the browser loads a script externally (whether it's be from your site or a cdn) it caches the file for future use. That's why cdn's are preferred for commonly used scripts. Makes the browser use a cached script instead of building a new one every time the page loads which makes the page load faster
More readable code - this ties into the first bullet point but nevertheless it is important. The smaller the files we humans are working with the better. It is easier to catch mistakes and much easier to pass of the torch to the next developer working on the project or learning from it.
Cons
The browser has to make an http request to get the code
There may be other browser specific reasons as well, but I believe the main reason is the separation of code into different components.
Probably the best advantage of using external javascript files is browser caching - which gives you a good performance boost.
Imagine you have a site that uses MyJsFile.js (a random 50kb javascript file that adds functionality to your websire).
You can:
embed it in every page, and add the 50kb to every page request (not ideal)
link it in every page (<script src="MyJsFile.js"></script>)
The second option is usually prefered because most modern browsers will only get the file once, and serve it from the browser cache instead of downloading it at every request.
Check out similar questions:
Why not embed styles/scripts in HTML instead of linking?
When should I use Inline vs. External Javascript?
Is it better to put the JS code on the html file or in an external file?

Pre-compiled versions of often used scripts in browsers [closed]

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.

When making a javascript library, where is a good place to document the API? [closed]

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 4 years ago.
Improve this question
I am making a library to generate some custom content. It is pretty verbose, about 1100 lines of code. Although the code is very readable and follows strict naming conventions, I am unsure where to document the API available when including the script file. When including the script in a page, intellisense does not pick up the "public" methods, nor does it for jQuery. jQuery has an awesome website for their API ( http://api.jquery.com/ ), but I do not feel inclined to make something as awesome as that.
Where should I document this custom API?
If in comments, what structure of comments would you suggest?
Edit
My point for intellisense was that even good naming conventions are going to require documented API. So I am definitely interested in a generic approach.
I think jsdoc is pretty popular.
http://code.google.com/p/jsdoc-toolkit/
You would document inline, following the conventions on the link. You would distribute a minified/obfuscated production build for deployment, and the documented one for development (i.e. you could do that)
Edit, you could also find more options here: http://o2js.com/2011/05/01/how-to-document-a-javascript-framework/
It's not generic, but if you didn't mind maintaining separate versions for different editors, Visual Studio's IntelliSense will load and parse XML comments in your JavaScript code. I would suppose MonoDevelop and SharpDevelop could use the same file as well, but I don't think IDEs like IntelliJ or Eclipse would get any use out of it...
HTH.
it depends how complex your api is, for my own small libraries i just make a big comment at the top of the file that contains
a quick writeup of what this is all about
if the library operates on html markup some example code that can be copy&pasted
a list of the functions with their parameters and one-line documentation for each
examples of how the library is typically used
notes/warnings/limitations. there's always something weird going on people won't expect
basically this is what you'd put in a C header file.
i guess you could do all the things i mentioned above in a separate file and then use markdown syntax (i'm too lazy ... also i prefer having everything in a single file).
p.s. some people mention inline-comments (i.e. directly where the functions are).
this is of course an option too. but to me it seems this is convenient only if have the docs auto-generated, it is a horrible way to quickly study the documentation inside the file because it lacks a big picture view.

Drawbacks of KSS [closed]

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

Python library for rendering HTML and javascript [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Is there any python module for rendering a HTML page with javascript and get back a DOM object?
I want to parse a page which generates almost all of its content using javascript.
The big complication here is emulating the full browser environment outside of a browser. You can use stand alone javascript interpreters like Rhino and SpiderMonkey to run javascript code but they don't provide a complete browser like environment to full render a web page.
If I needed to solve a problem like this I would first look at how the javascript is rendering the page, it's quite possible it's fetching data via AJAX and using that to render the page. I could then use python libraries like simplejson and httplib2 to directly fetch the data and use that, negating the need to access the DOM object. However, that's only one possible situation, I don't know the exact problem you are solving.
Other options include the selenium one mentioned by Łukasz, some kind of webkit embedded craziness, some kind of IE win32 scripting craziness or, finally, a pyxpcom based solution (with added craziness). All these have the drawback of requiring pretty much a fully running web browser for python to play with, which might not be an option depending on your environment.
You can probably use python-webkit for it. Requires a running glib and GTK, but that's probably less problematic than wrapping the parts of webkit without glib.
I don't know if it does everything you need, but I guess you should give it a try.

Categories