10 ms·
Deku: How we built our functional alternative to React
- nwmcsween 11y agoThis 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 11y agoThey didn't invent mercury.
- tel 11y agoIt'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 11y ago| It’s also a lot of fun The only cogent reason offered for writing yet another front end framework ...
- calcsam 11y agoProposed new shorthand: YAJF
- lostcolony 11y agoYAGDJF
- mofle 11y agoYAFS - Yet Another Framework Syndrome. https://medium.com/@tastejs/yet-another-framework-syndrome-yafs-cf5f694ee070 https://medium.com/@tastejs/yet-another-framework-syndrome-y...
- Aeolun 11y agoA very compelling reason though, if you are not constrained by any other factors.
- ryanisinallofus 11y agoYet another comment.
- kuschku 11y agoNo. The best reason is: Not bound to Facebook License and Patents.
- jefftchan 11y agoWhat 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 11y agoWe'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 11y agoLast commit: Jul 30, 2014
- davexunit 11y agoI really dislike JSX. Mixing HTML and JS is not elegant at all. Why is it so popular now?
- madeofpalk 11y agoI 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'))
- lmm 11y agoWhat 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 11y agoI 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.
- biggerbob 11y agoStupid. NIH. "Why didn’t you just use React?" "We like knowing in detail how code works". Such a common motif these days. Cool I hope that was worth 2 months of x devs' time.
- tacone 11y ago" We also found that we kept fighting with function context all the time which is waste of brain energy. React has some functional aspects to it but it still feels very object-oriented. You’re always concerning yourself with implicit environment state thanks to this and the class system. If you don’t use classes you never need to worry about this, you never need decorators and you force people to think about their logic in a functional way."
- nutate 11y agoReading code is easier than writing code, but I guess some people don't like doing that. I hesitate to call anyone stupid as they did have their non-npm thing, but still.
- droidist2 11y agoReally? I think writing code is way easier than reading it.
- nutate 11y agoI think there is a rapid feedback loop of writing that makes it drug like. Reading can start w/ absolutely no understanding and leave you with very little after a fair amount of time clicking from file to file. It can feel far more frustrating off the bat. But after some amount of time, the ease of simply reading someone else's working codebase compared to debugging/designing and reading your own becomes overwhelming. So off the bat, writing is easy, but as soon as the amount of code you've written gets near to the complexity of what you avoided reading, you're going to wish you'd just read up a bit. There are a lot of serious javascript nerds who defensively coded the living crap out of react (and for that matter ember, angular, etc)... starting from scratch in light of that seems quite intense. Even if I were going to embark on such a quest (let's say for pure functional programming style), I'd probably start looking at the ideas in Om (clojurescript react) before writing my own. I think I'm biased towards not coding because laziness pays dividends later once maintenance, etc come into play.
- DigitalSea 11y agoGreat 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 11y agoSorry, 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.
- jeswin 11y 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.
- jeswin 11y agoExcellent 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.
- deleted 11y ago[deleted]
- dukerutledge 11y agoMeh, I'd rather work with objects that enforce immutability and model monadic sequencing than this sea of continuation passing.
- ryanisinallofus 11y agoI 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 11y agoCool. Are you going to make a Deku Native for mobile development?
- fiatjaf 11y agoYou should use monospace fonts in your code samples.
- hereonbusiness 11y agoThis 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.
- kuschku 11y agoI was wondering why it showed as monospace for me, and then I noticed I had menlo installed on my system xD
- spinningarrow 11y agoThat is really lazy: the least that could've been done is {font-family: menlo, monospace}!
- fiatjaf 11y 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 https://github.com/Raynos/mercury/blob/master/index.js
- deleted 11y ago[deleted]
- jaltekruse 11y agoI 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.js https://github.com/Raynos/mercury/blob/master/dist/mercury.j...
- darklajid 11y agoStumbled 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 11y agoHaving 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.
- dustingetz 11y agoHow is this more "functional" than react? What do you mean by "functional"? I write clojurescript for a living and I don't get it.
- Meai 11y agoThose 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_ 11y agoReact 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.
- deleted 11y ago[deleted]
- coldcode 11y agoWhat language are those examples in? export let Button = { render({props, state}) { return <button>{props.text}</button> } }
- johnernaut 11y agoES6
- deleted 11y ago[deleted]
- insin 11y agoES6 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 http://babeljs.io/repl
- Lazare 11y agoJavascript. 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__ 11y agoHow does it compare to Mithril? http://mithril.js.org/ http://mithril.js.org/
- ConAntonakos 11y agoCongratulations! I think it's good to have competing options.
- tel 11y agoHere'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
- tel 11y agoI'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?
- e12e 11y agoI 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 11y agoHm, 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/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.
- insin 11y agoThat'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