DoubleDollarJS.com
doubledollarjs.com
doubledollarjs.com
Why would one choose something like this over Angular or Ember?
$$ ({
home: {
route: {
defaultOnly : true
}
}
})
$$
home:
route:
defaultOnly: true
He spent about five minutes on the latest show explaining it... but frankly I still have no clue what it is.
The core of it: dealing with the DOM kind of sucks, and as much as keeping 3 main file types around (.html, .css, .js) for web development isn't too much of a pain, the fact that HTML sits between everything muddies the water quite a bit.
Sure, $$ needs some more love and a community to pick it up and run, but kudos to you for getting it out there and having a solid philosophy (tiny robust kernel, super extensible, consistent docs). And yes, I'd write the code more compactly (the de facto js notation mentioned in another comment), but whatever, that's easy to translate.
I say all this because our team is working on an app ( http://luunr.com ) and toggling back and forth between HTML and JS is borderline silly (we looked at things like Angular and couldn't get behind them, feels to rigid and baked in my book). Would have loved to experiment with this a few weeks ago when we started.
Keep up the good fight and continue developing $$!
The above seems awfully close to a dogmatic sort of "if you don't get it, the fault is with you" kind of statement.
Here's an example slideshow application's source: http://oinksoft.com/static/js/jig.example.js
And here's Jig.js, use at your own risk: http://oinksoft.com/static/js/Jig.js
Erm, license ... how about MIT? MIT license it is.
The `slides' array is my data store, and the `presenter' object handles clearing out the page for the next slide. The actual app logic is tiny, but right away you get hash URLs, easy dispatching to actions, and a very simple controller/action model that can actually be even lighter than this example shows (for instance, you can choose to define no controllers at all, and just have an action list, kind of like Sinatra).
It doesn't use HTML5 History, and I'm sure it has all types of subtle issues because, like I said, it's only for internal use. But I see people are interested in tools like this, so I thought I'd let you all see :^)
The current popular offerings are HEAVY (Backbone, Ember, Angular) but I'm not going to release something that isn't industrial strength.
People shouldn't be so harsh to independent authors. I feel differently about large companies like Google and Microsoft, who get extreme value out of open source.
There's a reason I don't release many handy tools like the one linked in this comment, and it's because I expect a torrent of criticism to follow (which I can handle) and I'm not interested in changing it at all except for my own purposes (and so I'd just feel guilty).
The mantra of the critique culture is that you are not your ideas. Criticism of the idea does not imply criticism of the author – at least not in my world.
In any case, my main reason for withholding things is the "guilt" factor I mention at the end of my previous comment.
Binding URLs to functions and dispatch strings is all I need for a great many small projects; I have a very easy time managing the DOM with my own widgets and managing data with simple JavaScript objects. So the "heavy" part can be having to learn which parts of the API I do or don't need, reading through tutorial docs, etc.
Try it, you're refusal to "get past the need to mix markup and code" is restricting you from some pretty helpful functionality if you build JS heavy web apps!
People who write business code and logic often have little to no concern about tables vs divs, CSS quirks, and markup structure in general. Conversely, our UX people have no concerns whether we use MongoDB or SQL Server to serve records. They shouldn't have to. Our concerns are separated by using proper design and architecture, and we can work on things together while focusing on implementing our particular skillsets.
The script/markup mixture of DD and Backbone is not necessary at all, and it's a quirk because these frameworks (and others) make it one!
Probably because of this: http://jsperf.com/string-concatenation-vs-the-dom
Yes, it's faster to create DOM elements in string form rather than one-by-one, attribute-by-attribute.
However, creating DOM structure in code sucks. It's far better (and faster) to create markup and deal with templates by compiling HTML files into strings in JavaScript files and then turn those strings into DOM structure when needed.
Once you create DOM fragments from singular, compiled strings, you can perform data binding.
So, instead of this (from your benchmark):
var $dropdown = $('<select class="s">');
$u.find('a').each(function() {
var $a = $(this);
$('<option>').html($a.text()).attr('value', $a.attr('href')).appendTo($dropdown);
});
<select class="s" data-binding="{@source: aElements}">
<option data-binding="{@template-for: aElements}{value: href}{@text: aText}">
</select>
Writing markup to represent the presentation of data, and code to represent the logic of business is far superior to writing code that does both!
$$.js:28Uncaught SyntaxError: Unexpected token default
$$.(hooks).js:11Uncaught ReferenceError: $$ is not defined
$$.(core).js:246Uncaught SyntaxError: Unexpected token delete
$$.(router).js:1Uncaught ReferenceError: $$ is not defined
$$.(bindings).js:23Uncaught SyntaxError: Unexpected token default
$$.content.js:1Uncaught ReferenceError: $$ is not defined
$$.home.js:9Uncaught SyntaxError: Unexpected token default
$$._bootstrap.js:26Uncaught ReferenceError: $$ is not defined
Uncaught LiveEdit Failure: Failed to compile new version of script: SyntaxError: Unexpected token :A comparison of what it offers compared to at least a couple of the major libraries offering those things would've been useful...
I roll with BSD KNF across all of my brace-based langs.
Or in this case just use coffeescript and rejoice.
They're over-written by a page if that page defines that variable globally in some way.