Hacker News Reader

Comment by grayrest | Hacker News Reader

> React and Angular2 do the same thing yet they are both bloated and force tons of tools and tech down your throat. For what?

State control. The most important thing about a React app is that you can write your code to have every bit of application state inside a single variable. It gets you hot code loading, trivial testability, and session recording/replay. I can actually test the app without having to use selenium (which I hate). These aren't really benefits from React per se but from the vdom approach. My apps are in Clojurescript and don't use the majority of React's features so replacing it with an alternative vdom implementation is on my todo list for this year.

I haven't used it in anger, but Polymer is at the top of my list if I needed to write an app to integrate with a third party or something where I didn't have app state control.

View on HN

Note that mithril is much more lightweight than react, offers a similar vdom model, but has a completely different algorithm for deciding when to redraw.

I actually think that mithril's redraw algorithm is less intuitive to use than react, but it is way simpler, which has its own advantages.

There are a bunch of alternative implementations. The vdom benchmark [1] is a fairly good list but I've run across at least two more that aren't tracked there.

[1] http://vdom-benchmark.github.io/vdom-benchmark/

Which two?

It's missing ractive, which is one of the oldest virtual DOM implementations build by the interactive team at The Guardian. I use it daily for CertSimple.

I ran across [1] last week. I saw another (not ractive) a month ago but I've forgotten the name.

[1] https://github.com/Lucifier129/react-lite

I love mitril so much. It would be soooo much better with a lisp syntax, though.

I can't tell if you're joking.

I personally despise Lisp syntax.

...Well then, you probably wouldn't like Mithril.

Typically, Mithril uses raw JS lists, function calls, and objects to create its vdom, which you have to directly manipulate. Like using react without JSX. With a lisp syntax, you might write the end of an expression as )))))), as opposed to in JS, where you might write )])]}); or something similar.

I've actually been considering trying Mithril.

But it's not strictly parenthesis that bother me. You're right in that )]}) is actually far more annoying. I try not to nest that deep in JS if I can help it.

Arrow functions reduce the pain. Not passing array literals in function calls helps as well. Angular seems like the big culprit that injects [] into the middle of an argument list, for me anyway, and using that syntax is optional.

Well, mithril requires a LOT of array literals and object literals in your function calls. http://mithril.js.org/getting-started.html shows todomvc in mithril. That template would be much more compact, uniform, and readable with a lispy syntax.

I see. You're right, that is somewhat ugly.

I've actually considered the idea of hacking a JSX compiler to spit out Mithril output.

If you're going to mix mark-up in your JavaScript, may as well do it with "real" mark-up instead of some imitation language. I'm still on the fence about whether I like mixing mark-up and code, but I'm leaning more toward at this point.

That actually already exists: https://github.com/insin/msx

Awesome! Thanks for the link.

It did seem like an obvious thing to do. I probably would have searched for and found this before doing any actual work on JSX, but I'm glad to know it exists already. :)

Lisp syntax and idioms make mixing markup with code really elegant and simple. That's why I want to write mithril with lisp syntax.

I wrote a parenscript wrapper for it.

[edit] No time tonight to make it pretty and publish it, but here it is[1]. Usage is identical to my parenscriptx[2] (a React tool I wrote that I based this off of).

1: https://gist.github.com/jasom/4ab84354fda405a8f67a

2: https://github.com/jasom/parenscriptx

I was thinking more along the lines of lispyscript[1]. It's not as good as SPOCK[2], or clojurescript[3], but there's less overhead than clojurescript, and SPOCK is known to stretch your javascript implementation in odd ways.

1: http://lispyscript.com/

2: http://wiki.call-cc.org/eggref/4/spock

3: https://github.com/clojure/clojurescript

parenscript is quite low overhead; it's approximately lispyscript with common-lisp macros instead of whatever lispyscript has (it looks like some kind of pattern-matching style; there's only one macro example on the lispyscript documentation and the link to an article about more details is dead). In any event if you know lispyscript you can probably translate my code; it took me only a couple of hours to write the initial react version, and another 45 minutes or so to translate to mithril.

eslisp[1] might be up your alley

[1](https://github.com/anko/eslisp)

Thanks for the pointer, Leo.

Also, thank you for the mithril blog. It is amazing.

Everybody else, if you haven't read the mithril blog[1], YOU SHOULD BE READING THE MITHRIL BLOG. Even if you never plan to use mithril, you'll probably learn something interesting.

1: https://lhorie.github.io/mithril-blog/

If you want just the vdom model, look at https://github.com/Matt-Esch/virtual-dom I remember at one point mithril's vdom implementation was based on virtual-dom but I can't seem to find any documentation to back this up.

Probably a coincidence. I only found out about virtual-dom after I released Mithril.

Honestly memory is such an untrustworthy thing!

>State control

It took me a long time to figure that was the point and it still kind of seems you could write in good old plain javascript:

x = "some state"

if (you want to change it) { x = "some other state"

    DrawThingOneThatDependsOnx()

    DrawThingTwoThatDependsOnx()}

Rather than spending days learning the tons of bloat, tools and tech that effectively does that for you under the hood anyway?

(Plus with vanilla js running up to 40x faster than React https://news.ycombinator.com/item?id=9824884 apparently)

How do you know what things depend on X? if you have Z=Y+X, do you also refresh Z?

State control is not simple when you have many moving parts. A very good solution (which both Angular and React bring to the table without destroying performance most of the time) is to remove all the moving aspects to the parts. This doesn't matter in microbenchmarks, but in real apps, having something be slightly slower but bug-free is better than fast but wrong.

I like Douglas Crockford's "Class Free OOP" approach for managing dependencies and composing functions:

  function constructor(spec) {
    let {member} = spec,
    {other}  = other_constructor(spec),
    method   = function () {
          // accesses member, other, method, spec
    };

    return Object.freeze({
      method,
      other
    });
  }

but prefer to use an immutable data structure instead of Object.freeze().

All application state can be stored in a single "Atom" (i.e immutable data) and all message passing can be achieved through CSP channels.

When dealing with the DOM, 'incremental-dom' is a nice option.

Of course, separating pure functions from side-effects inducing code is key to maintaining control.

This is my approach when going "framework-less".

> vanilla js running up to 40x faster than React

That particular link is a strawman argument. React isn't magically fast. Writing a 5 line shouldComponentUpdate would normalize the performance.

If you think you can do better with something else, feel free to ignore the React hype. For my part, I've been doing frontend full time more or less exclusively since 2005 and have tried dozens of libraries/frameworks in earnest. I don't know of a better way to write client side code.

To add to the Clojurescript point: dead code removal. CLJS uses Google Closure and can take part in it's advanced compilation and dead code removal feature. All of the cruft that isn't used, that is abstracted away in CLJS anyway, can be removed when building your code for production.

https://developers.google.com/closure/compiler/docs/api-tuto...

Not an excuse for baroque frameworks though.

You can manage state like that with web components as well: store state in one root object, only pass state down the tree, only build DOM based on the given state, use events to communicate changes back up the tree.

The end result is very React-like in behavior, but completely interoperable with other web components, and not require a framework at all.

This is what React does if you don't use Flux/Redux/something similar and it don't scale very well to medium sized or larger codebases.

Web Components hasn't been supported by all browsers (and probably still isn't) and has had some problems with grouping components and loading them. I can use React today but Web Components is something I might want to use in 2-3 years.

Re: state control. The "mediator pattern" is a cool way to write some apps and it addresses a lot of these concerns (with a parent app-element). It's not Polymer specific, but here's a cool video going into a little more detail: https://www.youtube.com/watch?v=ZDjiUmx51y8

Reply on news.ycombinator.com