Deku: How we built our functional alternative to React

https://segment.com/blog/deku-our-functional-alternative-to-react/

by gwintrob • 11 years ago

189 78 11 years ago

segment.com

jefftchan• 11 years ago

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

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

anthonyshort2• 11 years ago

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• 11 years ago

Last commit: Jul 30, 2014

nwmcsween• 11 years ago

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?

Touche2• 11 years ago

They didn't invent mercury.

tel4• 11 years ago

It's mostly unrelated.

Mercury is a collection of libraries together which can be used as a framework. The most comparable subcomponent of mercury to deku is virtual-dom. Comparing virtual-dom and deku is pretty simple: v-d is not "component based" and has no internal state management.

kansface• 11 years ago

| It’s also a lot of fun

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

calcsam• 11 years ago

Proposed new shorthand: YAJF

lostcolony• 11 years ago

YAGDJF

mofle• 11 years ago

YAFS - Yet Another Framework Syndrome.

https://medium.com/@tastejs/yet-another-framework-syndrome-y...

Aeolun• 11 years ago

A very compelling reason though, if you are not constrained by any other factors.

ryanisinallofus2• 11 years ago

Yet another comment.

kuschku3• 11 years ago

No.

The best reason is: Not bound to Facebook License and Patents.

davexunit2• 11 years ago

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

madeofpalk• 11 years ago

I think because you just end up doing it anyway.

Note that this isn't mixing just any JS, it's only presentational javascript. Either you're using some templating language like Handlebars or Jinja/Django's or Angular's HTML attribute data binding, or lots-of-jquery-selectors-tied-directly-to-the-html, you still need some sort of view logic to build your DOM.

Don't get me wrong, I've never really used React/JSX in depth enough, and I'm not overly enthusiastic about all these 'HTML' tags in my JS. But lets not pretend this is any worse than the current approach of $('.modal').append(document.createElement('button'))

lmm2• 11 years ago

What I want is the wicket model, essentially a stricter version of Angular's HTML attribute data binding, where virtually the only thing you can do is <tag myframework:id="someid">, and you can connect to "someid" in code - but only as a literal, and the only thing you can do is replace that tag with a component, nothing more complex. All the current approaches are too liberal, too "there is more than one way to do it". I want to have one, and only one, simple rule for how data goes into HTML.

sls• 11 years ago

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• 11 years ago

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.

wtetzner• 11 years ago

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 part of the problem is how you think about it. You're not writing some HTML and then some Javascript to manipulate it. Conceptually, you're writing a Javascript function to create a chunk of HTML.

Hytosys• 11 years ago

I'm sure this similarity has been pointed out before, but I think JSX is tangible for many of the same reasons PHP templating was. It only makes sense that a company that operates predominately in PHP would pass the baton of markup interpolation to JS as the web becomes more client oriented.

I personally lean towards logic interpolation (Handlebars, AngularJS), but both have their potentials for abuse. I don't know enough about JSX to say one way or the other what good practices are enforced and what bad practices are available.

d0m• 11 years ago

From a developer standpoint, I always felt HTML and JS to be extremely tight together. So whether or not they're in different files, they were linked to each others. Now, with JSX, it just feel like a more powerful html without all the crapy extremely limited template language..

Maybe for a static website, it doesn't feel right. But for a webapp it feels much better than before for me.

anthonyshort2• 11 years ago

All it does it transform into a tree of objects, https://gist.github.com/anthonyshort/5e9112a9ded7c8fc0f20, which is annoying to write out by hand and HTML is familiar.

I hated it (a lot) before I tried it out. You could just put the render function in a separate file since it's just a function and then it's basically the same as a template anyway

albertoleal• 11 years ago

Why is it so popular now?

Because transpilers.

crudbug• 11 years ago

Count me in!

Introducing multiline string comments to ES6 (python syntax) would have been a better option.

""" <div> <p> {{ hello_world }} </p </div> """

grayrest• 11 years ago

You're in luck. ES6 introduces quasi-literals which are multi-line and will do exactly what you want. You can even tag them to set up parsing.

    jsx`<div><p>${hello_world}</p></div>`

I don't know why it'd be a better option. You're moving the time/cost of parsing client side and preventing minification. If you're going to do a build time parse, I don't understand what the extra quoting buys you.

aidenn0• 11 years ago

Perhaps you could explain what you mean by "not elegant"?

I personally find:

    <div>Hello {this.props.name}</div>

To be more elegant than:

    React.createElement("div", null, "Hello ", this.props.name)

Of course react allows you to use whichever you prefer.

hcarvalhoalves• 11 years ago

Mixing HTML and JS is not elegant at all.

Unless you know LISP, then you understand code is data.

Touche2• 11 years ago

But JS isn't lisp, and to manipulate it you have to turn it into an AST and traverse it with a lot of extra tooling. It's not as (easily) pliable as lisp.

davexunit2• 11 years ago

Trust me, I know Lisp. In Lisp, there's built-in templating via quasiquote, so we can easily construct HTML documents by first writing them as s-expressions.

JSX is a far cry from how Lisp does things. You get all of the nastiness of the redundant typing involved with hand-writing HTML mixed in with your JavaScript, plus the addition of another compilation step in your build!

I like Mithril's virtual DOM API[0] much more. It's really pleasing to use, but of course not as good as SXML in Lisp because JavaScript doesn't have macros or quasiquote.

[0] https://lhorie.github.io/mithril/mithril.html

insin4• 11 years ago

JSX [1] is essentially a syntax fix for something people have been doing for a long time in JavaScript with DOM building libraries.

Having extensively used nested function call (like MochiKit.DOM [2]) and nested JSON-ML-ish array (like dombuilder [3]) variants of DOM builders in the past, JSX's syntax is a lot more friendly to write and maintain.

[1] http://facebook.github.io/jsx/ [2] http://mochi.github.io/mochikit/doc/html/MochiKit/DOM.html [3] https://github.com/creationix/dombuilder

DigitalSea• 11 years ago

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.

jsprogrammer• 11 years ago

Sorry, but did you read the article? They claim a 38% performance advantage over "other frameworks", which I assume includes React.

Even if the performance was at React's level, a first pass at Deku shows it as much preferable to React in terms of coder experience.

jeswin2• 11 years ago

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.

fiatjaf4• 11 years ago

https://github.com/Matt-Esch/virtual-dom/

meric• 11 years ago

Have you heard of omniscientjs: http://omniscientjs.github.io? It allows you to use react in a functional style.

chime• 11 years ago

I hate seeing talented development hours going to waste that could have been used to make an already existing project better.

They didn't go to waste. They made Deku and learned a lot along the way. Just because something exists, doesn't mean you can't build your own. And not everything has an immediate, positive outcome.

I wrote my own MP3 Player back when Winamp really whipped the llama's ass. That got my name in a local newspaper in India, which ended up being the small boost I needed for the Consul General to grant me a Student Visa to come to the US. A few years later, a fan of my MP3 Player messaged me and we became good friends. I interviewed for a job in Florida and ended up staying at his place for the weekend. A few years later, while I continued to work at the job in Florida, my friend and I built a scheduling webapp that made it to the front page of Wired during SXSW.

An incredibly long list of positive things that happened in my life, I can track back to spending a week or two writing that MP3 player in my youth. If you ask me, I'd do it all over again. So I'm glad they build Deku, regardless of how it compares to React.

filearts• 11 years ago

Really awesome story. I agree with you wholeheartedly that there is always value in building things!

There may or may not be value to other potential users or even to the employer though and these seem to be the only perspectives addressed by commenters.

If the company's resources could have been better spent elsewhere than that is the company's (and its stakeholders') problem. Please stop discouraging others from creating and sharing because you don't find the creation better or worthwhile right this instant.

burntcaramel• 11 years ago

I think also the fact that Deku has a smaller file size than React.js is significant (10KB vs 118KB). That would have been more difficult with a fork.

If Deku looks solid enough I might consider using it. And hopefully it can influence React too.

mattdesl• 11 years ago

I am not invested in either framework but there are some very clear differences:

- size/complexity: React is a monolith that can't be digested by just skimming a couple small files

- API surface area: less room for major semver bumps

- modularity: React devs seem to fear dependencies

- versioning: React encourages the use of peer dependencies which is truly going to be a nightmare in 2 years with hundreds of UI modules across different conflicting React versions

- no singletons: React can only be required once, otherwise bats will fly out of your computer. This is compounded by the versioning issue.

- style: React uses and encourages a different programming paradigm

throwaway1979• 11 years ago

I'm disappointed for a different reason. I'm just sick and tired of the delta new thing. Frontend dev as it is practiced today is horrible ... libraries and frameworks seem to have shelf lives measured in months!

I was watching a video posted this morning (how NYT uses Go) and the dev was mentioning how challenging their system used to be with different languages - Python, PHP, Java and Groovy ... so they decided to redo major chunks in Go. Seriously?

I don't pretend to have the answer ... stopping to innovate isn't going to cut it. But I increasingly feel that as a tech worker, I'm on a train careening towards a ravine without a bridge. But hey ... lets go faster and it'll be a fun ride!

geon• 11 years ago

libraries and frameworks seem to have shelf lives measured in months!

What "shelf life"? If the library works for what you app needs it to do, there is no use by date.

vorg• 11 years ago

their system used to be with different languages - Python, PHP, Java and Groovy ... so they decided to redo major chunks in Go. Seriously?

Valid reason for a rewrite, especially considering the quality of one or two of those languages. A language can look and run OK when used for a script calling system code, but when those scripts are glued together and become the system, all sorts of problems can manifest. It's only sensible someone there looked at the sit and planned out a replacement.

kuschku3• 11 years ago

But Deku gives them the advantage of not being bound to possibly devastating patent licenses.

jeswin2• 11 years ago

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.

dukerutledge• 11 years ago

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

ryanisinallofus2• 11 years ago

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.

droidist2• 11 years ago

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

fiatjaf4• 11 years ago

You should use monospace fonts in your code samples.

hereonbusiness• 11 years ago

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.

kuschku3• 11 years ago

I was wondering why it showed as monospace for me, and then I noticed I had menlo installed on my system xD

spinningarrow• 11 years ago

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

fiatjaf4• 11 years ago

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

jaltekruse• 11 years ago

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...

darklajid• 11 years ago

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

dustingetz• 11 years ago

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• 11 years ago

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

tjallingt• 11 years ago

Functional as in Functional programming, the counterpart of Object Oriented programming.

Meai• 11 years ago

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?)

_pmf_• 11 years ago

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.

coldcode• 11 years ago

What language are those examples in?

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

johnernaut• 11 years ago

ES6

insin4• 11 years ago

ES6 with a sprinkling of JSX. Paste this into the Babel REPL [1]:

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

[1] http://babeljs.io/repl

Lazare• 11 years ago

Javascript. Mostly.

1) export and let are part of ES6 2) <button> is JSX, which is uses by Facebook's React but can also be used with Deku.

If you run that through babel, it turns it into valid ES5 Javascript which will run in any modern browser:

    "use strict";

    Object.defineProperty(exports, "__esModule", {
      value: true
    });
    var Button = {
      render: function render(_ref) {
        var props = _ref.props;
        var state = _ref.state;
    
        return React.createElement(
          "button",
          null,
          props.text
        );
      }
    };
    exports.Button = Button;

(Note: By default Babel translates JSX into React.createElement calls; the Deku docs cover the one line config changed needed to make it us Deku element calls instead.)

k__• 11 years ago

How does it compare to Mithril?

http://mithril.js.org/

ConAntonakos• 11 years ago

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

tel4• 11 years ago

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

tel4• 11 years ago

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?

e12e2• 11 years ago

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

e12e2• 11 years ago

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/segmentio/deku/blob/master/examples/todo/...

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

insin4• 11 years ago

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

Deku: How we built our functional alternative to React

Related Stories