Live data from Hacker News

Yahoo Mail moving to React

slideshare.net

191–200 of 301 posts

Re: Yahoo Mail moving to React

#191
post #49

Earlier quoted context omitted.

What framework would you suggest server side?

Disclaimer: I am a full-time Erlang programmer I use several frameworks/libs for different tasks: Webmachine, N2O, Cowboy I don't believe in RoR type of frameworks. I believe in clear separation between server and client. We are steadily moving towards a web of websockets and "one page JS applications". Won't comment on whether that is nice thing or not. I am not sure for myself. For client we are stuck with JS. Suck…

Just to follow up on topic of WhatsApp and Erlang, here is a presentation given at Erlang Factory 2014 about their goals with scaling WhatsApp to billions of simultaneous users.

http://youtu.be/c12cYAUTXXs

Re: Yahoo Mail moving to React

#192
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...

Re: Yahoo Mail moving to React

#193

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.

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/

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.

Re: Yahoo Mail moving to React

#194

Earlier quoted context omitted.

I never worked much with JS, but from my experience I find it hard to imagine writing such a big application in JS. It is so easy to do things wrong in JavaScript. Weak types, global namespace, ambiguous and unexpected behaviours.

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…

I do these things. But will my neighbor do the same?

Re: Yahoo Mail moving to React

#195
post #96

Earlier quoted context omitted.

One argument for one language everywhere is the benefits you get from an "isomorphic" app ( http://nerds.airbnb.com/isomorphic-javascript-future-web-app... ) 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…

Thanks for putting isomorphic in quotes.

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.

Re: Yahoo Mail moving to React

#196

Earlier quoted context omitted.

Out of curiosity, what did you program in before you learned node?

I switched from WPF, C# dev to Angular JS with Typescript and Web API with relative ease and I'm digging it. Typescript definitely helped though. I know I have plenty more to learn, but it's not as shitty as people make it out to be.

If you're using Web API (built on ASP.NET) then you're not using Node, which is a Web server written in Javascript.

But I do think it's cool that someone can transition from WPF to Web development with Angular without feeling too lost. Dynamic Web development used to be a very, very different ballgame from client application development.

Re: Yahoo Mail moving to React

#197
post #91
post #4

What an odd trend. First Netflix moves part of their infrastructure to Node ( 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.

Two reasons - mobile and support. Mobile, because everything on the web is moving towards API-based backends decoupled from the presentation layer. Support, because "everyone" knows how to write JavaScript.

> Support, because "everyone" knows how to write JavaScript.

... badly written JS, sad, unfortunately that's the fact.

Re: Yahoo Mail moving to React

#198
post #62
post #54

Earlier quoted context omitted.

As someone who knows their way around Erlang, it needs some work for more 'average joe' programmers to get much done with it. I'm not talking about the syntax, but some set of libraries or a framework or something that gets people up and running quickly. Chicago Boss is interesting, but it's not very Erlangy (it uses compiler magic). Edit: that said, a big company would certainly have the resources to make Erlang wor…

Sadly, I have to agree :(. This is the weakest aspect of the Erlang ecosystem...

So does this mean Erlang only makes sense if you work for a big company or have a large team to implement it properly? (I'm responding in light of davidw's edit which you may not have seen).

Re: Yahoo Mail moving to React

#199
post #167

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…

Write modules.

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

Re: Yahoo Mail moving to React

#200

Earlier quoted context omitted.

The notion that SPA automatically gives you better user experience is a fallacy. Better UI design gives you better user experience, and good UI design is possible using the classic approach to web development. As an added bonus, you get searchability for free and you don't have to move away from your existing server-side stack.

Single page applications allow for more flexible UI design, and that flexibility allows for lots of potential improvements. Forcibly re-drawing the canvas during transitions is quite limiting, and I don't know any visual or interaction designers who couldn't do a better job without that artificial constraint. Now, whether the benefits of getting rid of that constraint are worth the costs depends entirely on what you'…

You do not have to re-draw the canvas during transitions. Believe it or not, it is possible to do AJAX declaratively and with progressive enhancement. My approach is to develop forms normally, then add a directive that intercepts them via AJAX, "cuts" certain pieces of the target page and "pastes" it into the current page. It is a very simple, generic and flexible approach. The markup looks like this:

  
  
  
Normally, the only thing I need to add to go from non-AJAX to AJAX is submit-to="[CSS Selector Here]". Possibly, some IDs. Everything else works automatically. The library adds a certain attribute to the "pasted" parts, so I can add visual transitions via CSS3. I can use form's action URL to rewrite current URL via push state.
Post reply on HN