Show HN: Monkberry – a JavaScript library for building web user interfaces

[3D4y0]

OT: Can somebody please tell em, to stop the excessive use of css animations(the moving star field background). It pegs one of my cores, and raises my laptops temperature to the point where i can feel it. Worse still, it really adds nothing to the ability to peruse information, if anything I find it distracting! </rant>

[lucideer]

Given this is a website by someone purporting to be providing a "blazingly fast" JS UI lib, comments on UI perf. seem pretty on-topic.

Given the general lack of info on the site about why one should choose this library over others (beyond reiterating that it's "blazingly fast"), a showcase of one's claims of speed should be a pretty important aspect of the site.

This is not to criticise the library itself, but these kinds of first impressions are significant.

[wtf_srsly]

I think it isn't the animation itself but the blatant abuse of box-shadow to create all the stars. Using an image for example should greatly reduce the required performance.

[cel1ne]

Or code it is as a vertex-shader to run on the GPU.

https://aerotwist.com/tutorials/an-introduction-to-shaders-p...

[christophilus]

Yeah. It's annoying. Just go straight to the GH page:

https://github.com/monkberry/monkberry

Looks like a pretty good lib, actually.

[pygy_]

The background is in its own div with classeslike "stars"and "js-stars", just before the footer. You can delete the div using the DOM inspector to remove them.

[lhorie]

Damn, so much negativity. This library actually looks well designed (and I'm saying this as a virtual dom library author)

[epidemian]

Absolutely! I started a comment yesterday about what i found interesting skimming through the code of this library, but abandoned midways because i could almost see the snarky "oh, so just another templating library" response.

Too be fair, that response would be somewhat justified. After all, the code of the client-side library is so small[1] because it doesn't actually do much there. And that is in fact what i find interesting in comparison to other client-side rendering libraries like React (or Mithril ;).

There's quite a lot more code in the repo though[2], and that has to do with the processing of the view files, and compiling them to plain JS functions at build time. These plain JS, however, are not like most JS functions generated by templating engines, which usually involve generating a bunch of HTML (taking care to escape text as necessary) and then inserting into the DOM via `innerHTML` or a similar method. Monkberry actually parses the HTML bits of the templates and generates functions that construct the DOM using the JS DOM API. For the example on the homepage, it generates code similar to (you can see this on the browser devtools just by visiting that page):

  // Create elements
  var li0 = document.createElement('li');
  var input1 = document.createElement('input');
  ...
  // Construct dom
  input1.setAttribute("type", "checkbox")
  li0.appendChild(input1);
	
  // Update functions
  this.__update__ = {
    todo: function (todo) {
      var result;
      input1.checked = todo.complete;
      ...
    },
    ...
  }

Notice that the DOM elements are themselves cached and re-used each time the view is updated. And the update function does very direct stuff like setting `input.checked = todo.complete`.

TL;DR: seems like a solid library. Interesting idea and good execution.

[1] https://github.com/monkberry/monkberry/blob/master/monkberry... [2] https://github.com/monkberry/monkberry/tree/master/src

[hitr]

Actually a clean library .Github has more details on why it is faster than React >Monkberry is 10 times faster, sometimes 100 times faster. It's because Monkberry will do only necessary dom updates, and does it in a completely different way than React does. Monkberry compiles template to plain JavaScript to gain an advantage by using v8 hidden classes and reduce call stack. There is no virtual dom (in general, an react app have to keep 3 virtual doms), for example next template will be generated to JavaScript code which will do only necessary dom updates on state changes.

and also some benchmarks comparing against it. http://monkberry.js.org/benchmark/

I always enjoy reading why someone developed new library or tool because they wanted to improve something about a library they were using.It may not be a big thing but it surely gives one or two flaws about your favorite library you are so fond of .

[_qbjt]

Just some advice, that star animation slows the page to an incredibly sluggish state (latest Chrome on late 2013 retina MacBook Pro). Removing the `stars` and `js-stars` classes from the main div speeds the page up significantly and conveys the "blazingly fast" point more effectively.

[shash7]

Ah so its a templating engine.

[maxpert]

I think it's kinda MVC not full but good for micro projects where you want a clean code but not a bloated framework :D

[Kred]

This first thing I thought to compare this to was VueJS. It seems like the next step up if you were to need a bit more from your framework. Or is this an unfair comparison?

[voiper1]

I'm using riotjs (http://www.riotjs.com) which is closer to this than React, but it's "standard" HTML templates with controllers _with_ the template so all relevant code is together. (When I see react's complete divergence from HTML I get really worried...)

It's about 9kb gzipped, so it's 9x bigger, but does much more than Monkberry.

[datashaman]

This looks like it belongs on http://microjs.com. Instructions in the footer.

[ruler88]

what problem does this library solve that reactjs does not solve?

[ch4s3]

Being 1kb. Not to be pedantic, but 147kb is a lot on a crappy connection, so if you have users in rural places with slow internet or tiny data caps, a small library like this may be useful.

[vortico]

React minified is 147kb, which is actually significant if all you need is the functionality offered in Monkberry.

[snissn]

What problem does reactjs solve? Why are javascript libraries used instead of generating HTML server side? I feel I'm out of touch, could someone give me a quick primer?

[sesm]

This library uses two-way data binding like angular, vue.js and many others. Two-way data binding libraries/frameworks are easier to use on small websites, but don't scale well to large single page applications.

[lizardskull]

A more awesome name

[gldev]

The site presenting it has issues but the library itself seems pretty decent. Keep it up man.

[atmin]

I did something quite similar couple years ago [jtmpl.com].

Main difference is Monkberry uses Jinja-inspired templating language and jtmpl uses Mustache (with slightly changed semantics, so, for example, a partial can be dynamically requested via XHR). jtmpl is a bit bigger and provides a bit more features.

[gnuchu]

In the example

<button type="submit">Add #{{ todos.length }}</button>

should probably be

<button type="submit">Add #{{ todos.length + 1 }}</button>

:-)

[smegel]

Those checkboxes respond with noticeable delay. I hope that is more to do with the website than the library.

[Rapzid]

Love Phuket. This looks pretty cool too :)

[geekodour]

What it can do that VanillaJs can't?

[bpicolo]

Good abstractions help people build better software, faster. This is universally true, not just in the world of JS.

[sesm]

Two-way data binding.

[geekodour]

better organization i see