I am developing a Thunderbird extension, which is mostly done in JavaScript. I want to use several functions from Mozilla's NSS (Network Security Services) library in JavaScript. There is one JavaScript wrapper built into Thunderbird, named WeaveCrypto.js, which I currently use. The problem with WeaveCrypto is its age (AES-256-CBC might have been good enough in 2010, but is not recommended today anymore, e.g. through the this. SHA1 is also not really recommended as the prf-Algorithm in PBKDF2 anymore.) and hardcoded values like iterations, algorithms and key lengths.
The JavaScript Crypto already made it to the "Archive of obsolete content", while DOMCrypt is only available in Firefox.
I am currently chatting with Justin Dolske, the developer of WeaveCrypto. His current take is that I could fork WeaveCrypto and if I only add algorithm IDs and change only small pieces of logic (like the hardcoded values to changeable ones) they would likely add my forked version to Thunderbird.
I will do that if I have to, but it sounds a bit strange to me, that the huge NSS library is not completely accessible and useable in JavaScript without extra effort, even though all logic of Firefox and Thunderbird extensions is written in this exact language (or did I miss something?).
Any ideas appreciated :)
Justin Dolske told me about the WebCryptoAPI which uses the NSS library from JavaScript. It is completely available in Firefox since version 34 (so probably also in Thunderbird since then). Most parts are, however, not supported by the famous Internet Explorer, making it more difficult to use it in browser applications. It seems still perfectly suitable for Firefox and Thunderbird extensions.
Its documentation is incomplete, but not bad. Here is some JavaScript Example Code.
Documentation on common crypto functions is also available.
The Personal Security Manager (PSM) also uses the NSS library, but does not seem to be intended for the usage in JavaScript Extensions.
BUT: The supported algorithms in NSS are not state of the art. There are JavaScript Libraries like the SJCL JavaScript Crypto Lib that contain stronger algorithms. Unfortunately, it is not really recommended to use crypto functions written in JavaScript (Javascript Cryptography Considered Harmful).
Conclusion: That is the reason why the NSS library seems like the way to go, since it is written in C and should therefore be faster and more secure than JavaScript implementations. But it should be updated to the latest security standards. In the NSS 3.3 Plan they already mention "Update the list of encryption technologies" under "Must Have" and "Elliptic Curve Cryptography (ECC)" under "Nice to Have". I cannot see much information about that in the NSS BurnDownList, but I hope there is more to come.
Related
A rookie here.
Messing with my google scripts projects I have found a strange thing, a method that I was using was strike-through in the editor and it looked like this --> substr . Researching, I found that it is because this method is being deprecated. And for people looking how to solve it look the documentation in developer.mozilla.org.
At first, I had no problem with this, but, if it was not there before, and it is now, that means that the version of javascript that my project is using is changing and I do not want that. And there is my question
Is there a way to make the version of V8 JavaScript that my google script uses constant?
Looking in to the app-scripts documentation I have found that it uses V8 and that it is defined in the manifest but the way of freezing to a certain version is nowhere to be found. Maybe there is an easy answer, but I have no clue where else to look. Any help will be welcomed.
No, there is no way to select a particular V8 version for your GAS.
That said, JavaScript engines are generally very conscious of backwards compatibility. It is extremely rare that features are removed -- there are a good number of "legacy"/"deprecated" things in JS that won't be removed for the foreseeable future, because there's too much old and unmaintained (but still used) code out there that depends on them, and browser makers don't want to break that code.
Regarding the specific case at hand, I personally would be quite surprised if String.prototype.substr ever got removed. I see its deprecation as more of a "pro tip: how not to confuse substr and substring: only ever use one of them".
FWIW, V8 itself has no notion of deprecated JavaScript features. The strike-through you see is just an editor feature. Updating or not updating the V8 version underneath wouldn't affect it.
Taking a step back: writing software once and then expecting it to work without maintenance or monitoring for decades is, unfortunately, generally not a thing. For instance, if you developed a game for Windows 95, you'd have to expect that it won't run well (or not at all) on modern Windows versions. There are countless more examples of operating systems, SDKs/toolkits, compilers/engines, and programming languages themselves evolving over time in ways that guarantee backwards-compatibility for a couple of years but not forever. This is the flip side of technological progress. Pinning yourself to certain outdated versions is generally not a viable solution, for a variety of reasons.
So actually, in comparison, when you write an app or script in JavaScript, you have a very high chance of it still working fine 20 years later. So I wouldn't worry about it too much.
I'm looking for the way to get low level code of javascript built-in function.
For example, there is an polyfill(I want like this form and I call this low level code in my way) in mdn site of 'Array.prototype.indexOf()'
(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/indexOf)
And I get to understand that it is kinda low level code of built-in method.
Here is my question, where can I see the code to look inside of method of 'String.prototype.toLowerCase()'?
It'll depend on your javascript implementation.
For V8, here is the guts of toLowerCase (and toUpperCase)
Low level functions (such as these) are generally written in whatever language the javascript engine is written in - that's why they're so fast. So don't go in expecting something that's easy to read for the average javascript-only developer :)
The answer you are looking for probably doesn't exist but I'll do my best do help you out.
The low level function are dependent on which Engine you are using.
A few examples are:
V8 — open source, developed by Google, written in C++
Rhino — managed by the Mozilla Foundation, open source, developed entirely in Java
SpiderMonkey — the first JavaScript engine, which back in the days powered Netscape Navigator, and today powers Firefox
JavaScriptCore — open source, marketed as Nitro and developed by Apple for Safari
I assume you are looking for the function to understand what they are doing. If this is the case and you don't understand the languages that the engines are written it might be an idea to look at the polyfill implementation of those functions. Those are written in javascript and might help you understand them if that's what you are looking for.
Good luck! :)
JavaScript is defined by a standard, with many major implementations.
The definition for that method and others can be found in the TC39 website. It is only defined algorithmically, not in actual code.
That being said, for the open-source implementations, you can actually look at the source code for those implementations, though they will probably be in some other language, such as C++.
The major current open-source implementations of JavaScript are Google's V8, Apple's WebKit and Mozilla's SpiderMonkey.
So I am asking does each web browser have there own compiler example IE compiles Javascript from a website and generates sequence A of byte code .
On the other hand, google chrome compiles the same Javascript from the same website and generates sequence B .
I am wondering this because if that is the case would it be beneficial to run the compiler on the Javascript and upload the generated byte code to the website rather than the Javascript itself. And send different byte code based on each browser.
Or are there some other limitations.
As others have pointed out, there are different ECMAScript engines and some of them use a JIT (Just-In-Time) compiler while some others use runtime interpreters, being the former the preferred option for most browsers nowadays as it gives some performance benefits over the latter option.
You can see another question about this on: https://softwareengineering.stackexchange.com/questions/138521/is-javascript-interpreted-by-design
For example, V8 is the JavaScript engine used in Google Chrome, node.js and can also be embedded into C++ applications.
About your idea of sending compiled or precompiled code to the client instead of the raw JS, there are some projects working on something similar:
Asm.js consists of a strict subset of JavaScript, into which code written in statically-typed languages with manual memory management (such as C) is translated by a source-to-source compiler such as Emscripten (based on LLVM). Performance is improved by limiting language features to those amenable to ahead-of-time optimization and other performance improvements.
The important fact about Asm.js is that existing JavaScript engines do work quite well with its style of code, so you can start using it right now! But the code it produces is still (a subset of) the JS we know but written in some way that helps JS engines to run it faster:
Of course, there are also a lot of restrictions about what you can do with it, as it is mainly oriented to work with just numbers. See http://ejohn.org/blog/asmjs-javascript-compile-target/
Real support for Asm.js is still a limitation, so you can't use things like "use asm" and although you can run Asm.js code on today browsers and get some performance improvements, it won't be as good as it could be in browsers that could optimize Asm.js code. However, we may start having that and some other improvements in the (hope that near) future. See https://blog.mozilla.org/research/2015/02/23/the-emterpreter-run-code-before-it-can-be-parsed/
Meanwhile, and for a more general purpose JS that needs to work with more than just numbers, you can use Google Closure Compiler. I would recommend that you take a look at the FAQ first, and then you could start playing with it in the online tool.
There are several JavaScript (or rather ECMAScript) implementations in wide use, and while in theory there are standards, most widely used one being ES5 (ECMAScript 5) - yes, not everything in all browsers is properly, consistently implemented (I'm looking at you, old IE).
Here's nice compatibility table for ES5 (the one you're writing in today): http://kangax.github.io/compat-table/es5/
And here's same thing for shiny-new ES6: http://kangax.github.io/compat-table/es6/
Note the disclaimer at the top of these tables:
Please note that some of these tests represent existence, not functionality or full conformance.
Also, on the issue of whether JavaScript is compiled or interpreted language: it is definitely interpreted language - at least originally. But most common JavaScript engines in use today implement JIT (Just-In-Time compiler), translating much of JavaScript to byte or machine code before executing it (ergo - compiling).
Most widely used (and most performant as well) of these engines is V8, used by WebKit (and therefore present in Chrome, Safari, Opera, ... - Node.JS is using it as well). Read more about V8 and its JIT implementation: How the V8 engine works?
Yes, each browser has its own implementation of an ECMAScript engine, most commonly implementing/supporting ECMA-262, commonly known as JavaScript. While there are several large related families of browser engines such as Webkit, each engine further can have its own JavaScript engine. For example, as many have pointed out, Google use the V8 engine. Because these engines each do things a little differently, there is no one set of code that is promised to be deterministic across them, the way say Java code will run the same on any machine that supports the JVM.
Inherently, JavaScript is not compiled like a traditional language such a Java or C/C++. This is why, without the help of a 3rd party program, you cannot find non-syntax errors in your JavaScript code until that code runs. ECMAScript is an interpreted language.
Now, this is the tricky part. Most modern JavaScript engines do in fact compile JavaScript, often to another language (also known as Source-to-Source compiling or transpiling) such as C, to perform performance optimizations on it. Of course, at some point, all code gets compiled into byte code.
Your best bet for writing JavaScript that will work on all major browsers is to use core/standard features. For example, this means passing timestamp string in the form of "yyyy/mm/dd" instead of "yyy-mm-dd" when using new Date() since Firefox does not support the latter format - the Chrome developers simply added it to be nice to you. IE is notorious for handling certain non-standard features differently. I'm a big fan of http://caniuse.com/ to help with this.
Nowadays most javascript engines are JIT compilers. More here: What does a just-in-time (JIT) compiler do?
So yes, javascript is compiled (not interpreted), and most major browsers do it differently.
Firefox has a SpiderMonkey javascript engine. Chrome has V8 javascript engine.
Obviously those engines are a separate products and browsers utilize some kind of interface API to interact with them.
On the other hand programmers longed for a long time for their favorite language in browser. So much so, that we have products like GWT (for java), parenscript (for common lisp), HJScript (for haskell), and i'm sure many other libraries for many other languages that allow programmers stay with their favorite language and generate client side code as well.
The idea is so obvious that i am surprised that there's no implementation of it yet. Why not publish the interface API of browser to language engine and allow web sites to provide custom language engines as downloadable bundles. With current internet speeds 3-4 megabytes one time download is not a problem for majority of applications, even more so for intranet usage.
So where's our pluggable engines ?
You don't need pluggable engines really, just an agreed upon byte-code format. Google is going down that path now with NaCl and PNaCl which is based on LLVM. So any program that compiled down to a safe subset of LLVM byte-code could be run in the browser.
Browser vendors can't even agree on a common video format (see the html5 <video> debate) or on how the document DOM object should look like, and you want them to agree on a whole language interface?
Good luck.
I guess you forgot about applets and embed's. Both offer exactly what you want. And both suck for the very same reason.
We've been down this route in the past.
Older versions of IE supported VBScript as a scripting language in addition to JScript.
The result was a whole load of sites that only worked in IE.
This isn't what the web needs again. As a developer, I may desperately want to write code using my favourite language, but as a user I want to be able to browse all sites on the web without having to worry about which plug-ins I need for any given site, or whether my preferred browser can even use those plug-ins.
This is the problem that Microsoft's Silverlight has had. It might be a marvellous technology, but to the end user, why do I want another plug-in? Silverlight has managed to gain some market share thanks to the sheer power of Microsoft, but really not that much.
Now, if the code reaching the end user is consistent, regardless of the language it's written in, then the language doesn't matter. But this effectively means compiled code (or at least bytecode), which is a whole different kettle of fish to running a scripting language in the browser.
Though 99% of the code on our site is the work of 1 programmer, recently for the first time (and probably last) a programmer was hired to work on our site, he was given remote access to log in via ftp.
Background: He is located in a continent unknown to us, speaks a mothertongue that I cannot guesse from the English mails, and works in ways that are bit different than ours. It seems, this common workflow in long distant small projects where the original programmer is essential to update/customise their code.
Problem: The genius writes like a hacker, good quality but very poorly documented, some bugs occuring here or there. Now we are stuck with almost brilliant code with some bugs. Its Javascript mainly.
Question: First of all 1. What ways/utilities/websites are there to find bugs in freshly delivered JavaScript code, when its difficult to understand parts of thes code to begin with? 2. What are good code comparison programs/utilities/websites sothat one can vew in parallel side by side comparison differences between two versions of code?
Obviously both are very related so hopefully there is one great tool on this planet that aims to combine bug finding as well as shows you the differences between versions.
Any suggestions are good answers to me as I have no clue where to start from here.
I agree with the posts above, Firebug for Firefox and Google Chrome/Chromium's Web Developer tools are great for most JavaScript debugging purposes. IE8 has an o-k set of Developer Tools. I'd only recommend using them if you're having issues in IE-only, otherwise, the previously mentioned tools will perform much, much better. If you really want to run the JavaScript through the error-checking and code-quality gauntlet, take a look at Douglas Crockford's JSLint.
It's also worth mentioning community-driven JSHint as a resource for testing JavaScript code. It's not as strict as JSLint and has better support for commonly-used JavaScript libraries.
The Windows applications listed above should work great for comparing files. If you're on OS X though, Kaleidoscope is a wonderful comparison app. It costs a little money, but it integrates very nicely with most versioning systems.
I agrre with #BiAiB, about the need for a code management/versioning tool - this will save you hours of heartache.
Another excellent file comparison tool is Beyond Compare - it truly is worth every penny that it costs (which is not much)
Probably the best tool to help in the discovery of what is happening in your JavaScript code is Firebug, a plug-in to Firefox. Google Chrome and IE have similar functionality, although each solution may lack feature (or have extra features) that the others don't.
And, I agree with everybody else - you need source control in a big way.
For file comparison tools, there is also the excellent and free WinMerge
Eclipse can do compare.
JsTestDriver is a wonderful testing tool.
But you will need to write unit tests for it.
A great tool is using firebug and the Webdeveloper toolbar plugins for mozilla firefox.