Yes, I know that less was in first place written for node.js.
But I really want to use it without adding node.js to my server, or learning how it works.
Is there some implementations of less written in other languages? Or maybe something similar to less?
You could take a look at SCSS. The compilation of files into CSS is done by a Ruby script which is very easy to get set up (even on Windows), and the syntax and feature list is almost identical. I'd even say that the documentation of SCSS is better than LESS.
That said, I have managed to get LESS compilation running locally by running the file in a Javascript engine (in my case, Komodo Edit's macro system is powered by Javascript, but it could work with Rhino or V8). You do have to modify the source a little, to simulate the window object. I got a lot of help by looking at the code of the Less Engine project, which basically allows Less to be executed within a JVM.
There is a Windows LESS compiler for .NET and a standalone version of it as well. I find this latter considerably better (i.e. fewer bugs) than less.js, although both are pretty odd in the way they handle comments: less.js doesn't understand two comments in a row, and lessc.exe doesn't understand comments inside selectors. I really don't see the point of compiling the .less file at the client once per page download per client when you could have done it once for the universe at build time.
There is also a Python implementation of SCSS: http://packages.python.org/scss/. It works quite well and includes a watch folder function.
There is very nice PHP class: http://leafo.net/lessphp/
Related
My front end is an Angular 1.x project with tons of files. I basically need to validate it and find any errors that are there in any of the files. Specifically, errors that can break the page. In compiled/static type languages like Java, this is very easy, as the compiler will tell you exactly what's wrong. However, since JS is interpreted/dynamically typed, I can't figure out a way to "build" these files and find errors like I would for compiled languages. Going to every single page in the browser after I make any change is neither practical nor scalable.
I am also not using TypeScript or ES6 and it's not possible at the moment to migrate to any of them. Tools like ESLint and JSHint have also not been very successful, since they only bring out minor errors within that file. However, a lot of major code is spread over several files. Although my code is already all ES5, I thought about concatenating all JS files together in one file and running babel on it. But have it been sure how to manage dependencies during the concatenation (such as in what order to concatenate files).
This cant be the only project that uses vanilla JS and needs to be validated for errors. Anyone has any ideas on how I should go about accomplishing the task?
I highly recommend writing tests using jasmine and karma. I've found the two of these integrate really well with Angular and test driven development is highly regarded as one of the best development styles.
With all of this being said, I understand that's not what you're looking for directly because you want more of a "compiler" like solution. The closest thing that you can get to this in JS in my opinion is a linter and when combined with tests, this solution is rather good at finding errors in JS code.
I have a web project I'm working on and it is using LESS to combine all the files into one CSS for me. However I obviously don't want the client side javascript to have to run in production as that is going to slow things down.
Is there a way with the client-side less.js that it can export the .less files you give it to a single CSS file, which I could then call in my live environment?
You have a couple of options for this that I know of:
Use the LESS command line tool
If you're on a Mac, use LESS.app
Running a watch command isn't that big of a deal, it becomes second nature quite quickly :)
Since you want a non-command line option, I'd recommend LESS.app if you're running OS X. If not, try Simpless (cross-platform) or Crunch (Adobe Air-based).
PS. They're all free!
I did find a very interesting tool for identify unused css definitions in a web project.
http://www.sitepoint.com/dustmeselectors/
Are there similar tools also for javascript projects?
P.S.
I know there is no program for deterministically finding unused code. But I am looking for a report to identify possible unused code. Then the last decision will always be your own.
Problem is there is no way to be really sure. Suppose the following:
The initial HTML site is practically empty. There is a lot of JS code though, which seems to be unused.
OnLoad, a function is called which launches an AJAX query to the server. The server returns a lot of HTML code, which is the body of the site. This body contains lots of JavaScript functions.
The initial body is replaced with the body received via AJAX. Suddenly, all code is used.
Static analysis utilities are therefore useless. I do not know whether there exists a browser extension that marks all JS usage from a running browser though.
You can try using tombstones to safely locate and remove dead code from your JavaScript.
https://blog.bugsnag.com/javascript-refactoring-with-bugsnag-and-tombstones/
In order to find the unused assets, to remove manually, you can use deadfile library:
https://m-izadmehr.github.io/deadfile/
It can simply find unused files, in any JS project.
Without any config, it supports ES6, JSX, and Vue files:
The one that comes to mind most quickly is Javascript LINT (http://www.javascriptlint.com/) and JSLint (http://www.jslint.com/).
Beware though: the latter hurts your feelings.
Our project has more than 300 JSP files and more than 200 JavaScript files. I'd like to do some cleanup, removing unnecessary JS files. Even if the JSP includes the JS maybe none of the functions are used. The goal is to reduce both complexity and time needed to load the page. My IDE is Eclipse. Giving the dynamic nature of JavaScript I guess it will be hard or even impossible.
If it's conceivable that the application can be tested with a lot of coverage (i.e. going through every dialog, error message, and situation imaginable) you may be able to work with your access log files - compare the list of JS files to those fetched after period x of heavy use.
An alternative implementation of this would be setting up a "honeypot" (see my answer to this question).
Both these methods are of course "soft" in that their quality relies in how throroughly the application is actually used during testing time.
If you have any way of grepping all script references, that would be preferable. Maybe you can do a global search on {anything}.js, that would match most ways how to embed a JS file.
To find out what functions and javascript files are used in a project, you need code coverage tools, like JSCoverage or Code coverage for Firebug. These tools will return the functions used and the files used. Using these with an automated test suit like the Selenium or randomized testing should give you a fairly good idea which files are loaded.
If the files are loaded dynamically, you can also use Firebug or Fiddler to log the requests for the JS files.
Unfortunately if you want certainty, not just extremely high likeliness that you get with the above tools, you would have to generate a calling graph for your entire webapp, maybe using a Javascript Compiler, like Rhino...
Do you have a step in your deployment process that minifies JS? Do you have any sort of preprocessor for your JavaScript that allows you to leave in comments and console.logs and then have them automatically stripped out? Is your JavaScript machine generated by GWT or Script#? Do you use ANT or another tool to automate deployment?
I see a lot of JavaScript that looks like it comes right out of the editor, complete with lots of white space and comments. How much of that is due to not caring about the state of the deployed code, and how much is due to the spirit of the open web?
I usually check it out with JSLint to make sure it is bug-free, then pack it/encode it with YUI compressor.
My steps include:
I write Javascript using TextMate with the Javascript Tools bundle installed. This JSLint's my files on every save and notifies me when errors occur.
I use Sprockets to automatically concatenate my various Javascript files.
I run the resulting concatenation through jsmin to generate a minified version.
I end up with a concatenated lib.js file and a minified lib.min.js file. One I use for development, one for production. TextMate commands help automate it all.
I'm still looking for a good solution to actually (unit) test my scripts.
Check out YUI Compressor its a console app that you can use to minify (strip out comments, whitespace etc..) and also obfuscate your javascript files.
JSMin it from Douglas Crockford. We've got it hooked up as a macro in Studio as well as a post build item for some of our larger projects
FWIW, here's an interesting mini-benchmark on various ways you can minimize your Javascript source:
http://www.ericmmartin.com/comparison-of-javascript-compression-methods/
In short:
gzip compression in HTTP protocol really makes a difference (although you need to pay a CPU cost at the server side)
minification (removal of whitespace/comments, change of variable names etc.) also helps, and if you want best result, use it together with gzip compression
js-based decompressors are most likely useless - while you might get smaller size, the CPU overhead on the client is significant.
For one of our products, we concatenate all Javascript files together (most files are used on most pages, so this makes sense for us) and use Javascript::Minifier. This has given us a pretty nice speed boost.
A lot of it is probably due to not caring about people that might be viewing your pages on slower machines with slower connections and assuming that everyone has a 50Mbps line and three Gigs of RAM.
We are minifying our (hand-written + plugins, jQuery, etc.) JS as a part of the build process in .NET environment. No preprocessor, this is something we should definitely be doing once time permits.
P.S. By the way, we're not using console.log, as this will break IE. Instead we have a simple wrapper function, something like:
function log(stuff) {
if (window.console && window.console.log) {
console.log(stuff);
}
};
I have a PHP script that does it on the server side and keeps a cache of whatever it pulls from the source folder(s).
One word- packer
Light a candle, whisper a prayer against IE6 errors, and click "go". Does that count? :)
I don't minify my own javascript code since text tends to gzip/compress well.
I would minify a very large (say > 100 kb) javascript library (but then again I probably would not want to be using such a large library (or just ship what i use)).
I tend to believe that a lot of the javascript-minification is (in reality) done to achieve some sort of (futile) obfuscation of javascript code instead of the proclaimed end-user performance gain.
There's also a .NET port of YUI Compressor which allows you to:-
intergrate the minification/file combining into Visual Studio post-build events
intergrate into a TFS Build (including CI)
if you wish to just use the dll's in your own code (eg. on the fly minification).
I thought I would share my approach to js deployments. Have a look at this blog post:
http://www.picnet.com.au/blogs/Guido/post/2009/12/10/Javascript-runtime-compilation-using-AspNet-and-Googles-Closure-Compiler.aspx
This also includes code to compile (using google's closure compiler) at runtime (when needed).
Thanks Guido