10 ms·

> 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

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

plexicle 11y ago
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 https://www.youtube.com/watch?v=ZDjiUmx51y8
aidenn0 11y ago
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.
- grayrest 11y ago
  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/ http://vdom-benchmark.github.io/vdom-benchmark/
  - knite 11y ago
    Which two?
    - nailer 11y ago
      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.
    - grayrest 11y ago
      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 https://github.com/Lucifier129/react-lite
- qwertyuiop924 11y ago
  I love mitril so much. It would be soooo much better with a lisp syntax, though.
  - SomeCallMeTim 11y ago
    I can't tell if you're joking. I personally despise Lisp syntax.
    - qwertyuiop924 11y ago
      ...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.
      - SomeCallMeTim 11y ago
        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.
        qwertyuiop924 11y ago
        Well, mithril requires a LOT of array literals and object literals in your function calls. http://mithril.js.org/getting-started.html 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.
        SomeCallMeTim 11y ago
        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.
- shuzchen 11y ago
  If you want just the vdom model, look at https://github.com/Matt-Esch/virtual-dom 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.
  - lhorie 11y ago
    Probably a coincidence. I only found out about virtual-dom after I released Mithril.
    - shuzchen 11y ago
      Honestly memory is such an untrustworthy thing!
lsh 11y ago
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-tutorial3 https://developers.google.com/closure/compiler/docs/api-tuto... Not an excuse for baroque frameworks though.
spankalee 11y ago
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.
- jbergens 11y ago
  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.
tim333 11y ago
>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 https://news.ycombinator.com/item?id=9824884 apparently)
- rtpg 11y ago
  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.
  - kenOfYugen 11y ago
    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".
- grayrest 11y ago
  > 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.

plexicle 11y ago

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 https://www.youtube.com/watch?v=ZDjiUmx51y8

aidenn0 11y ago

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.

grayrest 11y ago
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/ http://vdom-benchmark.github.io/vdom-benchmark/
- knite 11y ago
  Which two?
  - nailer 11y ago
    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.
  - grayrest 11y ago
    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 https://github.com/Lucifier129/react-lite
qwertyuiop924 11y ago
I love mitril so much. It would be soooo much better with a lisp syntax, though.
- SomeCallMeTim 11y ago
  I can't tell if you're joking. I personally despise Lisp syntax.
  - qwertyuiop924 11y ago
    ...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.
    - SomeCallMeTim 11y ago
      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.
      - qwertyuiop924 11y ago
        Well, mithril requires a LOT of array literals and object literals in your function calls. http://mithril.js.org/getting-started.html 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.
        SomeCallMeTim 11y ago
        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.
shuzchen 11y ago
If you want just the vdom model, look at https://github.com/Matt-Esch/virtual-dom 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.
- lhorie 11y ago
  Probably a coincidence. I only found out about virtual-dom after I released Mithril.
  - shuzchen 11y ago
    Honestly memory is such an untrustworthy thing!

lsh 11y ago

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-tutorial3 https://developers.google.com/closure/compiler/docs/api-tuto... Not an excuse for baroque frameworks though.

spankalee 11y ago

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.

jbergens 11y ago
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.

tim333 11y ago

>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 https://news.ycombinator.com/item?id=9824884 apparently)

rtpg 11y ago
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.
- kenOfYugen 11y ago
  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".
grayrest 11y ago
> 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.