DoubleDollarJS.com(doubledollarjs.com)
doubledollarjs.com
DoubleDollarJS.com
http://doubledollarjs.com/
52 comments
The author here. This project was not ready for public release or review. Examples and docs need to be created etc. Should have been behind a firewall. Thanks for all your feedback.
What exactly is the reasoning behind embedding a bunch of HTML as template strings? Wouldn't it make way more sense to separate those out?
Why would one choose something like this over Angular or Ember?
Why would one choose something like this over Angular or Ember?
=) well, live it up and go ahead and use this as a platform for your ideas – I'm sure many would like to hear about it/your plans for it in greater detail, if you're so inclined.
I can't get passed the way the code is formatted.
Please just write it the way people normally write JavaScript:
$$ ({
home: {
route: {
defaultOnly : true
}
}
})
$$
home:
route:
defaultOnly: true
Taste is subjective. I write my JS pretty much the way DoubleDollar does. Of course, CoffeeScript makes it moot. :)
Geez, a lot of jerks on HN today. jv22222, thanks for making this. You're obviously putting a lot of work into it. I can't say that it particularly interests me at this point, but I'm glad that you and people like you work hard on things and open-source them.
[deleted]
Is this a parody? I'm genuinely having trouble discerning.
Nope, it's been developed by Justin Vincent of the TechZing podcast.
He spent about five minutes on the latest show explaining it... but frankly I still have no clue what it is.
He spent about five minutes on the latest show explaining it... but frankly I still have no clue what it is.
It's awesome. Really, I love it.
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 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 $$!
JS Devs - I think if you can open up your minds and take a look at what is actually a new and interesting approach to a JS framework, you'll be glad you did. Take a look at the examples. There's definitely some potential with this one.
Not to be harsh, but can you give an explanation/argument that includes substantive reasons for why there's potential?
The above seems awfully close to a dogmatic sort of "if you don't get it, the fault is with you" kind of statement.
The above seems awfully close to a dogmatic sort of "if you don't get it, the fault is with you" kind of statement.
There is potential because it is very simple to set up and works for the small tasks. I developed something similar a couple years ago called Jig.js (I've since pulled it offline and relegated it to small internal apps, and also quick browser-based presentations) because I wanted to be able to easily throw together quick apps, only having to include one <6kb (uncompressed!) JS file with no dependencies.
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).
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).
> People shouldn't be so harsh to independent authors.
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.
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.
That's fine, but there's a difference between a critique and a flame. There are an awful lot of flames in this thread. Also, as Hegel says, anything that exists is reasonable, and an "unreasonable" reason for not releasing code is still a valid one.
In any case, my main reason for withholding things is the "guilt" factor I mention at the end of my previous comment.
In any case, my main reason for withholding things is the "guilt" factor I mention at the end of my previous comment.
Lately I've seen a couple people refer to Backbone as "heavy," which I just don't understand, as it seems about as lightweight as possible for the functionality it provides. Could you explain what you mean?
Well, that's the thing, it provides more functionality than many people need, and requires more code than should be needed for some small projects.
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.
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.
I'm curious as to why numerous JS frameworks create DOM structure via string concatenation, or by putting markup in script tags. That's an automatic fail, in my books. No matter how interesting or useful a JS framework looks, I just can't get past the need to mix markup and code.
The script-markup mixture used by DoubleDollar or Backbone is really just a necessary quirk to achieve templating functionality. I haven't seen it done better honestly.
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!
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!
Thanks. I do build very JS heavy single-page web apps. Where I work we separate markup from code completely, and use MVVM to glue the things together. I've given an example above in reply to another comment.
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!
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!
Plates has separated markup and function very well, IMHO
https://github.com/flatiron/plates
>I'm curious as to why numerous JS frameworks create DOM structure via string concatenation,
Probably because of this: http://jsperf.com/string-concatenation-vs-the-dom
Probably because of this: http://jsperf.com/string-concatenation-vs-the-dom
Nice benchmark, but it misses the point.
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):
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!
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!
The entire thing doesn't work in Linux/Chromium
$$.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 :I'm having trouble understanding what the framework offers. Though I appreciate seeing code quickly, I'd like a better overview of what it does.
Same here. It looks like a loader plus some extensions that offer routing, and history/back/forward management plus a lot of conventions.
A comparison of what it offers compared to at least a couple of the major libraries offering those things would've been useful...
A comparison of what it offers compared to at least a couple of the major libraries offering those things would've been useful...
I can't imagine writing in that, just... so much whitespace.
It follows Allman style of indentation:
http://doubledollarjs.com/#convention
http://en.wikipedia.org/wiki/Indent_style#Allman_style
http://doubledollarjs.com/#convention
http://en.wikipedia.org/wiki/Indent_style#Allman_style
I hate when people choose a standard that has cases where it shouldn't be followed. See the return semicolon injection JS bug/feature.
I roll with BSD KNF across all of my brace-based langs.
I roll with BSD KNF across all of my brace-based langs.
It breaks returning object literals because `return` on its own line is a complete statement.
Whenever I come across Allman style indenting, I get an overwhelming urge to run "indent"....
when I absolutely must be bothered to use braces at all "one true brace" is the ONLY way to roll :-)
Or in this case just use coffeescript and rejoice.
Or in this case just use coffeescript and rejoice.
In Chrome/Chromium, $$() is a shortcut for document.querySelectorAll().
Only in the Webkit Inspector console, nowhere else. $ is also a shortcut (I forget for what though).
They're over-written by a page if that page defines that variable globally in some way.
They're over-written by a page if that page defines that variable globally in some way.
It is also used by prototype.js - http://api.prototypejs.org/dom/dollar-dollar/
While the visual style of the code may be perplexing to most of us, I imagine it might make javascript far easier for a dyslexic person to read.
Hm, this is a very particular way of working with Javascript. The formatting is very strange.
Its... I... um... Why?
Another day, another ho-hum JS doo-hicky thing-a-ma-jigger...