I am playing aorund with using LESS along with respond.js to streamline the development of a new site. Both LESS and respond are quite simply neat. However, with LESS in IE I have run into many problems.
For starters in IE8 mode my IE10 reported that id did not understand "map". No problems, I wrote up an Array.prototype map extension. Then it said that it did not understand isArray, once again in IE8 mode. Prototype extensions to the rescue again. Now it comes back saying something along the lines of SyntaxError: Invalid operand to 'in': Object expected
I am not in fact aware of what in might be but in any case I cannot keep adding adhoc prototype extenions on the fly in the hope that things will eventually settle down. Either LESS is unusable with IE or else someone here can point me to all the fixes needed to make it work.
Answer for your question:
First of all, LESS client side compilation is supported only in IE9+.
You could probably fix this using shims and polyfills for ES5, like these.
But please, don't.
What you should probably do (and forget the first part):
However, despite of really good caching mechanisms provided by the LESS compiler (eg. using localStorage to preserve generated code) using it i production isn't considered a good practice.
GruntJS and Bower.io work in the console, but are relatively easy to configure. Basically, you set them up once and forget they've ever existed:)
Livereload provides you with a GUI and it's incredibly easy to use.
I used GruntJS for frontend development with backend developers working with PHP (CakePHP, Zend, Laravel) and it made our lives much, much easier :)
It seems much more reasonable to streamline your frontend development workflow using a task runner like GruntJS or Brunch.io or install Livereload. These tools will monitor the file changes and generate a new CSS file on every save (and also, reload your CSS on the fly).
You can install GrunJS with watch and LESS plugins and keep is very simple this way. You could even use LESS Node.js package installed globally to the job.
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 often run into the problem of an javascript es6 import statement (transpilled via babel) failing to actually find the file the developer intended. This is particularly concerning during refactoring or during auto-fixing/formatting.
Is there a way to automatically flag imports, that are bringing in undefined? edit: at runtime?
It is standard practice to have a developer console of some kind or another (such as Chrome Developer Tools - hit F12, if working on web pages) open during refactoring or development of the Javascript.
So any imports that are not found would generate errors in that console, and thus be visible to the developer.
Missing imports however are not of concern (or should not be) to the User, and far as I know there is no mechanism to flag this to a User (non-developer) of the page. Dood design dictates it is not something they should be concerned with.
So you're probably thinking okay, during development time the we detect during our refactoring via the console that some imports have gone missing, we fix them and publish the latest code/page. Later the imports go missing.
Well that's the thing. If the imports live on external sources and can just randomly go missing, you need to fix That problem. If the imports need to live locally (same location as the javascript being served up) so they are available with 100% accuracy, then do that.
I have a quite big JavaScript for HTML page for a device.
But it's a bit slow. I tried compressing JavaScript files but it's still not satisfactory.
So I was thinking, is it possible to make it as a Just in Time that is compiled converted to machine code and use it? (Hope my understanding is correct) I use a WebKit based browser.
Anybody please who have done this, please provide links to "How To" pages or info about the same.
Both Safari and Chrome do JIT compilation of Javascript already. In fact, the only browser in widespread use that doesn't is IE8 and earlier. This is one of the main reasons why IE8 is so much slower than the competition these days.
But reading between the lines of your question, my guess is that you're not quite understanding what JIT compilation is. JIT compilation happens on the browser; you don't need to change your code in any way at all in order for the browser to be able to do JIT compilation on it for you.
What it sounds like you're actually thinking of is bytecode compilation, such as Java does. This bytecode is effectively a half-way compiled language which is then itself JIT compiled when you run the program. If this is what you're thinking of, I can confirm that this is not an option for browser-based Javascript code.
Google have been toying with a technology called 'Native Client' (NaCl), which would allow you to provide compiled code to the browser, but this is not available yet except in development versions of Chrome.
In any case, compiling may make your code run quicker, but it wouldn't solve the fundamental issue of why it's running slowly, which is likely to be a far better thing to resolve. (even compiled code will perform badly if it has bottlenecks; compilation in itself doesn't magically make slow code better)
If you want to find out why your script is running slowly, I recommend using a profiling tool, such as the one built into Firebug or Chrome's Developer Tools. This will help you identify the parts of your code which are running slowly.
You could also try the YSlow tool, which can also give useful information on javascript performance.
You also state that you've compressed your script to try to get it to go faster. Compressing the script will help it to download quicker (because it's a smaller file), but it won't do anything for the speed that the code runs at.
While working on a larger web application with an increasing amount of JavaScript code, we did a brainstorming session on how to improve code quality.
One of the first ideas was to introduce unit tests. This will be a long term goal; that will not, however, fix the most common causes of regression: the changing DOM and browser specific issues.
Unit tests run in a mocked, DOM-less environment and are not on the page.
What I'm looking for is an assertion framework that can be plugged into the code like this:
var $div = $("div.fooBarClass");
assertNotEmpty($div);
$div.fooBarAction();
I've found assertion frameworks that can do this, but they all either log into the console or into the DOM or open a silly pop-up. None of these work together with (thousands of) automated tests.
What I'm looking for is a run-time assertion framework that logs failed assertion via AJAX! Ideally, it should be:
Have common assertions built-in.
Integrate with JQuery modules, closures.
Log (via Ajax) the assertion, the file name, the page, line number, the cause of failure, some pre-configured variables of the environment (browser, release version etc.).
Support callbacks in case of failures. (If any assertion framework can just do this, I would be gladly willing to write callbacks doing the Ajax part.)
Work well with all browsers.
Trivial to exclude from production release.
Maintained code base.
We've been using the YUI Test Library. It seems to work fairly well.
Has a variety of assertion methods for different types
Assertions exist for equality, sameness, true, false, object type, and even array item comparison.
Allows for mock objects to test DOM objects and other functions
Our code does a lot of AJAX calls, or requires methods / objects that don't need to be tested (as they are tested elsewhere). Using Mock objects, we can tell the tests what to expect. For example:
var mockXhr = Y.Mock();
//I expect the open() method to be called with the given arguments
Y.Mock.expect(mockXhr, {
method: "open",
args: ["get", "/log.php?msg=hi", true]
});
Works with all browsers
We run our tests in IE, Chrome, and Firefox, and aside from some differences in what the test runner itself looks like, it works!
Trivial to exclude from production release
We have all of our testing code in a separate folder which accesses all the production code. Excluding the tests from production is as easy as excluding a folder.
Maintained codebase
YUI 3 is used on the Yahoo homepage, and seems to be fairly well maintained.
I know that it is not what you asked for but I highly recommend Selenium for automated testing of web applications.
Common assertions are built in.
It can test any JS framework because it drives the browser where your code runs.
It has robust logging features.
Browser support depends on your OS but all major browsers are supported.
There is nothing to exclude from a production release because the tests are external to the application.
The code base is well maintained and you have full control over your test cases.
It seems there is no similar solution I'm looking for.
I'm going write my own one, overriding console.assert to make an ajax call when arguments evaluate to false.
UPDATE: Here it comes, still under development, https://github.com/gaboom/qassert
Is it possible to run JavaScript code in parallel in the browser? I'm willing to sacrifice some browser support (IE, Opera, anything else) to gain some edge here.
If you don't have to manipulate the dom, you could use webworkers ... there's a few other restrictions but check it out # http://ejohn.org/blog/web-workers/
Parallel.js of parallel.js.org (see also github source) is a single file JS library that has a nice API for multithreaded processing in JavaScript. It runs both in web browsers and in Node.js.
Perhaps it would be better to recode your JavaScript in something that generally runs faster, rather than trying to speed up the Javascript by going parallel. (I expect you'll find the cost of forking parallel JavaScript activities is pretty high, too, and that may well wipe out any possible parallel gain; this is common problem with parallel programming).
Javascript is interpreted in most browsers IIRC, and it is dynamic on top of it which means it, well, runs slowly.
I'm under the impression you can write Java code and run it under browser plugins. Java is type safe and JIT compiles to machine code. I'd expect that any big computation done in Javascript would run a lot faster in Java. I'm not specifically suggesting Java; any compiled language for which you can get a plug in would do.
As an alternative, Google provides Closure, a JavaScript compiler. It is claimed to be a compiler, but looks like an optimizer to me and I don't know much it "optimizes". But, perhaps you can use that. I'd expect the Closure compiler to be built into Chrome (but I don't know for a fact) and maybe just running Chrome would get your JavaScript compiler "for free".
EDIT: After reading about what about Closure does, as compiler guy I'm not much impressed. It looks like much of the emphasis is on reducing code size which minimizes download time but not necessarily performance. The one good thing they do in function inlining. I doubt that will help as much as switching to a truly compiled langauge.
EDIT2: Apparantly the "Closure" compiler is different than the engine than runs JavaScript in Chrome. I'm told, but don't know this for a fact, that the Chrome engine has a real compiler.
Intel is coming up with an open-source project codenamed River Trail check out http://www.theregister.co.uk/2011/09/17/intel_parallel_javascript/