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

281–290 of 301 posts

Re: Yahoo Mail moving to React

#281

Post by spion »

tracker1 wrote: post #260
spion wrote: post #251

Earlier quoted context omitted.

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…

Going to make a few points of contention... 1. Not a problem, though I don't use either, I tend to use very small modules (not necessarily via npm, but require'd in my own project, or outside modules) 2. React, and even the Yahoo flux tools are pretty nice. React by itself is less useful. 3. I'd go with es6-promise here, which complies with the spec. I wrote i-promise as a module to give an ES6 compatible promise lib…

Well, observables would just be used as a mechanism to implement a flux-like architecture or decouple various parts of your server-side codebase (making them open to extension). A bit like event emitters, but without the stringly typed event names. I don't think thats evil? [1]

Or they can also be used in place of asynchronous lists (like "object streams"). I find them handy for various tasks :)

Regarding es6-promise, its too minimal for my taste, and missing my favorite feature (provided by bluebird. when and p-promise): long stack traces on (possibly) unhandled errors, which are quite invaluable on the server side when debugging longer chains of events. p-promise has the additional advantage of being a relatively small library which is pretty awesome :)

[1]: example: flux implemented with rxjs: https://github.com/fdecampredon/react-rxjs-todomvc

Re: Yahoo Mail moving to React

#282

Post by disbelief »

davidw wrote: post #205
disbelief wrote: post #198

Earlier quoted context omitted.

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.

Sounds similar to Node.js in that regard then. Lots more boilerplate and conventions you need to develop yourself.

Re: Yahoo Mail moving to React

#283

Post by xtrumanx »

Todd wrote: post #234
xtrumanx wrote: post #124

Earlier quoted context omitted.

I haven't really given the routing issue too much thought regarding ReactJS.NET. I assumed it would work just as well as my isomorphic apps in NodeJS; one route in server-side land that handles all URLs and returns a View that contains the server-side rendered React app. I maybe missing something for why that wouldn't work in ASP.NET land but like I said, I haven't worked with it that much. react-router is all right…

It looks like they may have recently solved the issue with async rendering on the server (4 days ago): https://github.com/rackt/react-router/wiki/Announcements#wha... One of the exciting things about React, and Node.js more generally, is how quickly it is moving. This usually means that there are sharp edges and rough patches and that's been my experience so far. I'll take that any day over a backwater that gets no a…

Thanks for the heads up. The link seems to redirect back to the project page but I found its contents via Google's cache.

It's awesome that they've apparently solved the issue. Haven't quite grokked the example but will study it further.

Re: Yahoo Mail moving to React

#284

Post by nutate »

findjashua wrote: post #275
neftaly wrote: post #228

Earlier quoted context omitted.

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

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.

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/ without diving into a fully architectured SPA.

Re: Yahoo Mail moving to React

#286

Post by Todd »

xtrumanx wrote: post #283
Todd wrote: post #234

Earlier quoted context omitted.

It looks like they may have recently solved the issue with async rendering on the server (4 days ago): https://github.com/rackt/react-router/wiki/Announcements#wha... One of the exciting things about React, and Node.js more generally, is how quickly it is moving. This usually means that there are sharp edges and rough patches and that's been my experience so far. I'll take that any day over a backwater that gets no a…

Thanks for the heads up. The link seems to redirect back to the project page but I found its contents via Google's cache. It's awesome that they've apparently solved the issue. Haven't quite grokked the example but will study it further.

Yes, that was strange. I noticed it was removed shortly after I posted my comment. I can only assume they want to clean up the examples in the announcement and integrate them into the docs. Here's where I saw the original link:

https://twitter.com/ryanflorence/status/536940145241763840

Re: Yahoo Mail moving to React

#287

Post by Todd »

eric_bullington wrote: post #74
Todd wrote: 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…

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

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.

Re: Yahoo Mail moving to React

#288

Post by bad_user »

igouy wrote: post #257
bad_user wrote: post #139

Earlier quoted context omitted.

That's not an objective comparison, since Javascript has been optimized to deal with arrays and numbers, as that's one main use-case that people have in the browser. Take a look at the source code and tell me if that's the kind of code that you write.

So it's not an objective comparison because the V8 implementation performs well? :-)

No, it's not an objective comparison because that's not the kind of code that we deal with in 90% of the cases, except when doing games, but then again plain Javascript is shitty for doing games, unless you develop in a strict subset that isn't meant for humans.

Re: Yahoo Mail moving to React

#289

Post by modarts »

Sawbones wrote: post #207
DigitalSea wrote: post #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 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…

You have a very topical understanding of how to structure an app with react then.

Re: Yahoo Mail moving to React

#290

Post by remon »

arms wrote: post #208
remon wrote: post #85

Earlier quoted context omitted.

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)

I didn't argue JavaScript is #1 on the server side, simply that it's the language with the most traction when it comes to that group of languages (of which Python is no part by the way, PHP and Ruby are though). I wouldn't touch JavaScript on the server side with a 10 feet pole.
Post reply on HN