Show HN: EndDash

http://www.enddash.com/

by sethbannon • 13 years ago

65 6 13 years ago

enddash.com

kumarski• 13 years ago

Cool stuff.

Thanks for open sourcing.

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

woodhull• 13 years ago

How does this compare with Epoxy for Backbone.js?

devhinton3• 13 years ago

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 :)

ianstormtaylor• 13 years ago

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 [2]: https://github.com/ianstormtaylor/get

devhinton3• 13 years ago

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:

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...

This does exactly that.

Thanks, from Amicus

devhinton3• 13 years ago

On further reflection,

It is also true that reactive does not have any support for collections or scoping. Reactive seems to take a view-centric approach while EndDash takes a template-centric approach. To us, the later seems more logical, as HTML is the structure of any webpage.

EndDash hooks into this structure and acts as an optimization so that HTML turns into a high level description of html/views/value interpolation. Thus defining a large template (with partials if needed) can be passed a single javascript model which is scoped down into. Passing models to views as needed.

Again, thank you for the comment :)

From Amicus.

Show HN: EndDash

Related Stories