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...

playing with Harmony Proxy I came out with a simple snippet: The aim of above snippet is to forget the usage of require ... here some example: module.sys.puts("Hello implicit require"); var fs = module.fs; fs.stat( ... ); It's compatible with nested namespaces too and if there are non JS chars in the middle ... well: var Proxy = module["node-proxy"];

I am very busy these days with my last (hopefully) moving into my new and completely empty rented flat ... and while I am building home utilities and preparing my last post about A Better JS Class , with some extra case where common libraries fail with their parent implementations, I would like to quickly share this require function I wrote days ago but just recently came back in front of my eyes. Why require In CommonJS we have different techniques and agreement about how developers should structure/organize their namespaces and libraries. The first common function adopted from CommonJS " followers " is the require one. This function aim is to load once, and runtime, a namespace, allowing scripts loaded via this function to define exported properties/variables or methods/functions. // file main.js var $ = require("jquery").$; // file jquery.js // let's imagine jQuery library has this piece of code inside if ( typeof exports != "undefined" ) { //...

There is one single thing I don't like about CommonJS Idea , the fact nobody is thinking about the client side!!! CommonJS Why Since everybody would like to use JavaScript as Server Side Programing Language , where right now I can count there about 50 implementations, somebody decided that at least basic stuff such IO operations, streams or sockets, and much more, should have a common behavior, namespace, API, across all different implementations. In few words, these guys are trying to create their own WSW Consortium , and this is absolutely OK. So what am I complaining about? Client CommonJS If we, as developers and libraries authors, would have adopted a similar strategy ages ago, rather than fight with each other about natives prototypes pollutions, web development would be probably even easier for everybody. We failed, while those server side guys started correctly. The problem, for both language usage and its environment, is that JavaScript on server has different problems th...