current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.
up vote 0 down vote favorite
1

I've been reading this article: http://modernweb.com/2013/09/30/functional-reactive-programming-in-javascript/ and I found the examples there way too complicated for what the code is supposed to do. I am aware that this is a simple example, made for demo purposes, but still, I am not sure if need to add that level of complexity for solving that specific type of problem.

Disclosure : I am big fan and advocate of reactive programming on the server. I believe that RP has many positive uses, especially when developing scalable applications. Yet, IMHO, it still feels kind of funky on the browser. Maybe, if it is encapsulated and used to serve a particular need, say implementing a complex routing and dispatching mechanism in th browser, it's use would be justified. What do you think?

share|improve this question

closed as primarily opinion-based by Doval, amon, Jon Purdy, Thomas Owens♦ Mar 19 at 11:50

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
1  
Sorry, but Stack Exchange sites aren't forums; the site's Q and A model isn't suited for discussions. See the help center for details. –  Doval Mar 19 at 11:35
    
"I am big fan and advocate of reactive programming on the server": don't forget that there are also JavaScript apps executed on the server-side (through Node.js). –  MainMa Mar 19 at 11:39
1  
@Doval I thought that this is exactly the purpose of "Programmers" - to allow for more discussion-oriented questions, unlike "StackOverflow" –  user1107412 Mar 19 at 11:47
2  
@user1107412 No; roughly speaking Stack Overflow is for problems with your code and Programmers is for design/methodology questions. None of the Stack Exchange sites permit discussions. The site's model is based on the existence of a single "best" answer, not a back-and-forth dialogue. This sort of thing is welcome in Programmers Chat. –  Doval Mar 19 at 11:52
2  
recommended reading: On discussions and why they don't make good questions –  gnat Mar 19 at 12:20

1 Answer 1

up vote 1 down vote

I agree, it's just too complicated. I think the root of this problem is that async programming is inherently difficult. In the past, async code was mostly found in specialist, high-performance areas (kernels, servers, etc.) while typical code was multi-threaded. This has changed somewhat in recent years.

The ideal solution would be for browser JavaScript to be multi-threaded. This is possible to some extent with Web Workers, but they are limited, and will generally not solve the problems that Bacon.js aims to solve. If we did get proper multi-threaded js - where every thread can access the DOM in a thread-safe way, this would largely remove the need for async programming. Having said that, I expect it would then introduce a whole new set of problems with bad threading code. And in any case, while we can wish for this, it isn't available right now.

So Bacon.js and other systems like AngularJS promises are trying to wrap the async complexity. However, as you point out, they're still complex to use. One of the reasons for this is that JavaScript doesn't have a widely-supported yield function. Yield allows a piece of synchronous code to pause, while it waits for something, then resume. Without this, you need to use "continuation passing style", which severely limits the ability of a library to hide the complexity. However, some browsers (Chrome, Firefox) now support yield in JavaScript.

In the absence of threads or yield, we are largely left with simply putting up with the complexity of async programming. However, there is one other avenue to explore: making common async tasks easier. Bacon.js aims to be a fully flexible async framework, so it's hard to use. AngularJS promises can be just as bad, but certain tasks are easier. For example, you can issue a resource load, get a promise, assign it to a model, and attach the model to a template. All that is pretty simple to code, and it gives you the behaviour that the template first appears empty, and automatically populates with data when it is ready. That's a pretty good start - although if you want to customise the flow it gets more difficult.

share|improve this answer
2  
I have a hard time understanding how promises are more complex than exposing threading semantics directly to the programmer. –  RibaldEddie Mar 19 at 14:51
    
@RibaldEddie - Consider this example. What would equivalent code look like that used threading? –  paj28 Mar 19 at 15:18
    
For a number of reasons it would almost certainly be harder to understand and more error prone. –  RibaldEddie Mar 19 at 15:20
    
@RibaldEddie - would you care to expand on those reasons? All that code would happily run in a single thread using blocking operations. We just can't do that in JavaScript (at present) because it would block the UI thread. –  paj28 Mar 19 at 15:36
1  
What you're saying doesn't make a lot of sense. Browsers are absolutely multi-threaded right now. The point of things like promises is to abstract away that complexity. The promise code from the angular example where it prints the greet statement all runs on the main (UI) thread. Anyway the question was closed as opinion based and generally a lot of programmers don't have a great handle on how all this stuff works so I won't be discussing it further with you here. –  RibaldEddie Mar 19 at 15:54

Not the answer you're looking for? Browse other questions tagged or ask your own question.