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