modisposition

TL;DR Here you have the solution to all your problems ... no? So take a break, and read through :) Current Status Using a generic " module loader " for JavaScript files is becoming a common technique, and full of wins, not only on the node.js server side. There are different client side alternatives , not entirely based over the module concept, and apparently only one concrete proposal, called AMD , able to work in both server and client following a build/parsing procedure. However, as somebody pointed out already ... AMD is Not the Answer This post does not even tell everything bad about AMD problems, and I am getting there, but it's surely a good starting point. Tobie article is another resource that inspired somehow what I am going to propose here, so before discriminating this or that technique, I hope you'll find time to understand the whole problem ... found it? Let's go on then :) The Beauty Of node.js require Function I don't think I should even s...

This is an early introduction to a project I have been thinking about for a while. The project is already usable in github but the documentation is lacking all over the place so please be patient and I'll add everything necessary to understand and use yuno . Zero Stress Namespace And Dependencies Resolver Let's face the reality: today there is still no standard way to include dependencies in a script. If we are using a generic JS loader, the aim is to simply download files and eventually wait for one or more dependency in order to be able to use everything we need. The require logic introduced via node.js does not scale in the browser due synchronous nature of the method itself plus the sandbox not that easy to emulate in a browser environment. The AMD concept is kinda OKish but once we load after dependencies, there is no way to implement a new one within the callback unless we are not exporting. I find AMD approach surely the most convenient but still not the best one: w...

This is a Q&D solution for some JavaScript precision problem when we use the module operator with floating point numbers. The Problem If we are dealing with the module operator we could have this case: alert( 8.25 % .05 ); // 0.049999999999999545 We expected 0 but we have a floating point inconsistency instead. This is a well known problem, and not only with JavaScript, truly annoying when we have to show run-time computed money/trends operations. The Solution This comes from my reply in a JS forum, knowing that the module will be a simply floating point, let's say .1 to .001, if we remove floating point from the right side of the operation everything works just fine: function mod(num, mod){ // Another WebReflection silly idea var pow = Math.pow(10, (("" + mod).split(".")[1] || "").length); return ((num * pow) % (mod * pow)) / pow; }; alert( mod(8.25, .05) ); // 0 alert( mod(8.25, .1) ); // 0.5 That's it, have a nice ...