

Show HN: EndDash - sethbannon
http://www.enddash.com/

======
ianstormtaylor
It seems like this library is just a less well-thought out version of
component/reactive[1]. It makes the mistake of jamming way too much logic into
magicky strings instead of using existing semantics to render things. For
example, there's a

    
    
      data-each
    

attribute for handling looping, but then instead of solving polymorphic
children in the same way, with a

    
    
      data-polymorphic="role"
    

attribute, it's solved with a weirdly hacky appending of "Polymorphic-" to a
class name.

The same goes for the use of class names to begin with. Why rely on hacky
parsing of class names that end in dashes, when you could just have

    
    
      data-text="firstName"
    

and be done with it. That's the route reactive takes and it's much more
flexible.

And then another piece of critique, the frequency that people actually use
curly braces in their attribute names is so incredibly low that it is
absolutely worth having a nicer syntax for interpolation by dropping the
leading # to end up with

    
    
      href="{interpolated}"
    

Not only that, but check out something like ianstormtaylor/get[2] to see how
easy it could be to add support for backbone-like models alongside regular
properties and terser, single-method models.

And finally, the API for creating a reactive instance is also much nicer in
that you aren't relying on ever-present singletons that you have to tightly
couple all of your modules to. Instead, you just get your template however you
want, get your model however you want and call:

    
    
      reactive(el, model);
    

Very clean.

Sorry if this comes off as harsh, I just think it's a shame that people using
Backbone (or more frequently Angular) are constantly making poor API decisions
for their plugins because they're exposed to so many poor API decisions in
their core toolkit.

[1]:
[https://github.com/component/reactive](https://github.com/component/reactive)
[2]:
[https://github.com/ianstormtaylor/get](https://github.com/ianstormtaylor/get)

~~~
devhinton
Agreed, thanks for the feedback, and, after having worked with end-dash I've
come to a lot of the same conclusions you just made.

The dashes were initially just to shorten the common:

<div class="thing" data-text="thing"></div> to <div class="thing-"></div>

Using dashes for polymorphic attributes was a bad idea, and is being removed,
the data-each was recently added to replace a dashed syntax for collections.
We're adding interpolated variables, so that the dash syntax will only be used
for scoping.

> Not only that, but check out something like ianstormtaylor/get[2] to see how
> easy it could be to add support for backbone-like models alongside regular
> properties and terser, single-method models.

[https://github.com/Amicus/end-
dash/blob/master/lib/util.js#L...](https://github.com/Amicus/end-
dash/blob/master/lib/util.js#L67)

This does exactly that.

Thanks, from Amicus

------
kumarski
Cool stuff.

Thanks for open sourcing.

One small comment, the scroll bar on the left appears unusually thin/it looks
cut off.

------
woodhull
How does this compare with Epoxy for Backbone.js?

~~~
devhinton
We prefer to have the values only defined in one place. In Epoxy.js, looking
at the getting started example, it appears the value firstName is indicated
both in the JS and in the HTML. In EndDash, this would only need to be done in
the HTML with '<input class="firstName-" />'

In addition, when dealing with views, there is no need to extend
Backbone.Views as Epoxy does. Instead, simply add data-view="myView" to the
desired 'el' of that view. The js object in scope will be automatically passed
in as well.

I am sure there are more differences but from a first take this is what I
notice. Would be interested to hear your take as well :)

From Amicus :)

