Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yahoo Mail moving to React

slideshare.net

Post reply on HN
Print view View original

261–270 of 301 posts

Re: Yahoo Mail moving to React

#261

Post by edwinnathaniel »

LunaSea wrote: post #214
edwinnathaniel wrote: post #190

Earlier quoted context omitted.

I'm a 70%-90% back-end guy with 10-30% front-end work (when necessary). As the companies I work(ed) for evolve from JS => jQuery => Backbone.JS => Backbone.JS + Marionette => EmberJS, so does my skill have to evolve. I also have to write some JS code on top of PhantomJS + CasperJS (not for automation testing but instead for performance monitoring) to support enterprise product at the moment. I used to hate JS with pa…

I'm not sure why you consider the JavaScript ecosystem unstable ? JS has: - awesome dependency management systems like NPM and Bower - awesome task runners like Grunt and Gulp - NPM has thousands of plugins, more than Java's Maven and Ruby Gems [1] - Github badge support for builds, test coverage, dependency versions and NPM - Close second best StackOverflow support behind Java (without taking into account Node.js) […

I will not take the # of NPM vs Java Maven as is. Keep in mind that Java SE (API) is way more complete than NodeJS basic APIs.

Also keep in mind that in Java, most people have 1-2 choices at most and those choices tend to be way more mature and stable so we tend to feel comfortable with those (at most) choices.

You can slice and dice my analysis anyway you want. You can say lack of choices is bad and millions of Java devs will disagree with you. You can say that NodeJS is evolving like mad and thousands of other more experienced Devs that myself would argue that NodeJS ecosystems is playing "see which one sticks". Your values are different than of mine.

StackOverlow stats you posted doesn't mean anything. Literally. We know JS has been around for ages. The fact that JS claim of fame to be smaller/leaner than Java yet rank #2 behind Java humongous ecosystem is a question mark in my mind: "What The Heck?"

It can go either way.

Gulp vs Grunt, NPM and Bower. Java has Maven. One tool. Yes, there are Ant and Gradle but let's be honest, Maven is king whether you like it or not. With Java, I declare the archetype (web-app or simple app) and dependencies and away I go (unit-test is part of the build, integration-test requires a few additional lines).

With JS, I have to .. ? Let me know if it's simpler than Maven. Let's not waste time to argue about XML vs JSON or whatnot, that's a matter of taste, let's focus on the required steps to build, run tests, and package it up whether as a deployable or a dependency of others.

Re: Yahoo Mail moving to React

#262

Post by kxo »

CitizenKane wrote: post #169
dschiptsov wrote: post #89

Why on Earth people who aren't merely enthusiasts of "cool async JavaScript with V8" or those who began as a webdevs and knows nothing better than JS and PHP, could choose a single-threaded solution, which blocks the whole app if a single function blocks, and forces programmers to write spaghetti wrappers around asynchronous call-back hells in a non-functional but GC'ed language? I am really too stupid to get it. "Si…

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…

> Realistically speaking if you're doing CPU intensive tasks then Node is definitely the wrong solution

Here's the answer:

Spawn $(nproc) more Node processes, use IPC if you need to.

Good luck seizing the theoretical performance gains one might see from threading (while not falling victim to diminishing returns related to context switching) in another comparable language.

Re: Yahoo Mail moving to React

#263

Post by edwinnathaniel »

LunaSea wrote: post #242
porker wrote: post #230

Earlier quoted context omitted.

> I'm not sure why you consider the JavaScript ecosystem unstable ? Well I'd say his opening might be the reason: "As the companies I work(ed) for evolve from JS => jQuery => Backbone.JS => Backbone.JS + Marionette => EmberJS, so does my skill have to evolve." It's evolving fast, and this makes it unstable in terms of knowledge and what's being used. Depending on outlook (or age?) this can make it exciting. It's also…

Even though the frameworks evolve quickly in JavaScript, nobody is stopping you with sticking to an "older" one if it works for your project. It's true though that your value as a developer shifts quite fast depending on the trends. But I feel that a fast moving world is merely a consequence of super large communities like the JavaScript one. By "stability" I meant that NPM and Bower are quite reliable. Also, if you…

Are you sure you're in a "fast moving world" as opposed to re-inventing-the-wheel because of one-or-two-edge-cases?

Re: Yahoo Mail moving to React

#264

Post by spion »

loxs wrote: post #20
__mrwhite__ wrote: post #14

Earlier quoted context omitted.

Any particular reason why you feel like server-side JavaScript feels fragile? Also if by DOM manipulation you mean libraries like jQuery, have you tried more declarative approaches found in frameworks like Angular and React?

Few reasons: 1. Cooperative multitasking. Really? In 2014? Hello? 2. Weakest of weak typing. undefined is not a function? Anyone? 3. Everyone can override everything. 4. Conventions, that's the only way you can build software in JS. Anyone know of a person who doesn't break conventions? Having programmed in something like Erlang, which IMHO is the sanest technology available today for doing web, JS feels horrible.

1. Yeah, Erlang beats JS in that regard without contest. Still, its better than and conditions race deadlocks. (Few mainstream platforms solve this really well and Erlang is one of them).

2,3,4. TypeScript, Flow, PureScript add varying degrees of strictness, checking and purity (from low to high, in that order)

Re: Yahoo Mail moving to React

#265

Post by tracker1 »

bad_user wrote: post #135
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…

Facebook Flow or TypeScript - still weak. On require/modules, that's a freaking mess. Ambiguous/unexpected behavior... nothing fixes it. To make matters worse, there's always the promise of some magical library or tool that's going to fix your problems, until you discover that it sucks, or that it is unmaintained, or that it doesn't interoperate with another library and then you're back to search between thousands of…

I prefer straight JS over CoffeeScript/TypeScript/Flow etc...

I don't find require/modules to be too much of a mess.. unless you are using a lot of really large tool-chains with deep dependencies... npm dedupe helps point out problems there.

Breaking your logic into idempotent functional components without side effects as separate files/modules reduces a lot of what can be considered ambiguous or unexpected.

If you work with a functional flow, avoiding OO in JS as much as prudent, you can get a lot done without nearly as much confusion.

For now co/generators/promises get you really far along. In the future await/async will take it farther.

Re: Yahoo Mail moving to React

#266

Post by adamors »

tracker1 wrote: post #258
adamors wrote: post #116

Earlier quoted context omitted.

Yes but if you're using a language that transpiles to Javascript, you might as well use another language all together (for backend programming). Debugging becomes much simpler with a language that doesn't has to turn into something else. For frontend development, a lot of frameworks and libraries only work consistently with Javascript. I've looked at TypeScript for instance, and it indeed looks nice. But it has a bun…

If you write very modular code with good test coverage, the odds of you needing to fire up a debugger are greatly reduced. Regardless of the language you choose. Given JS has first-class functions, and many libraries to follow functional patterns. You can write very stable code, with almost no chance of side effects within a given function/context.

The problem is, that not everyone works on greenfield applications all the time. I never inherited modular, well tested javascript projects.

I did, on the other hand, have to take over cobbled together jQuery, Backbone and Coffeescript applications.

Re: Yahoo Mail moving to React

#267

Post by kxo »

spion wrote: post #251
manish_gill wrote: post #176

Earlier quoted context omitted.

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…

Flow isn't mature enough yet, but even TypeScript eliminates pretty much the entire Wat talk. Also, it compiles to CommonJS, which means it works well with both node and browserify. Yes, we need a blessed, "batteries included" stack for JS made of components that play nicely together. Here is a nice list to get started with (IMO, ymmv) 1. TypeScript or Flow 2. React 3. Promises: bluebird, when or p-promise 4. Observa…

My only problem is with 3.

If you're already at the point where you are utilizing compilation, why not implement a compiler-level async/await solution (probably based off of a loop + a state machine, a la regenerator).

Re: Yahoo Mail moving to React

#268

Post by LunaSea »

edwinnathaniel wrote: post #263
LunaSea wrote: post #242

Earlier quoted context omitted.

Even though the frameworks evolve quickly in JavaScript, nobody is stopping you with sticking to an "older" one if it works for your project. It's true though that your value as a developer shifts quite fast depending on the trends. But I feel that a fast moving world is merely a consequence of super large communities like the JavaScript one. By "stability" I meant that NPM and Bower are quite reliable. Also, if you…

Are you sure you're in a "fast moving world" as opposed to re-inventing-the-wheel because of one-or-two-edge-cases?

I asked myself the same question and although I'm not sure what the answer is, my guess would be that the situation you describe would be valid for any (relatively) new programming language.

It shouldn't be particular to JavaScript or Node.js.

Re: Yahoo Mail moving to React

#269

Post by spion »

barosl wrote: post #52
wildpeaks wrote: post #25

Earlier quoted context omitted.

Paypal recently had an interesting follow-up talk "9 anti-patterns for node.js teams" about what they learnt in the past year. Slides: http://www.slideshare.net/jeharrell/9-antipatterns-for-nodej... Video: https://www.youtube.com/watch?v=6phif2t-wj0

It is surprising to me that they recommend callbacks over promises! I had no idea that promises require higher CPU resources.

Hmm, those are strange results indeed. I would not be surprised if those measurements were made a year ago. Back then, promises were really slow.

But then bluebird came out and changed everything, and many of the other promise libraries followed suit. Most promise libs are now really lightweight (with the only remaining exception being Q).

See https://gist.github.com/spion/6990910 ; http://spion.github.io/posts/why-i-am-switching-to-promises.... ; https://github.com/spion/async-compare/blob/master/latest-re... -

For example, bluebird (and most other promise libraries today) have 2 to 3 times lower overhead than caolan's async and are comparable to the most hand-optimized raw callbacks.

Re: Yahoo Mail moving to React

#270

Post by [deleted] »

loxs wrote: post #92
stepstep wrote: post #67

Earlier quoted context omitted.

All of these are valid points except 1. Node's async IO is one of its strengths. Contrast with Rails, for example, where the standard practice for concurrency is to spawn multiple processes (or, less commonly, threads). How many Rails processes can you fit on one machine? 5-10? Node can handle thousands of concurrent connections, all on a single thread. And when you hit those limits, you can always continue scaling w…

Cooperative vs. Preemptive multitasking is not the same as Light threads vs. OS threads/processes. Erlang (and also Haskell for example) does preemptive multitasking with light threads. And that's what I'm talking about. Yeah, preemptive multitasking may be costly. But as you say, when you have lots of users, most of their tasks are sleeping or waiting for timers. That's where preemptive multitasking excels. You can…

[deleted]
Post reply on HN