Lell.js – FRP, State Model, No Boilerplate, Built on Rx | Hacker News Reader

Lell.js – FRP, State Model, No Boilerplate, Built on Rx

github.com

37 pointszd26 comments

    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.

Sorry, but won't stop anytime soon, because it's insanely productive.

The React community has overwhelmingly adopted JSX.

Why is it insane?

It's actually the opposite - awesome.

shameless plug: try domvm [1], it's js/JSONML all the way down, extremely fast [2] (see others [3]), 8k min, isomorphic with zero dependencies. you can mix imperative and declarative views and compose them with maximum flexibility and api exposure.

[1] https://github.com/leeoniya/domvm

[2] http://mathieuancelin.github.io/js-repaint-perfs/domvm/index...

[3] http://mathieuancelin.github.io/js-repaint-perfs/

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.

it has nothing to do with jsx. all vdom libraries do this. redraw-the-world is done much faster than React by numerous libraries, including mine (see other comment in this thread). Inferno is a lib that will probably replace React while maintaining jsx compatibility, check it out btw.

jsx is just more natural for designers but i agree with the gp that the benefits can be obtained with plain declarative js and avoid all the tooling required for jsx.

> all vdom libraries do this.

Most developers have never used a virtual-dom library, especially those that find JSX offensive. Your sales pitch for your library is coming off pretty aggressive, and it's a bit off topic. No one is talking about render speed.

well, if the topic is how great jsx is, it's on topic for me cause the lib was written specifically to scratch that itch :)

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.

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!

> 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

That's a very accurate observation and it's a very strong argument against React.

It's not against. React code is a part of view layer. Therefore it is kind of template code with amazing full programming language power instead of standard limited approaches.

It seems that moving html into javascript versus moving javascript into html has been the winning choice. Like the clojurescript counter parts, I want to write code.

It's really not. I've been a big opponent to JSX for quite a while, but after actually working with it and dealing with TDD on the frontend I believe it is far better approach than what Angular does for example.

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

It's like they saw "code is data" and reversed it (rock star developers do not believe in formal logic theory).

The result is a language with all the beauty of 2001's PHP and the modernistic pretentiousness of pseudo-functional JS. Calling it React is just adding insult to injury by taking a huge crap of the solid Rx research in .NET that actually brings something new to the table.

Cleaning up the messes that rockstar developers produce is why I can live such a comfortable life. Until they start trying to present at POPL or ICFP (at which point they'd get laughed straight out of the committee hall of peer reviewers) I really can't hate on them too much.

The PhD's at Microsoft Research-Cambridge, Bart deSmet (MS-guys, I can't believe you pulled him off language development for Cortana) and the rest of the Rx team must be vomiting at what came out of their mathematically sound (often wholly proven within F*[3]) Rx work, but at the same time praising whatever deity that their name isn't attached to it. At least they're adhering to the interface signature of IObserver<T>.

Digression -- but anyone who is interested in the duality (not in the mathematical sense of 'duals) between LINQ operators and monadic operators, watch this talk with de Smet[1]. It's brilliant in it's ability to reduce all of LINQ to 5 [or less, .SelectMany() is to LINQ as NAND is to gate logic; it's later proven that 3 operators are all that are required, no surprise there, Kleisli triple anyone?] and shows with great elegance the isomorphism between monadic Haskell and LINQ. (And why RX falls so naturally out of .NET as a result.)

[1] https://channel9.msdn.com/Shows/Going+Deep/Bart-De-Smet-MinL... [2] http://community.bartdesmet.net/blogs/bart/archive/2010/01/0... [3] https://fstar-lang.org/ - to be formally presented at POPL '16. I'd offer commentary but it wouldn't do justice - any PL nerds should give that a read immediately, assuming they haven't already. MSR is without a doubt the Bell Labs of our generation.

>It's like they saw "code is data" and reversed it (rock star developers do not believe in formal logic theory).

Yes, you've expressed my point better than I could. Other commenters have thought that I dislike JSX because I like separate, string-based templating languages, but I think those are terrible! I hate JSX from a language design standpoint. Writing HTML templates as functional code in your language of choice is a big win, but inventing a new language "with all the beauty of 2001's PHP and the modernistic pretentiousness of pseudo-functional JS" is a big lose.

No, it's the only way to stay sane. Look at the embeded language in angular, or every crazy templating lib around. It is far better to embed html into the host language than the other way around.

http://franz.com/support/documentation/current/doc/aserve/ht...

http://weitz.de/cl-who/

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

[1] http://mithriljs.org

I've been really enjoying cycle.js http://cycle.js.org/

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

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.

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

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.

Reply on news.ycombinator.com