6 ms·

Maquette – Pure and simple virtual DOM library

79 points by tilt 10y ago

yladiz 10y ago
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 10y ago
  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 10y ago
    Barring adding a build step, why couldn't you compose a function that returns JSX?
    - __derek__ 10y ago
      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#reactdom https://facebook.github.io/react/docs/top-level-api.html#rea...
      - hashkb 10y ago
        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?
        deleted 10y ago
        [deleted]
        __derek__ 10y ago
        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.
  - cies 10y ago
    > I never liked writing HTML or CSS in the first place I also did not like the split between code and markup and or style. > build my front-end out of regular functions, which I can compose however I want using regular code Yes, me too! I want to share what I found. PureScript. Has some nice libs like Thermite (React under the hood) and Halogen (no React, plain PureScript, cleaner). And much more then these two... Elm. Has the batteries included. Nice lib in this language is elm-css, which makes CSS/HTML styling symbols typesafe! GHCJS. The heavy weight. Compiles Haskell to JS (Elm and PureScript merely inspired by Haskell). Coming along quite well, may not be very ready for production. Lots of interesting libraries. Big lib here is Reflex.
- joshontheweb 10y ago
  Do you have a library outside of React that you would recommend?
qwertyuiop924 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      One man's tight integration is another man's tight coupling.
      - qwertyuiop924 10y ago
        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.
- johangorter 10y ago
  We wouldn't have created Maquette if Mithril supported animated transitions (in an unobtrusive manner). So that is the real difference.
Etheryte 10y ago
"Maquette is a virtual DOM implementation that excels in speed." Waiting for some data to back that claim.
- tilt 10y ago
  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
  - Etheryte 10y ago
    The first line on the page reads: "This benchmark has some serious flaws, and the only thing that it tests is a children reconciliation algorithm." Not exactly something to base an opinion on.
  - johangorter 10y ago
    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.
- Geee 10y ago
  https://localvoid.github.io/uibench/ https://localvoid.github.io/uibench/ I think Inferno should be fastest in most cases.
  - localvoid 10y ago
    uibench results on Chrome 54 with full render time and disabled sCU: https://cdn.rawgit.com/localvoid/6715c4b23eadc460112e671b4add3710/raw/907901966dd0473f1026d1ff25e244a022eb5ab1/uibench_results.html https://cdn.rawgit.com/localvoid/6715c4b23eadc460112e671b4ad...
dimgl 10y ago
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 10y ago
  > «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.
erwinkle 10y ago
Love the site design, but will never use the library
doublerebel 10y ago
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-jsx-7da7b0a1dc98#.s2tmxyyce https://medium.com/maquette-news/maquette-2-2-now-supports-j... [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
artf 10y ago
Please add 'width: 100%;' to your '.homepage .row' CSS rule. In Firefox I see an annoying scollbar on bottom of the page
- incubes 10y ago
  Thanks for reporting. I just added it to the sheet!
marcfawzi 10y ago
this is ripping off hyperscript h(...) syntax without giving credit? https://github.com/dominictarr/hyperscript https://github.com/dominictarr/hyperscript
boubiyeah 10y ago
Looks well put; not sure just yet what it adds to the scene compared to snabbdom.
maxencecornet 10y ago
Site design is gorgeous
atmin 10y ago
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/

79 points by tilt 10y ago

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 10y ago
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 10y ago
  Barring adding a build step, why couldn't you compose a function that returns JSX?
  - __derek__ 10y ago
    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#reactdom https://facebook.github.io/react/docs/top-level-api.html#rea...
    - hashkb 10y ago
      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?
      - deleted 10y ago
        [deleted]
      - __derek__ 10y ago
        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.
- cies 10y ago
  > I never liked writing HTML or CSS in the first place I also did not like the split between code and markup and or style. > build my front-end out of regular functions, which I can compose however I want using regular code Yes, me too! I want to share what I found. PureScript. Has some nice libs like Thermite (React under the hood) and Halogen (no React, plain PureScript, cleaner). And much more then these two... Elm. Has the batteries included. Nice lib in this language is elm-css, which makes CSS/HTML styling symbols typesafe! GHCJS. The heavy weight. Compiles Haskell to JS (Elm and PureScript merely inspired by Haskell). Coming along quite well, may not be very ready for production. Lots of interesting libraries. Big lib here is Reflex.
joshontheweb 10y ago
Do you have a library outside of React that you would recommend?

qwertyuiop924 10y ago

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 10y ago
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 10y ago
  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 10y ago
    One man's tight integration is another man's tight coupling.
    - qwertyuiop924 10y ago
      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.
johangorter 10y ago
We wouldn't have created Maquette if Mithril supported animated transitions (in an unobtrusive manner). So that is the real difference.

Etheryte 10y ago

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

tilt 10y ago
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
- Etheryte 10y ago
  The first line on the page reads: "This benchmark has some serious flaws, and the only thing that it tests is a children reconciliation algorithm." Not exactly something to base an opinion on.
- johangorter 10y ago
  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.
Geee 10y ago
https://localvoid.github.io/uibench/ https://localvoid.github.io/uibench/ I think Inferno should be fastest in most cases.
- localvoid 10y ago
  uibench results on Chrome 54 with full render time and disabled sCU: https://cdn.rawgit.com/localvoid/6715c4b23eadc460112e671b4add3710/raw/907901966dd0473f1026d1ff25e244a022eb5ab1/uibench_results.html https://cdn.rawgit.com/localvoid/6715c4b23eadc460112e671b4ad...

dimgl 10y ago

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 10y ago
> «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.

erwinkle 10y ago

Love the site design, but will never use the library

doublerebel 10y ago

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-jsx-7da7b0a1dc98#.s2tmxyyce https://medium.com/maquette-news/maquette-2-2-now-supports-j... [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

artf 10y ago

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

incubes 10y ago
Thanks for reporting. I just added it to the sheet!

marcfawzi 10y ago

this is ripping off hyperscript h(...) syntax without giving credit? https://github.com/dominictarr/hyperscript https://github.com/dominictarr/hyperscript

boubiyeah 10y ago

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

maxencecornet 10y ago

Site design is gorgeous

atmin 10y ago

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/