Live data from Hacker News

Yahoo Mail moving to React

slideshare.net

71–80 of 301 posts

Re: Yahoo Mail moving to React

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

Re: Yahoo Mail moving to React

#72
post #17
post #3

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.

You can create an awful UI with any technology.

libaries like Bootstrap make you built less awful UI ,but very generic

Re: Yahoo Mail moving to React

#73
post #68

Earlier quoted context omitted.

I struggled to find anything I liked about javascript. Other than ease of deployment.

First-class functions and closures are nice if you're coming from Java.

Those are in Java now. Always have been, really, with a lot of boilerplate.

Re: Yahoo Mail moving to React

#74
post #26
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.

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 ho…

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

Re: Yahoo Mail moving to React

#75
post #69

Earlier quoted context omitted.

node.js is the new PHP for hip web developers who read HN. It's still a relatively unheard of platform to most people and mocked by a lot as well. I love it though.

Well, if you are like me, who worked with PHP for years, node.js feels nicer to use. Npm alone makes it better than PHP ever was.

NPM is great, haven't used PHP but it blows Python's pip out of the water IMO.

Re: Yahoo Mail moving to React

#76
post #26

Earlier quoted context omitted.

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 ho…

As a C# developer, I too am building isomorphic apps currently in NodeJS (with ReactJS). Then I found out about ReactJS.NET [0] which allows for server-side rendering of ReactJS components from ASP.NET. I haven't had a chance to try it out properly yet but my preliminary test of it made it seem plausible for creating isomorphic apps in ASP.NET. Have you given it a shot? If so, what are your thoughts? [0] http://react…

I've experimented with it. I think it's a great solution if you really want to stay with a uniform stack (as much as is possible, anyway). What I came to realize, though, is that the Razor views were just scaffolding. You would need to re-implement any such scaffolding in your client-side views. The next problem is the router.

Any client-side routes will need to be mirrored on the server if you want isomorphism. This means you're using two routers. Many Node solutions will use different routers on the client and server, but there are a growing number that can be shared.

The router is my biggest stumbling block right now in my road to React. There are a variety. There seems to be a consensus around react-router, but now we have the Yahoo contribution. There are two problems that I'm having. The first is that, if you want to use HTML5 History (instead of the dreaded hash bang), you're kind of on your own. There is usually little documentation on how best to handle this. If you do this, you have to intercept and prevent navigation, but only for the relevant local routes, of course. This is intimately tied to eventing. If you're using React, you'll probably use React events (vs, say jQuery).

The next issue is that most of the examples out there are simplistic. They will show a simple page with one component embedded that swaps out a part of the view. Any real app will require layouts, views, and components. Some of these levels will vary based on routes. ASP.NET has an elegant solution for this. I haven't seen an analogy with React + router.

I think part of my problem is that I'm still ramping up. I'm guessing that this is largely teething pains.

Re: Yahoo Mail moving to React

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

Re: Yahoo Mail moving to React

#78
post #20

Earlier quoted context omitted.

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.

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…

loxs argument (and as an Elixir guy I fully agree with him) is that those options are all terrible. The Erlang VM (BEAM) is extraordinary in how it solves that problem. It's both preemptive and green threads. It supports SMP and clusters across nodes out of the box. I highly recommend taking a look at BEAM and how different it is from everything else out there.

Re: Yahoo Mail moving to React

#79

Earlier quoted context omitted.

I don't think they have mail storage, spooling and sending implemented in node.js. I think they use both PHP before and node.js now as a front tier. And this is okay, it's where node.js shines.

See, this confuses me. From working with Node and understanding its core architectural concept, the single event loop, I find Node's worst use case to be front end development. Server side rendering takes time, even 10 ms. On an single event loop, that is terrible. You can only server 100 request/second due to the 10 ms limit. While it is nice that you can move a request into the backing queue while waiting for the d…

Well...there is the global operator, and it takes into account the entire running "stack of files" - so include your config.php, lib.php wrappers, which in turn include other files for your application/framework, and then use the global $var tag in every function, and you get a reference to a truly global variable.

http://php.net/manual/en/language.variables.scope.php

PHP also has "superglobals"

http://php.net/manual/en/language.variables.superglobals.php

Re: Yahoo Mail moving to React

#80
post #72
post #17

Earlier quoted context omitted.

You can create an awful UI with any technology.

libaries like Bootstrap make you built less awful UI ,but very generic

True, if you adhere to Bootstrap's methods, you'll create a less terrible static UI, but you can still create awful data representation and transitions.
Post reply on HN