fp is the only successful paradigm in js, and react is friendly to fp

【 在 muser (负尽千重罪，练就不死心) 的大作中提到: 】
: react 好用吗，能提高生产力吗？  ————这两天看了一下，不知道它为什么这么火。我前台没经验，拿个jquery bootstrap就觉得很强大了
--
FROM 180.173.114.*

if you mean requirejs and angularjs, they are different creatures

【 在 officercat (黑猫警长·奈叶要加油) 的大作中提到: 】
: requiredJS现在什么情况，被agularJS替代了么？
--
FROM 183.195.251.*

fundamental libraries (e.g. dom, node api) provides async by callback,
thus requires code to be organized around first-class functions.

the js language lacks class-based inheritance.

1 = you have to work with many functions
2 = you cannot work with many classes
1+2 = you have to write many functions working with dumb objects.

this is where fp wins.

【 在 muser (负尽千重罪，练就不死心) 的大作中提到: 】
: so why fp wins?
--
FROM 183.195.251.*

explicit locking is more error prone.

【 在 muser (负尽千重罪，练就不死心) 的大作中提到: 】
: 另外，在传统gui里，是通过锁定界面来防止运算过程中的数值改变。angular加个功能以指定某个时段内某dom节点disabled应该也很容易吧？
--
FROM 183.195.251.*

【 在 muser (负尽千重罪，练就不死心) 的大作中提到: 】
: 墨菲定律，我觉得主要是心理上的感受。
: 现实中，爬火梯走钢丝的杂技演员多了。
: 编程也是。

but it is irresponsible to tell newbies to play acrobat.

: 刀梯上行走，不是求的刺激。而是知道，刀锋和皮肤接触后两者没有相对位移，就不会割伤。
: erlang我用过一年多。天之道，尺有所短寸有所长。所以，无论erlang 听上去如何完美，她也搞了个mutable 的 mnesia 数据库。

the point is not about never to use mutable state; it is that managing
mutable state is hard, so avoid it when unnecessary, and when necessary,
keep things manageable.  a database is a typical manageable global
mutable state; we all know how to manage it, and we assume we have only
one or a few of them.

: 我个人觉得，该做什么做就是了。需要锁就锁，不需要就不锁。所谓好坏都是放在某个上下文里才有意义的。

agreed.

and, well, in the context of webdev, and especially at the client side
as is the topic of this thread, the problem comes down to soft real-time
programming with deadline of 1/24 s, in a single thread using cooperative
multitasking in (explicit or implicit) continuation-passing style --- if
you lock, you are always in the GUI thread.  take your example, if you
lock a component to deny writes to its state, the logic may be:

- UI components discard user input if locked;
  of course, input is discarded, and if background computation accidentally
  took too long the UI just broke up.
- cancel background computation if any;
  cancellable promises are yet to mature, and side effects around
  cancelling require a lot of attention.
- buffer input and retry when unlocked;
  looks somewhat too complex to me, and, retry is not always desired.

in a 2-way binding, all these must be done before binding is updated, that
is, usually directly in the UI component.

but if using 1-way data flow, an UI component can blindly push out new
inputs, because we can easily plug-in a "locking" layer between the view and
controller/model.  in FRP this can be streams.  above problems are not
automatically solved, but there is no longer need to lock in every component
and every piece of logic code.

well, in 2-way binding the scheme can be emulated by taking a snapshot of
all required data before starting computations, but this already makes the
whole thing a 1-way flow.
--
FROM 183.195.251.*