
Lell.js – FRP, State Model, No Boilerplate, Built on Rx - zd
https://github.com/arkverse/lell
======
davexunit

        render() {
          var person = model.person
          return <div>
          <span>{person.name}</span> - {person.power_level}
          <button onClick={this.tapIncreasePowerLevel} />
          </div>
        }
    

Can we stop this JSX stuff? It's insane.

~~~
natrius
React is a different way of building user interfaces. Instead of finding the
right UI element to update, you write functions that generate a description of
the entire UI from the state, then the library calculates the differences to
update the changed elements.

As a result, old advice about separating code from templates does not apply.
Combining code and templates is the right thing to do in React, and JSX is far
more pleasant to read and write than the native function call syntax, which is
still available if you really don't like JSX.

If you haven't tried it, you should.

~~~
davexunit
You are assuming a lot. I know how to write purely functional template code
using the virtual DOM in JavaScript, or something like SXML in Scheme. You can
do this without using a terrible mashup of XML and JavaScript.

> JSX is far more pleasant to read and write than the native function call
> syntax

No, it isn't. XML is both hard to read and write. It's for machines, not
humans. Besides that, mixing two languages with two very different syntactic
structures together is a recipe for disaster. And besides that, you now need
an additional compilation step because it's not plain JavaScript. What works
much better is something like Mithril's templating API, which is concise and
pure JavaScript.

~~~
natrius
Okay. Most people prefer reading and writing JSX, and haven't found it to be
"insane" or a "disaster." I'm glad you found a library you prefer!

------
gokulj
Another virtual dom based framework worth a serious look is Mithril [1]. JS,
all the way.

[1] [http://mithriljs.org](http://mithriljs.org)

------
bribri
I've been really enjoying cycle.js
[http://cycle.js.org/](http://cycle.js.org/)

~~~
andersriutta
I've been seeing quite a few Rx-based libraries coming out, like Cycle.js (as
you mentioned) and Yolk, which is "a small library built on top of Virtual DOM
and RxJS": [https://github.com/garbles/yolk](https://github.com/garbles/yolk)

------
daliwali
Am I the only one who couldn't connect this to "making things move in a web
browser" for a minute? It wasn't until I saw the pseudo-HTML (JSX) code that
it clicked. Even the headline is full of jargon.

Seems that everyone is busy coming up with convoluted ways to do the same old
thing (manipulating the DOM). When I look at early jQuery era front-end code,
it's quite easy to follow what's going on. The language (ES3) was simpler, and
the competing libraries at the time provided thin abstractions on top of the
DOM API.

The DOM was more or less complete when DOM Level 3 was specified in 2004. How
much of the front-end code being written now, will be able to be easily
understood and maintained in ten years time, after the trendy fads have come
and gone? Maybe that question is irrelevant since most business fail within
that timeframe, but for posterity's sake, I'd like to look back and learn what
went well and what went horribly wrong.

~~~
_pmf_
> How much of the front-end code being written now, will be able to be easily
> understood and maintained in ten years time, after the trendy fads have come
> and gone?

Eventually, the kind of virtual DOM will move to either some standard API (via
a way of committing changes in a transactional manner) or into the next
iteration of the DOM API itself, so yes, none of the VDOM libraries will
survive the next 5 years.

For now, VDOM libraries are a necessary evil, not some revolutionary concept
like many people seem to try to make us believe.

~~~
daliwali
Actually it's quite faster to call the DOM API directly, even if the VDOM
abstraction is very sophisticated it's still overhead. Facebook has convinced
people that it's a necessary evil when it's not.

It doesn't even make sense to standardize VDOM since it's just an
implementation detail.

