3 ms·

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

• epidemian 10y ago
  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.js https://github.com/monkberry/monkberry/blob/master/monkberry... [2] https://github.com/monkberry/monkberry/tree/master/src https://github.com/monkberry/monkberry/tree/master/src
• hitr 10y ago
  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/ 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 .
  • lhorie 10y ago
    I asked the author if he could put together a dbmon so we could compare apples to apples. Unfortunately, React is not a good representative of modern virtual dom overhead/performance. On dbmon, React is somewhere between one and two order of magnitudes slower than many virtual dom libraries (e.g. mithril rewrite, inferno, kivi), with render times in the 60-100ms range (vs 2-10ms range for the other libs), and proportionally similar results in vdom benchmark. As far as I could see, Monkberry doesn't implement the search space reduction algorithm that the libraries above do, and uses only mapped reordering, so I'm curious if its compilation+mapped reordering combo can outperform search space reduction w/ a virtual dom overhead. Anyways, regardless of how well it does against vdom libs that do take advantage of hidden classes etc, I really like the execution of this project.