
Deku: How we built our functional alternative to React - gwintrob
https://segment.com/blog/deku-our-functional-alternative-to-react/
======
DigitalSea
Great work guys, but correct me if I am wrong but it seems the reasons you
decided to build Deku (if I am understanding what you have written) did not
seem to be anything other than you were not a fan of how React doesn't take a
completely functional approach to building components. Is that an appropriate
assumption to make based on what you have written in your article?

I feel a little disappointed to be honest. Because as I was reading, I was
expecting to read that you somehow had created a dom-diffing algorithm and
matching library that was more performant than React.js, but really it just
came down to the fact you didn't like how React.js looks. I was rooting for
you from the beginning, expecting to see someone had created something
superior to the much hyped React, but it didn't happen.

I don't want to hate on what you've done, looking through the code reveals
that you put some considerable effort into Deku, but it makes me wonder if
that effort could have been spent on perhaps learning the inner-workings of
React.js and adapting it to your needs in its own fork. But having said that,
Deku to me only has a few slight differences to React.js, the way components
are built in Deku in comparison to React.js doesn't appear to be that
dramatically different.

I don't want this comment to come across as yet another cynical HN commenter,
but I just cannot see anything comprehensively different to existing
solutions. I hate seeing talented development hours going to waste that could
have been used to make an already existing project better.

~~~
jeswin
> Deku to me only has a few slight differences to React.js

This framework is genuinely different from React in how you use it. I know
several JS programmers who prefer functional style, yet choose to incorporate
React-style classes because React is really good at what it does. This gives
them an alternative.

The components built with Deku will be different in programming style. And
that's really, really significant.

~~~
fiatjaf
[https://github.com/Matt-Esch/virtual-dom/](https://github.com/Matt-
Esch/virtual-dom/)

~~~
malandrew
virtual-dom is excellent.

Also check out mercury:

[https://github.com/Raynos/mercury](https://github.com/Raynos/mercury)

Or better yet, fork mercury and modify the index.js file and package.json.
It's a bunch of libraries masquarading as a framework (which is awesome
because it means it's modular instead of monolithic)

~~~
fiatjaf
What do you say about
[https://news.ycombinator.com/item?id=9529457](https://news.ycombinator.com/item?id=9529457)?

------
jeswin
Excellent work. I just went through the source code; lean and neat. I am going
to offer this as an alternative to React in something I'm building.

To the new-to-JS programmers out here, I'd recommend waiting until a framework
reaches a certain level of maturity. React is not just about the core library
itself, it is also about the tooling and ecosystem. For example, you can use
React dev tools in Chrome. You are more likely to find how-tos and
documentation if you're using React. React Native might help with sharing code
if native mobile is in your plans.

Like the documentation says, what this framework really gives you is the
ability to skip the OO-style coding that React mandates, and use just
functions and modules.

------
fiatjaf
> So we looked for smaller alternatives, like virtual-dom and mercury. The
> documentation for virtual-dom was slim and we didn’t think the API for
> mercury was very user friendly.

Really? You found that it was better to write everything from scratch instead
of modifying mercury for your use (thus making use of the very good virtual-
dom library)? Do you know that the whole mercury source code[1] is only 126
lines of code?

Perhaps you should also know that your library usage examples, in the end,
look just like mercury usage examples.

[1]:
[https://github.com/Raynos/mercury/blob/master/index.js](https://github.com/Raynos/mercury/blob/master/index.js)

~~~
jaltekruse
I think that you are pointing at the wrong file, it looks like the library is
actually around 4k lines. The point may still be valid, but it was not a
trivial codebase to fork and they seem to have some architectural goals that
they didn't think any of the current libraries were well suited to work with.

[https://github.com/Raynos/mercury/blob/master/dist/mercury.j...](https://github.com/Raynos/mercury/blob/master/dist/mercury.js)

~~~
darklajid
Stumbled upon this [1] in their Readme:

 _mercury is lean, it 's an weekend's read at 2.5kloc. (virtual-dom is
1.1kloc, an evening's read.)_

1: [https://github.com/Raynos/mercury](https://github.com/Raynos/mercury)

~~~
tel
Having attempted to read virtual-dom several times I highly disagree with it
being an "evening's read". It is highly complex, idiosyncratic, has a number
of difficult to grok internal conventions, and at least a few large algorithms
with next to no documentation. I think a lot of people deservedly like it's
API, but it is far from an easy read.

------
jefftchan
What about Ripple.js [1] [2], which Segment also released ~1 year ago? Is that
dead now?

[1] [https://ripplejs.github.io](https://ripplejs.github.io) [2]
[https://news.ycombinator.com/item?id=7609816](https://news.ycombinator.com/item?id=7609816)

~~~
anthonyshort
We're still using it on some of our projects, but we've found that no matter
how simple we make data-binding it still leads to a mess of event bindings and
state management.

The original plan was to make a virtual dom plugin for ripple but it wasn't
really possible with the way the worked behind the scenes.

~~~
TheHippo
Last commit: Jul 30, 2014

------
kansface
| It’s also a lot of fun

The only cogent reason offered for writing yet another front end framework ...

~~~
calcsam
Proposed new shorthand: YAJF

~~~
mofle
YAFS - Yet Another Framework Syndrome.

[https://medium.com/@tastejs/yet-another-framework-
syndrome-y...](https://medium.com/@tastejs/yet-another-framework-syndrome-
yafs-cf5f694ee070)

------
dustingetz
How is this more "functional" than react? What do you mean by "functional"? I
write clojurescript for a living and I don't get it.

~~~
platz
It's an interesting question that I also had. After reading through,
apparently "functional" means "no concept of classes or use of this."

------
Meai
Those were exactlY my grievances with react as well i was practically hoping
somebody builds a smaller sane version of react. It could be cool if this
would use html / shadowdom components instead of jsx, but i havent checked out
the src yet (is there a link?)

------
droidist2
Cool. Are you going to make a Deku Native for mobile development?

------
nwmcsween
This seems very much like mercuryjs except less modular as per a quick glance.
What are the differences between mercuryjs and deku besides the need to
compile-to-dom in deku?

~~~
Touche
They didn't invent mercury.

------
davexunit
I really dislike JSX. Mixing HTML and JS is not elegant at all. Why is it so
popular now?

~~~
sls
I reflexively dislike the notion, but am trying to consider it with an open
mind. The notion that a subtree of the DOM and some JavaScript that
manipulates it, designed together to create a single functional component,
represent a single concern and should be packaged together, is not
unreasonable.

I think it is very different than the spaghetti pages found in jsps and php
pages of yore, and the emphasis on component is a big part of why.

~~~
visarga
I took the same route - instead of trying to keep HTML in one place, JS in
another, CSS in another I made separate files for each component including all
the necessary HTML, JS and CSS in one file. It makes more sense because I
write them together and debug them together. Also, I don't need to find where
are the CSS selectors in a huge monolithic CSS file, or the same about JS
functions. I don't let a component become too complex, so the 1 file/component
ratio is just right.

------
k__
How does it compare to Mithril?

[http://mithril.js.org/](http://mithril.js.org/)

------
tel
Here's a draft d.ts file for anyone who'd consider using this with TypeScript
(like I would).

[https://gist.github.com/tel/a4b0980db350096afd53](https://gist.github.com/tel/a4b0980db350096afd53)

------
coldcode
What language are those examples in?

    
    
        export let Button = {
          render({props, state}) {
            return <button>{props.text}</button>
          }
        }

~~~
johnernaut
ES6

------
fiatjaf
You should use monospace fonts in your code samples.

~~~
hereonbusiness
This was bugging me too, they are trying to but it's probably only working on
OSX machines since they're using {font-family:'menlo'} without a fallback, so
if the font is not available the code is rendered using Times New Roman
instead, at least on Chrome.

~~~
spinningarrow
That is really lazy: the least that could've been done is {font-family: menlo,
monospace}!

------
dukerutledge
Meh, I'd rather work with objects that enforce immutability and model monadic
sequencing than this sea of continuation passing.

~~~
ryanisinallofus
I think there are times for both but I agree with you. I'm pretty much only
interested in Multi paradigm languages at this point and after much
consternation I'm pretty stoked about the es6 moves and hope JS continues to
support all the ways to program things.

Immutability and lazy eval are both really well implemented with OOP
interfaces even though I consider both functional concepts.

I read this recently: semantics != syntax.

------
e12e
I wonder if they looked at riotjs[1] as an alternative. Deku is at ~10k,
riotjs is at ~4k. They both seem to have similar goals: no legacy support,
decent api, decent performance.

[1] [https://github.com/muut/riotjs](https://github.com/muut/riotjs)

~~~
e12e
Hm, I suppose if they wanted to avoid _this_ (which makes sense), riotjs might
not be a good fit. Eg:

[https://github.com/muut/riotjs/blob/master/demo/todo.js](https://github.com/muut/riotjs/blob/master/demo/todo.js)

vs

[https://github.com/segmentio/deku/blob/master/examples/todo/...](https://github.com/segmentio/deku/blob/master/examples/todo/todo.js)

Does look like riotjs might be re-factored in some interesting ways, if they
move it to ES6 though.

~~~
insin
That's the compiled version - this is the source for the Riot example:
[https://github.com/muut/riotjs/blob/master/demo/todo.tag](https://github.com/muut/riotjs/blob/master/demo/todo.tag)

------
tel
I'm curious about the decision to elide the synthetic event system. Does
Segment only target modern browsers? What is the compatibility delta on
including or eliding synthetic events?

------
_pmf_
React is a one trick pony. If the DOM is not the bottleneck for your
application, React has zero advantages over any bread and butter MVC
framework.

------
ConAntonakos
Congratulations! I think it's good to have competing options.

