
Yahoo Mail moving to React - rfc791
http://www.slideshare.net/rmsguhan/react-meetup-mailonreact
======
DigitalSea
I am surprised at all of the hate that Yahoo! is receiving for this, in the
comments section of Hacker News (not surprisingly). This is great in my
opinion, I think React.js is definitely the future of SPA's especially when
combined with the Flux architecture. As someone who has been using React on a
daily basis for the last few months, I have a severe man-crush on it. It just
makes so much sense, combined with something like Browserify and working with
a isomorphic workflow (shared codebase front and back-end).

And those who say Yahoo! are just jumping onboard the React hype train or
Node.js hype train, you have it all wrong. Yahoo! have been using Node.js for
the last few years, in-fact early 2010 is around the time Yahoo! engineers
started playing with Node.js, long before it was considered mainstream cool or
being used really in any high-profile scale environment.

It is rare that a company the size of Yahoo! truly ever embraces moving at
this kind of pace and embracing new open source technologies, languages,
frameworks and libraries. Now that Yahoo! have openly declared their use of
React on such a large scale, expect it to explode even more so in 2015. For an
open source project that is a little over a year old, React is getting the
kind of user-base and adoption that most open source projects can only dream
of having.

This news excites me. I honestly cannot wait to see how it all turns out.

PS. I have noticed a few people in the comments section getting confused.
Yahoo! Mail is NOT using React just yet. The current mail product is still
using YUI and plain HTML/Javascript. If you read through, it mentions 2015...

~~~
Sawbones
I really need someone to explain to me what they love so much about React.js.
I tried it out and I absolutely hated the way components didn't understand
their relation with other components. I had to chain a callback all the way
down to my ListItem Component just so it could set which item was selected in
the component and let other components know that. If you ever end up adding
another parent component you have to rewrite all those top level components to
pass that information down.

~~~
rakoo
That's because you used React alone, which works as a top-down view engine. If
you want to modify something in the view, you have to go back to the top and
modify the model. Instead of doing it manually, Facebook has created the Flux
architecture to help you scale this process efficiently.

~~~
marknutter
So Facebook created an architecture to solve a problem their new web framework
introduced?

~~~
neftaly
No, they created an architecture and decoupled their web framework from it.

~~~
findjashua
Which was a poor decision, imho. Using React only makes sense with Flux, why
separate them? Furthermore, the examples on React's docs use the pass-down-
the-event-handlers madness, instead of using Flux. React+Flux is a good
solution, but the documentation leaves a lot to be desired.

~~~
nutate
React components can be brought into any architecture. Using them with flux
certainly simplifies many things, but by the same token, flux apps can be
written using other libraries (react based like om, or even full frameworks
like angular). The decoupling is good. It lets you try out a component from
[http://react.rocks/](http://react.rocks/) without diving into a fully
architectured SPA.

------
dschiptsov
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. "Single language for a whole stack" is a
pretty stupid Java-sque argument, a naive assumption that one single language
is good for all kinds of tasks.

~~~
cmicali
One argument for one language everywhere is the benefits you get from an
"isomorphic" app ([http://nerds.airbnb.com/isomorphic-javascript-future-web-
app...](http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/))

Sharing code between client and server lets reduce duplication and use the
same templating/rendering on both sides. Fits very well with complex single-
page apps.

That said, I'm not sure there are that many apps that really need this vs. the
tradeoffs you have to make going all-in on JS and the complexity this can
bring.

~~~
codygman
Thanks for putting isomorphic in quotes.

~~~
magicalist
I don't know why it bothers me so much, but it really does. What happened to
just saying that the same code is run on the client and server? Avoids the
jargon, doesn't make math nerds mad, isn't that much longer, and says exactly
what you mean.

------
cageface
I've been a Javascript and Node skeptic for years now but I think the tide is
finally turning. So much time and energy has been poured into making JS better
that it's finally starting to pay off. Javascript with all the ES6
enhancements is really not a bad language. The runtime performance is already
very good and continually getting better. Tools like Typescript and Flow make
dealing with larger code bases much easier.

I don't think the other "scripting" languages like Ruby, Python, and PHP stand
much of a chance against it in the longer term. They just don't have the
resources to compete.

~~~
ChrisAntaki
> 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 of browser performance being highly
invested in by Google, Mozilla, etc.?"

[1]
[http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=python3&data=u64)

[2]
[http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=yarv&data=u64)

[3]
[http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=php&data=u64)

~~~
meowface
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, Rubinius/RuJIT, HHVM,
and LuaJIT. LuaJIT and V8 would likely still come out on top due to the amount
of work and sheer excellent engineering put into the compilers (and in
LuaJIT's case, also the interpreter), but PyPy's performance should be a lot
better than CPython's for these benchmarks.

I also imagine (though am mostly speculating) that a benchmark involving a
full-stack frontend framework like Angular or Ember, with hundreds or
thousands of JS objects and lots of DOM manipulation, should put V8's
performance a bit closer to CPython's.

~~~
ChrisAntaki
> I also imagine (though am mostly speculating) that a benchmark involving a
> full-stack frontend framework like Angular or Ember, with hundreds or
> thousands of JS objects and lots of DOM manipulation, should put V8's
> performance a bit closer to CPython

Interesting idea! How would we make a version of the benchmark for CPython
though?

~~~
meowface
You couldn't do the DOM parts, but you could compare Python dicts with
Javascript objects, and compare performance when there are a lot of heap
allocations and GC calls.

------
remon
What an odd trend. First Netflix moves part of their infrastructure to Node
([https://news.ycombinator.com/item?id=8631022](https://news.ycombinator.com/item?id=8631022))
and now Yahoo is doing something similar. Node.js is great but I don't think
huge enterprise systems for some of the largest brands in the world are
necessarily the best fit. I wish they'd provide some insights on why they're
making that particular move.

~~~
Todd
Speaking from personal experience, I'm reluctantly moving from my favorite
stack (C# MVC) to Node.js in order to be able to build an isomorphic SPA in
the most straightforward way. Node is the stack of choice for JS and the
obvious choice if you want to render on the client _and_ the server using as
much shared code as possible.

That said, you're still free to develop your API using your favorite
technologies. To be honest, this is where the heavy lifting is, anyway, so it
makes sense to have stronger typing, richer data types, etc. at this level.

~~~
eric_bullington
>...your API...is where the heavy lifting is, anyway, so it makes sense to
have stronger typing, richer data types, etc. at this level.

I've had the opposite experience with the SPA projects I've worked on, one of
them pretty large.

With the possible exception of authorization/authentication, the API for all
my projects has been pretty straightforward, whereas the client-side app has
been where I've missed stronger typing and rich data types most acutely, to
the point where I've been actively evaluating compile-to-js alternatives with
a better/safer type system.

However, with the advent of Facebook's Flow, I might just stick with JS.

~~~
Todd
I guess what I meant was that there can be significant data manipulation at
the API level, and this calls for more language and runtime support.

Agreed that client code can become very complex. It's one of the reasons I
avoided doing too much on the client in the past. My solution to this has been
to use TypeScript, which is fantastic for solving this sort of problem. Yes,
it moves away from prototypal inheritance. It also doesn't play nice with JSX.
It's still hugely worth it for me. I haven't tried Flow but it looks like it
addresses the same problems.

------
mygreetings
Little bit off topic but is there anyone like me in community having a problem
with liking javascript?

I have worked with javascript for years but it was always for DOM
manipulation. When it comes to building an app with javascript, i feel like it
is too fragile to depend on.

Anyone can help me to get rid of this feeling?

~~~
romaniv
Same here, to a greater extent. Why? At the highest level, because it's a
language that was chosen based on a whim (not merit) and is now being
extensively worked on and showed down everyone's throats. I like languages,
plural. I like new languages. I like to have a choice. (And no, I cannot
"simply chose something else" if I have to work with people who say every
other choice is invalid _by default_. And yes, this is the mentality I
commonly see.) In a way, JavaScript is the new Java.

The core language (syntax, available directives) hasn't changed much since the
time everyone deservedly hated it. Its performance was optimized, it got many
more libraries and it is still the only language supported by browsers. But
the question is, why all of this applies to JavaScript and not
Python/Ruby/whatever?

A lot of its benefits people claim simply _weren 't around_ when they chose to
stick with it. It's like saying you chose IIS over Apache because of features
of C# 5.0 and ignoring the fact that you chose IIS in 2004, where C# 5.0 was
not around. It's a dishonest argument.

Speaking of which. How can people claim that JS benefits from the same
language running on client and server when 90% of server-side libraries do not
work on the client and there are potentially major differences even in core
library (e.g. forEach)?

Also, a huge part of JS ecosystem are kludges, crutches and workarounds that
make the stack way, way more complex that it should be. (E.g. source maps.
Imagine someone minifying PHP for faster parsing and then asking everyone to
use some source mapping technology for debugging. They would be laughed out of
any conference or discussion.) This mentality permeates _everything_. I mean,
seriously, require directives need to be implemented _as a library_? Namespace
isolation is a closure-based hack? Can you imaging stuff like that being
tolerate for any other language?

~~~
woah
Are you kidding me? Source maps allow you to debug preprocessed as well as
minified code. This allows seamless integration of multiple languages into the
same ecosystem, libraries, etc.

~~~
romaniv
You develop a language that is sent to the client in plain text. Then you
write a lot of code in it. Then you realize that with so much code, file
transfers take too long. You write a utility to strip out spaces and comments,
as well as change variable names so files are smaller. Okay, so now you have
_unreadable plaintext files_. After juggling minified and unminified version
of the same code for some years you realize that debugging like that sucks.
You develop a new format that allows you to map minified and unminified files.
This format requires support on the browser side, as well as in the
minification utility, and it also requires the author of the minified library
to provide you with two additional files. You declare victory and pat yourself
on the back. The whole process only takes a few years.

Meanwhile, people debugged _binaries_ for several decades before your language
even been developed.

Do you see anything wrong with this picture?

~~~
tracker1
It seems to me, that without linking/debugging tools for {LANGUAGE_X} all your
debugging would give you would be assembly symbols.

------
mncolinlee
I see a ton of discussion about the NodeJS decision and almost nothing about
the more interesting industry paradigm shift to reactive programming and using
functional-style programming in an imperative language.

They're joining the likes of Facebook, Netflix, Square, Microsoft, Instagram,
Khan Academy, SoundCloud, Trello, New York Times, and others in adopting
reactive extensions.

~~~
klochner
Yahoo is moving to the React javascript library. The "react" in React js does
not refer to reactive programming in the "Reactive Manifesto"[1] sense.

    
    
        [1] http://www.reactivemanifesto.org/

~~~
delluminatus
They are also moving to a Flux-inspired application structure which is
supposedly very similar to functional reactive programming, which is what the
OP was referencing.

------
glifchits
Yahoo's React/Flux projects mentioned at the end are intriguing. I have tried
implementing Flux architecture in an app and found it really tedious and
boilerplatey. I'm still looking out for well-implemented Flux dispatcher
libraries.

[https://github.com/yahoo/dispatchr](https://github.com/yahoo/dispatchr)

[https://github.com/yahoo/routr](https://github.com/yahoo/routr)

[https://github.com/yahoo/flux-router-
component](https://github.com/yahoo/flux-router-component)

~~~
ericclemmons
Me too. Reflux solved it for me and simplified things considerably!

[https://github.com/spoike/refluxjs](https://github.com/spoike/refluxjs)

------
jameswragg
Here's the associated Yahoo Engineering blog post that goes with the slides.
[http://yahooeng.tumblr.com/post/101682875656/evolving-
yahoo-...](http://yahooeng.tumblr.com/post/101682875656/evolving-yahoo-mail)

------
bsimpson
I was hoping to see a conversation around the points addressed in the slides
(e.g. how to handle async data in Flux). Instead, it's a bunch of neckbeards
whining about people using Node.

~~~
skeletonjelly
What's with the neckbeard shaming?!

But seriously you're on HN and you're upset about people arguing/discussing a
web technology? I don't even see one mention of "m'lady"

------
untilHellbanned
I can't make arguments about Node's technical abilities, but I like that big
companies are throwing more of their weight behind Javascript.

I think Javascript is fun and easy to use. That's good enough for me.

That it helps preserve balance with iOS and Android in the "software eating
the world" conversation, is a bonus.

------
z3t4
With the Opera browser it takes over a second to load the GUI whenever I click
something, and the overall design looks like it has been made by someone
making his/her first homepage. No wonder they decided to use something that
encourage in-line HTML where code and design get entangled like a pile of
spaghetti - making it almost impossible to maintain.

In the last years JavaScript has exploded with new frameworks and "compile to
JS languages". But I have yet seen anything close to usable. Maybe it's
because I've become "speed blind" after coding JS for over 15 years. I do not
see all the problems ppl see in JavaScript, until I look at code written by
beginners that seem to use every framework out there, and over-complicate the
code, and naming everything with one letter variables and the name of their
favorite pizzas.

------
dyeje
It's funny that this showed up on the front page, because yesterday I logged
into an old Yahoo email account for the first time in a few years and was
absolutely astounded at how awful the UI was.

~~~
owenversteeg
The UI has almost literally nothing to do with the backend technologies.

~~~
mawburn
Unless you're unfortunate enough to be working GWT or something similar.

------
fideloper
The exciting part of this for me would be around improvements in Yahoo -
removing old cruft code. There's lot of strangeness and/or flat out errors I
run into on Yahoo regularly. Any improvement in that regard could be a big
benefit.

On the topic of JavaScript - I love Node as a glue. For larger applications -
I just don't know how to structure (architect) a large application on a
language like JS. Maybe that's just my ignorance.

~~~
woah
Write modules.

~~~
edwinnathaniel
That's like saying write classes and methods. Not enough.

~~~
woah
Yea, I'm not saying it's a miracle cure, but in general I have found the
following to be useful:

1) Break any functionality possible into a separate npm module - not just a
separate file with module.exports. Keep the npm module small and break it up
further if it gets too big.

2) This module will be small enough that it is trivial to debug, refactor,
test, and document. If it gets to a size where these tasks are hard for any
reason and you wish for strong typing or something, the module is too big.

3) Please make sure that you do test and document the module. This will make
your team way faster in the future.

~~~
spion
I don't know, I kinda wish for strong typing even in smaller modules.

[https://github.com/doxout/promise-
observer](https://github.com/doxout/promise-observer)

and its statically verified documentation as well (therefore never goes out of
date)

------
ownedthx
Moving to node can be in part a decision to attract fresh talent, as well as
keep the current team interested and motivated.

------
colinramsay
Yahoo seems to be championing React more than Facebook! With the flux-router-
component they are trying to solve something that FB hasn't really addressed
and it shows that they're actively trying to share the solutions to practical
problems people come across when working with Flux.

------
tunesmith
Just curious, what are the reasons for 'isomorphic' apps these days? SEO used
to be the big reason, but since google and bing can now render most
javascript, and since you can use pushState for SEO, that's not really a
sufficient reason anymore.

~~~
woah
Speed on first load I'm guessing? Compatability with screen readers and
readability type things? There are many reasons, and it is simply conceptually
better.

------
vamur
I wonder if the move is the reason Yahoo Mail has become even slower than
before.

~~~
scholia
Every time I use Yahoo email in a browser, which isn't often, it's gotten
worse. I suspect there's more to it than that...

------
ComNik
Is finding Clojure people that hard (honest question)?

The Clojure + ClojureScript approach has many more batteries included. You get
all the benefits of reusing the codebase on both sides of the fence while the
language is solving the "Transactional Store", efficient dirty checks, nice
server-side concurrency primitives and many unrelated problems for you.

~~~
arms
As someone that's recently started working with Clojure (and soon
ClojureScript), I wonder the same thing. My first guess is that people are
unfortunately and unjustly turned off by its Lisp pedigree.

I've been using and enjoying React and am excited to learn more about Reagent.
It seems like Clojure + Reagent will make development quicker and more
enjoyable.

------
adamors
Considering how awful Yahoo Mail has become, I guess they're just throwing
things at the wall and seeing what sticks.

------
wildpeaks
Yahoo also had slides about Isomorphic Flux / Dispatchr two weeks ago if you
want more infos on how they're using React:
[https://speakerdeck.com/mridgway/isomorphic-
flux](https://speakerdeck.com/mridgway/isomorphic-flux)

------
bitL
I find it funny as Yahoo has Netty which is far better performing and more
capable than node.js...

------
somefoobar
Anyone have more insight on why TJ Holowaychuk left Node?

[https://medium.com/code-adventures/farewell-node-
js-4ba9e7f3...](https://medium.com/code-adventures/farewell-node-
js-4ba9e7f3e52b)

Anyone experience the same?

~~~
spion
I think that his main issue is/was that node isn't robust enough. I agree, but
personally think that promises largely solve that issue. Streams are still a
bit icky though.

He also says that node isn't moving fast anymore, which is unfortunately true.
The node core team was stuck trying to release 0.12 for quite a while because
of some significant changes to internals (V8, AsyncListener). Once 0.12 is
out, things should be much easier. On the plus side, the ecosystem is still
moving at the same speed which is pretty great, and JS gets new advanced
tooling every day: typescript, flow, 5 (!) es6 compilers...

------
dingdingdang
Node is a weird choice for Yahoo and Netflix: at least it might see the base
Node package being improved significantly which is always nice :)

------
mhd
But it's still going to be fake desktop app, right? It seems Google is the
only one to buck this trend.

------
callahad
Slide 11: Even Yahoo's Engineering Manager for Mail crops the ads out their
own product screenshots. :(

~~~
imanolov
Yahoo Mail Plus doesn't have ads. All Yahoo employees use Yahoo Mail Plus.

~~~
redonkulus
That's not true. We get the ads too :)

------
__mrwhite__
Would be interesting to see some performance benchmarks in comparison to
previous iterations.

------
serve_yay
"The age of large platform libraries is over."

Boy oh boy do I wish that were the case.

------
matobago
React is not even stable yet...

------
svs
Since when has what Yahoo Mail does become relevant again?

------
peterwwillis
Welp, time to find a more stable/sane mail host.

------
notastartup
Do you guys think that we are now moving into a new trend on the client side
now? React + Flux vs. Angularjs, Backbone.js?

It seems that every job, even backend positions, require Angularjs or
Backbone.js knowledge. Having largely ignored the two and hoping they would
die, I am ready to learn React + Flux to accelerate to this cause.

