ruby JS library
Ondrej Certik
in case you don't know about this JS library:
http://jsclass.jcoglan.com/
that implements Ruby like programming in JS. Which is imho very
similar to Python in many aspects.
Ondrej
--
You received this message because you are subscribed to the Google Groups "JavaScript for Python programmers" group.
To post to this group, send an email to js...@googlegroups.com.
To unsubscribe from this group, send email to js4py+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/js4py?hl=en-GB.
Jonathan Fine
Hi,
in case you don't know about this JS library:
http://jsclass.jcoglan.com/
that implements Ruby like programming in JS. Which is imho very
similar to Python in many aspects.
This is interesting. There's definitely a widespread wish to make JavaScript programming easier by adopting concepts from other languages.
An aside. I find the concept of a library in JavaScript interesting, because it lacks a built in concept of module. For me a library is a related collection of modules, or something similar.
What is really missing in all of this is a standard library. The CommonJS group have a JavaScript standard library as one of their stated goals.
--
Jonathan
Peter Rust
> What is really missing in all of this is a standard library.
> The CommonJS group have a JavaScript standard library as one of their stated goals.
Server-side Javascript (CommonJS) avoids a number of issues in client-side Javascript, which makes a standard library much easier.
In client-side Javascript, the weight of additional, unneeded files (you don’t want users to have to download an entire standard lib when they load your page) and the undesirability of including every needed file independently (i.e. every imported module or function in a separate file, which would bloat the HTML and the number of separate requests) require some sort of packaging system.
The Google Closure Library has attempted to become a standard library for Javascript developers with a wide array of functionality – but from what I’ve seen, it has failed to be accepted as such for two important reasons: (1) It requires a packaging system installed on the developer’s server in a particular language – they haven’t made their packaging system available in Python, Ruby, PHP, etc. It can be argued that it’s not too hard to install Java on a dev machine, but – whether it’s really that hard or not – the reality is that developers tend to steer clear of downloading/installing different languages/frameworks than the ones they’re using. And (2) it requires a different workflow and style than what web developers are used to… the Google guys didn’t work hard at making their approach look like the typical web approach and/or allow multiple ways of doing things to try to get widespread acceptance from the web developer community.
The MooTools library has developed a packaging system on their server (or at least they planned to, I haven’t followed them closely), where you choose what components/modules you want on their server and their server prepared a packed/minified file for you.
Libraries like Prototype and jQuery – which really are more “built-ins” library than a full “standard” library – pack everything into a single file and usually offer that file in both full (w/ comments, unminified) form and minified form.
“Full” libraries, like jQuery’s plugin library and Prototype’s Scripteka library, offer each plugin/module for independent download. The developer adds the <script> tag to include the additional library.
Many libraries have started out as Prototype-dependent or jQuery-dependent, but as they have matured, the maintainers have written hooks so they can be used in a variety of environments, as well as a “vanilla” mode, where the maintainers have rewritten from scratch the parts that they depended on a 3rd party library for, or they have included a standalone piece (like Sizzle) with their library that does just that function.
More UI-centric libraries – like YUI, ext and Dojo – and to a lesser extent jQuery UI and PrototypeUI – have a more module-based system with packaging, dependencies and the like.
Because Javascript has so few batteries included – not just the lack of a standard library, but, more critically, the lack of full-feature built-in data structures and functions – each library has provided a built-ins-level core. Like Python, this often includes functional-style functions as well as richer data structures. However, the web being so central to client-side development, these builtin-level libraries often also include DOM helpers, Selector engines and Ajax helpers. Also, the more “UI-component” libraries include base classes for building UI widgets.
The lack of consistency between these “built-in-level” libraries, the ease of programming with them and the challenge of programming without them has led to large non-standard libraries developing around each core built-in-level library. Only the modules or components that gain real traction and programming power can develop to the point where they become compatible with multiple low-level Javascript libraries or also can operate in “vanilla” mode without a low-level library.
The weight of additional low-level libraries – real or perceived – has kept developers from wanting to add multiple low-level libraries to their projects. This has also added to the fragmentation of the Javascript library space.
In order for a “standard” library to really be accepted, it would probably need to write API bridges/wrappers between 2 or 3 low-level libraries (one of these would certainly need to be jQuery), so that developers could pick from components written for multiple low-level libraries without adding the full weight of all the low-level libraries. The packaging/dependency system – if there is one – would need to either be a server-side solution, maintained and operated by the standard library team (like mootools online packaging/dependency system), or would need to be available in PHP and Ruby and probably at least one of (Python, Java or .Net).
-- Peter Rust
Jonathan Fine
> What is really missing in all of this is a standard library.
> The CommonJS group have a JavaScript standard library as one of their stated goals.
Server-side Javascript (CommonJS) avoids a number of issues in client-side Javascript, which makes a standard library much easier.
In client-side Javascript, the weight of additional, unneeded files (you don’t want users to have to download an entire standard lib when they load your page) and the undesirability of including every needed file independently (i.e. every imported module or function in a separate file, which would bloat the HTML and the number of separate requests) require some sort of packaging system.
The weight of additional low-level libraries – real or perceived – has kept developers from wanting to add multiple low-level libraries to their projects. This has also added to the fragmentation of the Javascript library space.
In order for a “standard” library to really be accepted, it would probably need to write API bridges/wrappers between 2 or 3 low-level libraries (one of these would certainly need to be jQuery), so that developers could pick from components written for multiple low-level libraries without adding the full weight of all the low-level libraries. The packaging/dependency system – if there is one – would need to either be a server-side solution, maintained and operated by the standard library team (like mootools online packaging/dependency system), or would need to be available in PHP and Ruby and probably at least one of (Python, Java or .Net).
Oh dear. So for the browser it's not enough just to write a decent low-level library, but one has to provide so many other things as well. If you're right then JavaScript is indeed a sticky environment.
Peter Rust
> for the browser it's not enough just to write a decent low-level library,
> but one has to provide so many other things as well
I believe so. jQuery has become incredibly popular low-level library among client-side developers, but not enough so (IMO) to ignore the thousands of developers who have chosen a different low-level library (Prototype, Mootools, closure, ext, dojo, YUI, base2, etc).
The Google Closure Library attempted to be a “standard library” for Javascript, but failed. JSAN has attempted to be a sort of PyPI/CPAN for Javascript, but also hasn’t gained significant traction (IMO).
Note that there is a difference between “standard library” and “open library” (PyPI/CPAN), but in Python (and I think this is a good practice) the “standard library” grows out of the “open library”. Items in the “open library” that gain a lot of traction (ElementTree, for instance) get added to the “standard library”.
I would focus primarily on the “open library” before trying to pull out the best modules for a “standard library”. The “open library” should not mandate that a particular low-level javascript library is used – rather, it should publish a low-level API specification that the low-level library must implement. All modules/plugins in the open library can depend on the low-level library being implemented.
However, that low-level library API specification should be written fairly close to jQuery’s API so that the most popular of the almost 5,000 jQuery plugins will work in the new open library with no change or with changes that can be automated.
Also, there should be bridges that allow one (or preferably two) other low-level javascript libraries to implement the low-level API specification, so that they can be used as an alternative low-level library. This would make the system much more “open” and encourage any libraries that weren’t included to write their own bridges to they can also play.
The low-level API specification should include things like AJAX, a Selector Engine, DOM Helpers, Event helpers as well as various utilities. Being a Prototype user myself, I’m familiar with how the Prototype library structures these things. Though it has a different syntax than jQuery, and a bridge could be written make it conform to a jQuery-like low-level API.
Or, maybe I’m wrong and a JSAN-type library that tracks dependencies could be written with vanilla Javascript as the base and the jQuery itself – as well as Prototype and other packages – could be broken down into their component parts and placed in JSAN… then the jQuery plugins could be analyzed for what particular components of jQuery they depend on and could be placed in JSAN with those dependencies listed… This looks like what someone has done with Prototype. While JSAN looks promising, the community seems too focused on Perl and Joose and not focused enough on quality (Ian Bicking’s doctestjs doesn’t load) and on bringing the masses of client-side developers (and jQuery developers) on board.
Perhaps the JSAN concept is right and all it lacks is support from the jQuery community – pulling in all the plugins, listing the dependencies, breaking jQuery into its component parts – and a packaging system written in PHP, Ruby and Python/Java/.Net.
-- peter
From: js...@googlegroups.com [mailto:js...@googlegroups.com] On
Behalf Of Jonathan Fine
Sent: Friday, May 07, 2010 1:23 PM
To: js...@googlegroups.com
Subject: Re: ruby JS library
On Fri, May 7, 2010 at 4:14 PM, Peter Rust <pe...@cornerstonenw.com> wrote:
Nick Fitzgerald
_Nick_
For what its worth, the way that CommonJS implements modules can be mimicked on the client side:var moduleName = {}(function (exports)var foo = "local to module";exports.bar = "public api of module";}(moduleName));This, and variations of this, are a common pattern in javascript. This particular pattern almost exactly mimicks the semantics of CommonJS modules, but you don't get access to little things like filename, filepath, etc...You could explicitly define __all__ in your python modules and then when they render to js, wrap them in the self invoking function and attach everything thats in __all__ to exports at the bottom of the function. Or you could do how Python does and attach everything that doesn't start with a "_" to exports automatically.
_Nick_
Nick Fitzgerald
_Nick_