Live data from Hacker News

Yahoo Mail moving to React

slideshare.net

201–210 of 301 posts

Re: Yahoo Mail moving to React

#201

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…

You assume everybody uses these tools... in unity, harmony, and applying the best practices (that are not established yet). You assume all libraries in JS is mature, well-supported, and will be there in the next 4 years at least. I echoed other comments: JS ecosystem is unstable and confusing at the moment. Case and point: EmberJS. I have to use ember-cli, npm, bower, and broccoli. Some of them overlap.

None of those overlap. NPM is used for build tools along with broccoli, and bower is used for application code. Ember cli packages them together.

Re: Yahoo Mail moving to React

#202
post #68

Earlier quoted context omitted.

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.

> Always have been, really, with a lot of boilerplate.

Many uses of first-class functions is for reducing boilerplate to begin with.

Re: Yahoo Mail moving to React

#203

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…

Why, it's nice? Throw several worker processes in and you can easily handle 1000 rps per VM.

And no, you don't really need global variables in frontend that much; and backend PHP programs (which you should not do of course) have long-lived global variables.

Re: Yahoo Mail moving to React

#204

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/routr https://github.com/yahoo/flux-router-component

I'd also like to throw in a vote for Reflux. https://github.com/spoike/refluxjs

Re: Yahoo Mail moving to React

#205
post #62

Earlier quoted context omitted.

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

You can do web stuff in Erlang. It's just that it's not like Rails, where you start it up and it's easy to do so much with so little code. Since there's not as much infrastructure, you have to do more yourself.

That can still be worth it, given the advantages the run time gives you, but I think you'd really want to know exactly what you're doing.

Re: Yahoo Mail moving to React

#206
post #186
post #166

Earlier quoted context omitted.

> Their chat backend is in Erlang Not true anymore. They switched away from Erlang because of reliability and scaling problems. So saying that mega-user server side is a solved problem because of Erlang feels like a stretch.

What did they switch to? Source?

http://www.quora.com/When-did-Facebook-switch-away-from-usin...

Re: Yahoo Mail moving to React

#207

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

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.

Re: Yahoo Mail moving to React

#208
post #85

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

I think in this instance JavaScript has to compete with Java, C#, go, erlang, etc. rather than the other "scripting" languages. I don't think many would argue JavaScript isn't comfortably #1 within that domain.

I'm genuinely curious why you think JavaScript is comfortably #1 within the domain of Python, Ruby and PHP. I've been writing (client side) JavaScript for a very long time, and I generally enjoy it, but I don't see myself abandoning Python on the server side for JavaScript anytime soon.

(edited for clarification)

Re: Yahoo Mail moving to React

#209
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…

>The downside of Node's approach is callback hell.

Have you used Async.JS? In my experience, it has always solved my deep callback problems.

Re: Yahoo Mail moving to React

#210
post #180

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.

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.

Post reply on HN