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.
=) 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
}
}
})
Or in CoffeeScript:
$$
home:
route:
defaultOnly: true
Other than that, this is sort of interesting. Reminds me of Couch Apps, which I could never get the hang of and eventually had to stop messing with. Everything is declared according to a specific structure, but its hard to figure out what structure you are supposed to use for a given task. High learning curve and difficult translation from imperative thought to this type of patterned declaration.
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.
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.
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.
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.
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.
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.
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!
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!
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);
});
$$.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 :
