Yahoo Mail moving to React

Post by spion » Wed, Nov 26, 2014, 11:49 PM UTC

manish_gill wrote: post #176

nwienert wrote: post #112

Earlier quoted context omitted.

I feel like people stick fingers in their ears and ignore the ecosystem whenever JS is mentioned. There's a wealth of transpilers and tools that fix all the problems mentioned here (if you even agree they are problems), and yet they are brought up every time. Weak types: Check out Facebook Flow or TypeScript. Global namespace: Not true with require/modules. Ambiguous/unexpected behavior... please explain? You could u…

True, there's a plethora of JS tools someone can use. The problem is that they have to be discovered. And there's no standard. I found out about Browserify 2 days ago and realised all the problems it could have solved for me. Now I have to migrate the code I have to it. JS ecosystem is confusing. See: https://news.ycombinator.com/item?id=7074307 Utilities should be a part of the language's "battery". Ambiguous/Unexpe…

  1. TypeScript or Flow
  2. React
  3. Promises: bluebird, when or p-promise
  4. Observables: rxjs or most (they play well with promises)
  5. immutable-js for immutable data structures
  6. lodash and/or Ramda.js
  7. browserify

Post by igouy » Wed, Nov 26, 2014, 11:51 PM UTC

meowface wrote: post #146

oceanstone wrote: post #133

Earlier quoted context omitted.

> The runtime performance is already very good and continually getting better Have you checked out the Computer Benchmarks Game? Here are some benchmarks they provide, comparing the JavaScript V8 to Python [1], Ruby [2], and PHP [3]. Looking at statistics such as these, I'm left thinking, "1. This is awesome! 2. Is there something about these other languages that prevents V8-like performance, or is this more a matter…

V8 does precompilation to native code and JIT optimization, which can typically turn numerical computations into efficient, and often highly optimized, machine code. These benchmarks seem to primarily be testing algorithms which require a lot of numerical computation and can take advantage of Javascript's typed arrays, which V8 is designed specifically to optimize. A somewhat more fair comparison would be V8 vs. PyPy…

Post by tracker1 » Wed, Nov 26, 2014, 11:55 PM UTC

jbergens wrote: post #237

CitizenKane wrote: post #169

Earlier quoted context omitted.

It's honestly not as much of an issue as it's often made out to be. There are a ton of ways to manage asynchronous code out there including but not limited to all the various promise libraries such as when.js( https://github.com/cujojs/when ), q ( https://github.com/kriskowal/q ), and bluebird ( https://github.com/petkaantonov/bluebird ). Not to mention the Async library ( https://github.com/caolan/async ) which is f…

Actually I think that even a lot of CPU intensive tasks could run on Node. Split them into smaller tasks (which you probably have to do anyway if you want to use multiple threads with another language) and run those as promises. Of course js is bad for most numerical calculation but for some things it might work. Or combine it with Dart or Asm.js.

Post by igouy » Wed, Nov 26, 2014, 11:57 PM UTC

bad_user wrote: post #139

oceanstone wrote: post #133

Earlier quoted context omitted.

> The runtime performance is already very good and continually getting better Have you checked out the Computer Benchmarks Game? Here are some benchmarks they provide, comparing the JavaScript V8 to Python [1], Ruby [2], and PHP [3]. Looking at statistics such as these, I'm left thinking, "1. This is awesome! 2. Is there something about these other languages that prevents V8-like performance, or is this more a matter…

That's not an objective comparison, since Javascript has been optimized to deal with arrays and numbers, as that's one main use-case that people have in the browser. Take a look at the source code and tell me if that's the kind of code that you write.

Post by kxo » Thu, Nov 27, 2014, 12:03 AM UTC

gasping wrote: post #225

woah wrote: post #216

Earlier quoted context omitted.

If you have callback hell, it is an expression of muddled thought. If you have broken your code up into small enough modules and functions, and you know which tasks depend on other tasks, you will not have callback hell. If you are unclear on the logic of your code, you can often make it work in a messy way with the "laundry list approach". This involves formulating a sequence of tasks that happens to work, without n…

> If you have callback hell, it is an expression of muddled thought. No. It's an indication that you're using a FOTM runtime environment. There's a reason why no production-ready runtime uses continous passing / callback models.