
Maquette – Pure and simple virtual DOM library - tilt
http://maquettejs.org/
======
yladiz
So with these virtual DOM libraries, after seeing a lot of them try to fill in
this supposed niche, and seeing two this week including this one, I'm of the
opinion that it should either be completely JS looking, e.g. a simple wrapper
around createElement, or React looking, e.g. with JSX.

The ones that are in between, while potentially having nice syntax or a nice
looking homepage, aren't enough to convince me to use them over React, mainly
because 1) if I'm doing any production code, I want other engineers to be
familiar with it and its pitfalls; 2) I want to make sure it'll be supported 6
months down the road; 3) engineers are familiar enough with JSX or with
createElement, but some other syntax may be confusing and have corner cases
that a bigger project like React hasn't thought of... I don't want a lookalike
React.createElement because I can just use React.createElement; 4) many of
these libraries are built with "performance" in mind, but does it really
matter how many more times it can process a ToDoApp if it doesn't really
affect user facing performance?

While this isn't a jab at this library specifically (although it hasn't had
much _substantial_ development in a while...), but too many libraries are
created to fill some supposed niche and then abandoned when they move to
different pastures, and if you need to fix any of those corner cases you will
inevitably run into, ideally you can submit a PR and get it fixed easily and
with little delay.

~~~
hashkb
I'm interested in tools like this because it allows me to build my front-end
out of regular functions, which I can compose however I want using regular
code. I never liked writing HTML or CSS in the first place.

~~~
yladiz
Barring adding a build step, why couldn't you compose a function that returns
JSX?

~~~
__derek__
Or just skip JSX and use ReactDOM directly.[1] JSX is just sugar for the
functions underneath, after all.

[1]: [https://facebook.github.io/react/docs/top-level-
api.html#rea...](https://facebook.github.io/react/docs/top-level-
api.html#reactdom)

~~~
hashkb
Isn't that a lot like hyperscript? Maybe I like this or mercury or I one of
the other varieties better for one reason or another. Is ReactDOM the best fit
for everyone?

~~~
__derek__
I've never used HyperScript, and I made no claims about anything being the ONE
TRUE TOOL. I suggested that yladiz's recommendation would fit your described
preferences better without injecting JSX.

------
doublerebel
I really dig Maquette. The library is easy to use, the documentation is good,
and the interactive examples make it really easy to get running.

The Hyperscript notation Maquette uses is compatible with other vDOM
implementations, so it's possible to use JSX [1], Jade/Pug [2], Handlebars, or
any other templating solution that compiles to Hyperscript [3].

I personally prefer really "dumb" views and have my controllers attach events
and link model data. Thanks to the modular design of Maquette, instead of the
Maquette `createRender()` pattern I was able to use SpineJS for the Model and
Controller portions of the app.

I used Maquette recently to create an API and Web UI for Bull job queue, which
I'll be releasing this week as open-source. I did not run into any bugs or
difficulties in Maquette, it was as efficient and straightforward as
advertised.

Previously I've used Templatizer (precompiled Jade templates), but Maquette's
feature to map and track lists of objects/elements spurred me to change. I'm
sold on it for now but really appreciate the thriving competition of vDOM
renderers.

[1]: [https://medium.com/maquette-news/maquette-2-2-now-
supports-j...](https://medium.com/maquette-news/maquette-2-2-now-supports-
jsx-7da7b0a1dc98#.s2tmxyyce)

[2]: [https://www.npmjs.com/package/gulp-pug-
hyperscript](https://www.npmjs.com/package/gulp-pug-hyperscript)

[3]:
[https://www.npmjs.com/browse/keyword/hyperscript](https://www.npmjs.com/browse/keyword/hyperscript)

------
dimgl
I find the virtual DOM is much easier to create using regular HTML syntax. I
like Vue 2.0's approach where it creates a virtual DOM from the actual DOM
itself.

Edit: I left a huge comment regarding POJOs and how the example on the
homepage is pretty ugly, but I just found out that there's something called
Hyperscript, and it's used to create a virtual DOM. So, while the example is
in Hyperscript, Maquette also supports JSX.

I still don't understand the point of all of this I guess. Isn't it time we as
JavaScript devs took a step back and thought "why do we need this?"

~~~
nine_k
> _«why do we need this?»_

Obviously, because real DOM is (1) slow and prone to hard-to-predict reflows,
(2) non-transactional, and (3) not going to change, due to backwards
compatibility.

Thus the need to operate on a fast, cheap virtual DOM, and then apply the
smallest sufficient change to the real DOM the users see.

------
artf
Please add 'width: 100%;' to your '.homepage .row' CSS rule. In Firefox I see
an annoying scollbar on bottom of the page

~~~
incubes
Thanks for reporting. I just added it to the sheet!

------
Etheryte
_" Maquette is a virtual DOM implementation that excels in speed."_ Waiting
for some data to back that claim.

~~~
tilt
Here is a Benchmark tool [https://vdom-benchmark.github.io/vdom-
benchmark/](https://vdom-benchmark.github.io/vdom-benchmark/)

where you can input this "Custom URL": [https://vdom-benchmark.github.io/vdom-
benchmark-maquette/](https://vdom-benchmark.github.io/vdom-benchmark-
maquette/)

then open the Dev Tools and Run.

But looks like it fails tests, add '&test' to the URL in the new window.

Source:
[https://twitter.com/andrestaltz/status/770307344513306624](https://twitter.com/andrestaltz/status/770307344513306624)

~~~
johangorter
The main conclusion from this benchmark was that all 'modern' virtual DOM
implementations are all capable of achieving 60fps on large pages on most
devices. There is no point in picking the 'fastest' anymore, because users
simply will not see the difference.

------
qwertyuiop924
So... it's mithril with a ton of the useful stuff ripped out, for a
comparatively tiny reduction in size? Why would I want that?

~~~
erikpukinskis
There is something to be said for using APIs whose total surface area is close
to the surface area that you need. If I want to use different parts of three
libraries, but those libraries have excess functionality with a lot of
overlap, then I have to deal with potentially conflicting expectations. I also
have to worry that the subset of functionality I do use will go away or change
because it's not the central focus of the library.

~~~
qwertyuiop924
The thing is, if you're using a VDOM, you'll probably want the other stuff
Mithril's got anyways. And the tight integration with the vdom renderer helps
make sure that rerenders happen only when something actually changes, and that
partial states don't render. For 3 megs, I'll take it.

~~~
erikpukinskis
One man's tight integration is another man's tight coupling.

~~~
qwertyuiop924
You can actually disable a lot of that stuff. It's just like that by default.
You can even write your own render loop, if you really want to.

------
atmin
I created something similar recently, but more minimalistic, es6/jsx-
encouraging and based on the real DOM (via morphdom).

[https://atmin.github.io/funponent/](https://atmin.github.io/funponent/)

------
boubiyeah
Looks well put; not sure just yet what it adds to the scene compared to
snabbdom.

------
maxencecornet
Site design is gorgeous

------
erwinkle
Love the site design, but will never use the library

