Updated JSAN.js - JSAN.cwd
jhuni
currently executing script is, as long as that script was passed by
JSAN.require. For anything that is a moderately advanced script that
has anything to do with the file system then this can be a really
useful feature. Say for example you have some image files and css
files that are related to a script then you can locate those files and
use them.
I also managed to remove two useless private functions
JSAN._convertPathToUrl and JSAN._convertPackageToPath so I didn't
increase the file size in the process of adding JSAN.cwd to JSAN.js...
Finally when I was testing JSAN.js I noticed that it did not work in
Opera because AJAX requests for non-existant files return a blank
string rather then null like in firefox.
http://jsan.googlegroups.com/web/JSAN.js?gda=HekV0zkAAAD6kWaoCbCT94Ly_Otqo4xbQwMtIW-r17nBq2YXiGHhuiFtYEPVAfuxgrZ5rQJorQGECKgQbmraGdxlZulaYnsh
Furthermore there is a lot of general improvements that could be made
to the JSAN.js file:
1). Use caching in the for loops so that you do not recalculate things
in every iteration.
2). Use mixin with an object literal to save space.
3). Do not make a private function just to use it once, instead make
it inline to save space.
4). The whole file doesn't fit on one line right now.
Expect another version of JSAN with a lot more improvements. I want it
to be built to such a point that if anyone looks at it they think
"this code couldn't possibly be any better."
David E. Wheeler
> JSAN.cwd allows the user to know what the working directory of the
> currently executing script is, as long as that script was passed by
> JSAN.require. For anything that is a moderately advanced script that
> has anything to do with the file system then this can be a really
> useful feature. Say for example you have some image files and css
> files that are related to a script then you can locate those files and
> use them.
Nice!
> I also managed to remove two useless private functions
> JSAN._convertPathToUrl and JSAN._convertPackageToPath so I didn't
> increase the file size in the process of adding JSAN.cwd to JSAN.js...
Did you clone the code on GitHub?
> Finally when I was testing JSAN.js I noticed that it did not work in
> Opera because AJAX requests for non-existant files return a blank
> string rather then null like in firefox.
>
> http://jsan.googlegroups.com/web/JSAN.js?gda=HekV0zkAAAD6kWaoCbCT94Ly_Otqo4xbQwMtIW-r17nBq2YXiGHhuiFtYEPVAfuxgrZ5rQJorQGECKgQbmraGdxlZulaYnsh
>
>
> Furthermore there is a lot of general improvements that could be made
> to the JSAN.js file:
>
> 1). Use caching in the for loops so that you do not recalculate things
> in every iteration.
> 2). Use mixin with an object literal to save space.
> 3). Do not make a private function just to use it once, instead make
> it inline to save space.
> 4). The whole file doesn't fit on one line right now.
+1
Note that we also decided, on IRC I think, to change the name from
"JSAN" to "Just". This is because, really, it has nothing to do with
JSAN itself, but is a library to add library loading to JavaScript.
Since you have the tuits to be doing this hacking, do you feel like
making that change, too?
> Expect another version of JSAN with a lot more improvements. I want it
> to be built to such a point that if anyone looks at it they think
> "this code couldn't possibly be any better."
Go go go!
Thanks,
David
Christoph Dorn
> Note that we also decided, on IRC I think, to change the name from
> "JSAN" to "Just". This is because, really, it has nothing to do with
> JSAN itself, but is a library to add library loading to JavaScript.
> Since you have the tuits to be doing this hacking, do you feel like
> making that change, too?
>
modules [1] as being specified by the ServerJS [2] group. Is there an
interest to support this capability?
I am also interested in writing a package manager for JSAN that runs as
a firefox extension, integrates with the openjsan site and can interact
with the system to install any file into any location on the user's hard
disk.
Christoph
[1] - https://wiki.mozilla.org/ServerJS/Modules/SecurableModules
[2] - https://wiki.mozilla.org/ServerJS
jhuni
"JSAN" to "Just". This is because, really, it has nothing to do with
JSAN itself, but is a library to add library loading to JavaScript.
as the current 'JSAN.js'. The question we have to ask ourselves though
is what do we do about CSS.Change, MochiKit, and all those other
modules that depend on the JSAN JavaScript interface? It is going to
be really hard to get rid of the JSAN.js file if that is what you guys
are aiming for, and if we do create 'Just' we are probably just going
to divide the community which isn't quite good either.
I am thinking why can't we have JSAN.js be a standard interface for
loading JavaScript modules regardless of what platform you are working
with? That way if somebody comes around with a different file system
interface other then AJAX such as: Titanium Appcelerator, Serverjs,
and who knows how many others then we can just switch out the JSAN.js
file as long as it implements JSAN.use and JSAN.require and it will
immediately work correctly.
Let me give a hypothetical situation: we move all the modules over to
'Just.js' but then the Titanium people make 'TitaniumLoader.js' well
there is no hope of there interface ever working with all the modules
because we use 'Just.js' but what if instead they created a different
version of 'JSAN.js' then it would work correctly....
Anyways if you can elaborate more on how you are going to deal with
such issues as fragmenting the community and dealing with all those
old modules then we can get started with building this new interface.
Christoph Dorn
> I am thinking why can't we have JSAN.js be a standard interface for
> loading JavaScript modules regardless of what platform you are working
> with? That way if somebody comes around with a different file system
> interface other then AJAX such as: Titanium Appcelerator, Serverjs,
> and who knows how many others then we can just switch out the JSAN.js
> file as long as it implements JSAN.use and JSAN.require and it will
> immediately work correctly.
>
I think this is a great idea.
Christoph
David E. Wheeler
> I am interested in contributing to Just to enable it to load securable
> modules [1] as being specified by the ServerJS [2] group. Is there an
> interest to support this capability?
The module description there sounds pretty close to what JSAN.use()
does, although use() doesn't return a function, it installs it into
the calling namespace. But I'd want to have the ability to tell a
module to export more than one function at a time, personally.
> I am also interested in writing a package manager for JSAN that runs
> as
> a firefox extension, integrates with the openjsan site and can
> interact
> with the system to install any file into any location on the user's
> hard
> disk.
Ooh, nice. +1
Best,
David
David E. Wheeler
> I could easily throw together a 'Just.js' that is pretty much the same
> as the current 'JSAN.js'. The question we have to ask ourselves though
> is what do we do about CSS.Change, MochiKit, and all those other
> modules that depend on the JSAN JavaScript interface? It is going to
> be really hard to get rid of the JSAN.js file if that is what you guys
> are aiming for, and if we do create 'Just' we are probably just going
> to divide the community which isn't quite good either.
Yeah, it'd be tricky.
> I am thinking why can't we have JSAN.js be a standard interface for
> loading JavaScript modules regardless of what platform you are working
> with? That way if somebody comes around with a different file system
> interface other then AJAX such as: Titanium Appcelerator, Serverjs,
> and who knows how many others then we can just switch out the JSAN.js
> file as long as it implements JSAN.use and JSAN.require and it will
> immediately work correctly.
The reason we wanted to change the name of the JavaScript library is
because it has nothing to do with (Open)JSAN. The name is a misnomer.
I agree that it could be difficult to get other libraries to adjust to
the name; we'd obviously have to have some sort of deprecation policy
and provide backward compatibility for a while.
John, what did you have in mind here?
> Let me give a hypothetical situation: we move all the modules over to
> 'Just.js' but then the Titanium people make 'TitaniumLoader.js' well
> there is no hope of there interface ever working with all the modules
> because we use 'Just.js' but what if instead they created a different
> version of 'JSAN.js' then it would work correctly....
I don't see how the naming being JSAN or Just effects such situations.
They just rename the file to JSAN.js or Just.js, as appropriate. I
don't think that the interface will change much. Will it?
> Anyways if you can elaborate more on how you are going to deal with
> such issues as fragmenting the community and dealing with all those
> old modules then we can get started with building this new interface.
Yeah, it's not something I'm working on, I just wanted to bring it to
your attention.
Best,
David
jhuni
someone else who is capable of making this change effectively then
great.
I am going to focus on contributing as many useful modules as
possible.
jhuni
compressor! Besides that I have got JSAN.js to work in all the modern
web browsers. ( I had to make it prefer ActiveXObject for Internet
Explorer because in Internet Explorer 7.0 XMLHttpRequest is defined).
There isn't much of an excuse anymore not to use JSAN.js.
David E. Wheeler
Link for your revised version? Is it in GitHub?
—Theory
jhuni
> Link for your revised version? Is it in GitHub?
>
http://bazaar.launchpad.net/%7Ejhuni-x/gold-os/trunk/annotate/head%3A/lib/core/JSAN.js
I decided to use object literals and anonymous subroutines to save
space and to just make the code more organized. Now it is very small
with the YUI compressor.
http://yui.2clics.net/
Nickolay Platonov
There isn't much of an excuse anymore not to use JSAN.js.
Regards, Nickolay
jhuni
important then those issues.
Also, I do not see why if (JSAN.includePath.length==1) there would be
more then one HTTP request.
Besides I have not seen a better option. I have not seen Dojo do any
better with dojo.require and JS.Class require is no better either.
On Jul 15, 10:45 pm, Nickolay Platonov <nickol...@gmail.com> wrote:
Nickolay Platonov
Also, I do not see why if (JSAN.includePath.length==1) there would be
more then one HTTP request.
If the module which is being 'required' in turn requires another module, etc (recursive dependencies) - there will be
a separate synchronous http request for each file - this is not acceptable in production environment.
Besides I have not seen a better option. I have not seen Dojo do any
better with dojo.require and JS.Class require is no better either.
http://groups.google.com/group/jsan/browse_thread/thread/8035ed10b2e6750c
http://github.com/SamuraiJack/JooseX-Namespace-Depended/tree
Regards, Nickolay
jhuni
server side to optimize the HTTP request' and that would have been
just fine.
Indeed I have thought of that before, but I think that many people
will not have that option, you realize that JSAN works without a
server and without perl installed? Besides people can use Task or
something similar to combine several modules in one.
I think it would be highly preferable to add that as an option to JSAN
that can work with or without a server, something like JSAN.deps
('DOM.Events', 'HTTP.Cookies', 'Canvas.Explorer', 'Pod.HTML') or
something like that, and if we are not using the server-based
interface it can still work...
If you have your own local installation then HTTP requests are not a
performance issue so grouped dependency loading should be an OPTIONAL
optimization after the fact, which can be done in JSAN if we combine
the statements. It only takes 3.8 kb for JSAN now so I do not think
more options will hurt.....
I would be glad though if Joose itself would be reduced to like a 5 kb
core with optional loading of the other modules, because I have a
working implementation of Classes and Roles in like 5 kb and that is
all I need.
The whole 41.8 kb is way too much for many people including myself,
when most of the things in there are not going to be used by the
average person. In fact, that is about the same size as the entire
JS.Class standard library.
On Jul 16, 9:55 pm, Nickolay Platonov <nickol...@gmail.com> wrote:
>
> > Also, I do not see why if (JSAN.includePath.length==1) there would be
> > more then one HTTP request.
>
> If the module which is being 'required' in turn requires another module, etc
> (recursive dependencies) - there will be
> a separate synchronous http request for each file - this is not acceptable
> in production environment.
>
> > Besides I have not seen a better option. I have not seen Dojo do any
> > better with dojo.require and JS.Class require is no better either.
>
> You may want to look at these links for the alternative approach:
>
>
> Regards, Nickolay
Nickolay Platonov
If you have your own local installation then HTTP requests are not a
performance issue so grouped dependency loading should be an OPTIONAL
optimization after the fact, which can be done in JSAN if we combine
the statements. It only takes 3.8 kb for JSAN now so I do not think
more options will hurt.....
Yes, grouped dependencies loading is an optional feature, JooseX.Namespace.Depended can work
in usual "request per module" mode, without any server-side components.
I would be glad though if Joose itself would be reduced to like a 5 kb
core with optional loading of the other modules, because I have a
working implementation of Classes and Roles in like 5 kb and that is
all I need.
Oh, interesting, could you post a link to your implementation? Btw, Joose 3.0 core is 8kb (after YUI+gzip).
The whole 41.8 kb is way too much for many people including myself,
when most of the things in there are not going to be used by the
average person. In fact, that is about the same size as the entire
JS.Class standard library.
Yes, Joose 2.0 is kinda all-in-one package, this is going to be changed in 3.0 version.
Regards, Nickolay
jhuni
> Yes, grouped dependencies loading is an optional feature,
> JooseX.Namespace.Depended can work
> in usual "request per module" mode, without any server-side components.
>
interface instead of doing that within JSAN as people already have
been doing. I mean one of the biggest problems with the JavaScript
community is we do not have unity over anything, even the
implementation of the language itself is divided by Internet Explorer,
Firefox, Opera, Chrome, and Safari. Then for module loading there is
Dojo, JSAN, JS.Class, YUI 3, JSPAX, Joose.... In Perl there is just
one implementation used and there is just one module loading mechanism
and if it were any other way the language would be as dead as
Fortran.
In Perl6 there is no Moose there is just one way of creating Classes
and Roles and I like Perl6 but in JavaScript you have to look at
JS.Class, Joose, and all these different people competing and everyone
has a different interface. Sometimes I feel like just writing standard
JavaScript is the best way to go so that you do not alienate any
developer with a library.
>
> > I would be glad though if Joose itself would be reduced to like a 5 kb
> > core with optional loading of the other modules, because I have a
> > working implementation of Classes and Roles in like 5 kb and that is
> > all I need.
>
> Oh, interesting, could you post a link to your implementation? Btw, Joose
> 3.0 core is 8kb (after YUI+gzip).
>
particular small piece of code but I will get one soon hopefully and
the basic point I was trying to say is I do not need anything more
then the MooTools Class interface you know something very simple for
almost all of my code, something small like 5 kb and if I need more
then that I want to be able to say JSAN.use('Joose.Types') or
whatever.
Also since we are on this topic something that I think is a real waste
and that is really annoying is this:
Module("com.test.module", function (m) {
Class("Test", {
methods: { world: function () { return "hello" } }
});
});
I would much rather see this:
Class("com.test.module.Test", {
methods: {
world: function() {
return "hello";
}
}
});
I mean even just going and saying Joose.Class.create() and rolling
your own assign statement would be okay but why go through what is a
cumbersome interface in my opinion? Anyways I might use Joose someday
but I do not know right now.
Nickolay Platonov
Okay but there is no reason why you would need to make a separate
interface instead of doing that within JSAN as people already have
been doing.
Well, there were reasons to make a separate interface.. It were drawbacks of JSAN.js:
- its strictly synchronous
- it can't be extended (easily) to support dynamic css/images/whatever loading
JooseX.Namespace.Depended address all above. It can be extended really easily with couple of
standard Roles - see for example how the support for SSJS were added. Plus it supports grouped mode.
Actually, I've suggested on the IRC channel, that ideas on which JooseX.Namespace.Depended is based
can be re-written in "pure" javascript and then both JSAN.js and JX.N.D can rely on that library - w/o any feedback..
I mean one of the biggest problems with the JavaScript
community is we do not have unity over anything, even the
implementation of the language itself is divided by Internet Explorer,
Firefox, Opera, Chrome, and Safari. Then for module loading there is
Dojo, JSAN, JS.Class, YUI 3, JSPAX, Joose.... In Perl there is just
one implementation used and there is just one module loading mechanism
and if it were any other way the language would be as dead as
Fortran.
In Perl6 there is no Moose there is just one way of creating Classes
and Roles and I like Perl6 but in JavaScript you have to look at
JS.Class, Joose, and all these different people competing and everyone
has a different interface. Sometimes I feel like just writing standard
JavaScript is the best way to go so that you do not alienate any
developer with a library.
Yes, the problem you are talking arises due to the lack of packaging standard in JS.
The goal of JSAN project is to establish such standard. Unfortunately there is not enough
man power behind it - the project is stagnating..
Also since we are on this topic something that I think is a real waste
and that is really annoying is this:
Module("com.test.module", function (m) {
Class("Test", {
methods: { world: function () { return "hello" } }
});
});
I would much rather see this:
Class("com.test.module.Test", {
methods: {
world: function() {
return "hello";
}
}
});
Good point, this was fixed in 3.0 version. Moreover, In Joose 3.0 you can write:
Class('Level1.Level2.Level3', { ... })
var a1 = new Level1.Level2.Leve3()
and later:
Class('Level1', { ... })
var a2 = new Level1()
Class('Level1.Level2', { ... })
var a3 = new Level1.Level2()
Perl-like namespacing..
jhuni
all this code out there that depends upon JSAN. Seriously you have not
provided any good reasons. Just change how JSAN.require works do not
make a whole other library!
We already have all this code out there what do you expect to do about
that?
Seriously though this JooseX.Namespace.Depended thing requires a bunch
of Joose libraries that most of the JavaScript community will not want
to use. JSAN.js does not require any libraries.
> - it can't be extended (easily) to support dynamic css/images/whatever
> loading
you!!! The point is to be a 4 kb extension to the JavaScript language
that doesn't depend on any other library and which can be used to load
other libraries.
If you want to load CSS the best people around for that are the YAHOO
user interface people they have made YAHOO.util.StyleSheet and other
great utilities for that and they do not use Joose. I want to have a
library to load the YAHOO libraries and JSAN.js is only 3.8 kb.
> Unfortunately there is not enough man power behind it - the project is stagnating..
everyone out there wants to develop there own JavaScript library. Okay
but do not try to make your own packaging standard!! Now every dang
JavaScript library wants to make its own packaging standard and there
is no reason that if you make JooseX.Namespace.Depended that anyone is
going to use that especially when they can use JS.Class, Dojo, or a
number of other libraries.
Seriously you have shown no reason to discontinue support for
JSAN.require. Change how JSAN.require works if you want. Make another
version. How it works right now is not a good excuse.
> The goal of JSAN project is to establish such standard
everyone to use?
jhuni
The real question is: why not make JSAN.require() a packaging standard
and base Joose after it? People will not use more then 3.8 kb!
Why not if you have an idea for an improvement in packaging include
that in JSAN??!?!?
JSAN.require can be changed to work with SSJS.
Packaging should not be dependent upon Joose because most people will
not use Joose and if you make packaging dependent upon Joose you have
lost at least me.
Nickolay Platonov
Why don't you start a thread like "JSAN.js refactoring" with your ideas how to make it asynchronous, etc?
My point is simple: JSAN.js is not usable in production and renaming it to 'Just' will not help.
The optimizations you made also will not help.
JSAN.js should be deeply refactored, but there is no any community will for that, thats why it stays unchanged,
and thats why another loaders appears.
About Joose - just do not use if you don't want, did I ever said you MUST use it. The same about JX.N.D.
And I'm staying with JSAN project because I believe its the only true approach to the JS packaging currently.
I hope sometimes will appear new members who will be able to "resurrect" it.
Meanwhile I'm doing what I can:
http://github.com/SamuraiJack/Module-Build-JSAN-Installable/tree
http://github.com/SamuraiJack/JSAN-Prove/tree
Regards, Nickolay
jhuni
"Just." I am sorry for being irrational. You kind of made things sound
hopeless there but lets forget that.
Anyways I guess I should say there is advantages to using JSAN.js
because I will be working on it and heavily testing it in all the web
browsers.
I will add support for group module loading too I suppose. Something
like this?
JSAN.cache();
JSAN.require('Joose');
JSAN.require('HTTP.Cookies');
JSAN.require('MochiKit.Signal');
JSAN.uncache();
I suppose that could effectively store those three statements
somewhere then make a combined request on .uncache() but then if it
goes to JSAN.require('MochiKit.Signal') then MochiKit.Signal also will
require MochiKit.Base and MochiKit.DOM so if you could add those on
too then you would only need a single HTTP request. But where would
you be able to get such data?
Maybe some statement:
JSAN._deps('MochiKit.Signal', ['MochiKit.Base', 'MochiKit.DOM']);
JSAN._deps('MochiKit.DOM', 'MochiKit.Base');
Then that could help things along I suppose and that could minimize
HTTP requests even more. There is a lot to consider. I will get to
work on all of these issues.
Maybe I should restart the entire library from scratch. Then I won't
have to fix all of Casey West's mistakes lol
On Jul 18, 10:35 pm, Nickolay Platonov <nickol...@gmail.com> wrote:
> Seems you like arguing, for the sake of arguing. Instead of this, why don't
> you address the mentioned issues in JSAN.js?
> Why don't you start a thread like "JSAN.js refactoring" with your ideas how
> to make it asynchronous, etc?
>
> My point is simple: JSAN.js is not usable in production and renaming it to
> 'Just' will not help.
> The optimizations you made also will not help.
>
> JSAN.js should be deeply refactored, but there is no any community will for
> that, thats why it stays unchanged,
> and thats why another loaders appears.
>
> About Joose - just do not use if you don't want, did I ever said you MUST
> use it. The same about JX.N.D.
>
> And I'm staying with JSAN project because I believe its the only true
> approach to the JS packaging currently.
> I hope sometimes will appear new members who will be able to "resurrect" it.
>
>
> Regards, Nickolay
Christoph Dorn
> Maybe I should restart the entire library from scratch. Then I won't
> have to fix all of Casey West's mistakes lol
>
There is now a browser platform [2] as well.
Christoph
[1] - https://wiki.mozilla.org/ServerJS
[2] - http://github.com/tlrobinson/narwhal/tree/master/platforms/browser
jhuni
working with us.
I believe in improving the JSAN interface because we already use it
with many of our modules.
I said before though that I might be interested in making the JSAN
modules work with ServerJS at some time in the future.
On Jul 19, 8:47 am, Christoph Dorn <christoph...@christophdorn.com>
wrote:
David E. Wheeler
>> - it can't be extended (easily) to support dynamic css/images/
>> whatever
>> loading
>
> The point of the JSAN standard is not to load all your files for
> you!!! The point is to be a 4 kb extension to the JavaScript language
> that doesn't depend on any other library and which can be used to load
> other libraries.
Well put (and part of the reason I suggested changing its name to
"Just"). But development and marketing will need to be pushed forward
for any good to come of it.
Best,
David
jhuni
JSAN.js merely implements a few statements that should have been put
in the core of the language A LONG TIME AGO.
I guess the name of the file doesn't really matter. I would just like
people would are developing JavaScript libraries to continue to use
JSAN.js because it is supported either way.
I am okay with the idea I am thinking about adding the following:
window.Just = window.JSAN;
But since nobody uses window.Just I do not know if it will do any
good.
David E. Wheeler
> In Perl use() and require() are both are core part of the language,
> JSAN.js merely implements a few statements that should have been put
> in the core of the language A LONG TIME AGO.
Agreed. I think Brandon might agree, as well.
> I guess the name of the file doesn't really matter. I would just like
> people would are developing JavaScript libraries to continue to use
> JSAN.js because it is supported either way.
Well, it'd be `Just.use()` and `Just.require()`, so it's a class name,
as well.
> I am okay with the idea I am thinking about adding the following:
>
> window.Just = window.JSAN;
>
> But since nobody uses window.Just I do not know if it will do any
> good.
The idea is to then encourage people to use the loading functions from
Just rather than JSAN, since JSAN.js is not the same as JSAN
(openjsan.org).
Best,
David