Comparing your CoffeeScript example against a vanilla JS React example seems cheap. here's the front page React example in CS:<p><pre><code> converter = new Showdown.converter()
MarkdownEditor = React.createClass
getInitialState: () -> value: 'Type some *markdown* here!'
handleChange: (e) -> @setState(value: e.target.value)
render: () ->
d = React.DOM
d.div(
d.h3(null, 'Input'),
d.textarea(onChange: @handleChange, value: @state.value),
d.h3(null, 'Output'),
d.div(dangerouslySetInnerHTML: __html: converter.makeHtml(@state.value))
)
React.renderComponent MarkdownEditor(), document.querySelector('.container')
</code></pre>
Showing a LOC comparison (and not even from the same dialect of a language) isn't a good proof for what you're trying to demonstrate. Clarity, simplicity, and debuggability all count. Removing a few extra lines of (non-boilerplate) code compared to React doesn't make the library simpler to work with.
Oh, I thought this was the already existing Hamlet language.<p>Of which there are at least two.<p><a href="http://www.yesodweb.com/book/shakespearean-templates" rel="nofollow">http://www.yesodweb.com/book/shakespearean-templates</a><p><a href="https://github.com/gregwebs/hamlet.rb" rel="nofollow">https://github.com/gregwebs/hamlet.rb</a><p>It does look pretty cool though.
An unfortunate choice of name. When I saw the title, I thought it was on about <a href="https://hackage.haskell.org/package/hamlet" rel="nofollow">https://hackage.haskell.org/package/hamlet</a>
We use hamlc and Backbone.js in our stack. This lib looks like it will simplify a lot of that.<p>I have a few questions:<p>1. Its interesting to see JS events specified in the template (e.g. `%a(onclick=@doSomething)`). Is there a way to specify that in the JS/model?<p>2. Does "Observable" mean that the value is updated when the model changes, when the DOM changes, or both? Could all of the attributes of the object passed into the template be observable by default or would that incur a significant performance penalty?
> Avoid working with over-engineered frameworks without sacrificing a great interactive experience<p>This is a pretty lame claim seeing as text fields are busted in Hamlet. [1]<p>This is another example of a "lightweight" library that hasn't hit any of the hard problems yet. It's fine if you make this your personal project to learn from, but trying to convince people to bet their projects on unproven technology is pretty disingenuous.<p>[1] Inserting characters does not work in the second example at <a href="http://hamlet.coffee/garden/" rel="nofollow">http://hamlet.coffee/garden/</a>
I've really enjoyed ractive. Simple to learn, with mustaches, and it has worked really well for our project. No extra compile steps. Figured I'd share since I see alot of buzz around React and other things, and preferred ractive.js when I researched it a little bit ago.
Reactivity is becoming an imperative. The browser of the future will let us code in a reactive language instead of forcing non reactive html or js on us. I'd love to see something simple for other languages and platforms as well.<p>I love that it seems to not be tied to node out of the box as well.
This looks to be a great declarative/reactive template engine. I've been working mostly with the Meteor Blaze template engine the last few months. Both of them use a "normal" template language for writing views and (potentially) let you choose if you prefer writing your templates in Handlebars, Jade, or Haml [0], which I find far more easy to use than React JSX format. I think
Blaze beats Hamlet on the runtime rendering engine.<p>First, Blaze does not require to set a root element in a template, which could be a source of bugs with Hamlet because for instance the `each` child is a template, here is a snippet of problematic example from the Hamlet README:<p><pre><code> - each @items, ->
.first
.second
</code></pre>
This works perfectly fine in Blaze. IIRC Blaze uses comments node on the DOM that are never rendered in browsers in order to define some "domrange" that keep track of n children in a single parent group.<p>The second runtime issue in Hamlet appears when a third-party library directly modifies the DOM, without telling the template engine. Basically the modification will be erased on the next template redraw which make this system incompatible with all jQuery plugins for instance. Blaze has "fined grained DOM updates" which mean that the modification of a single element in a template does not require to touch any other node in the DOM. For instance if you have a each loop of inputs, and the user start to enter some data in one input field, and for some reason the template is redrawn the text will stay in the input with Blaze, but will be erased with Hamlet.<p>Blaze also support reactive SVG (I'm not sure if Hamlet supports it but I haven't seen any particular mention in the code).<p>I think all of these features can be implemented in Hamlet drawing on Blaze and ReactJS runtimes.<p>Nevertheless I find the Javascript model declaration cleaner in Hamlet than in Blaze or Backbone or React. The only thing I'm not sure about is writing the js events in the template and not in the model, I actually like having all events of a given template in a single place but I don't have strong opinion on this.<p>[0]: Meteor support Spacebars (which is quite similar to Handlebars) by default <a href="https://github.com/meteor/meteor/blob/devel/packages/spacebars/README.md" rel="nofollow">https://github.com/meteor/meteor/blob/devel/packages/spaceba...</a>, and there is also a package for jade <a href="https://github.com/mquandalle/meteor-jade" rel="nofollow">https://github.com/mquandalle/meteor-jade</a> (disclaimer: I'm the author). It also seems that it wouldn't be difficult to support other languages than Haml for Hamlet.