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

161–170 of 301 posts

Re: Yahoo Mail moving to React

#161

Post by WorldWideWayne »

dschiptsov wrote: post #89

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. "Si…

It's not, but having a single language to glue together all of the other ones is a pretty good idea. That's what I use Node for. With the addition of Edge.js I can run any .NET language right in the same runtime as Javascript (or, run Node inside my .NET app).

Re: Yahoo Mail moving to React

#162

Post by oceanstone »

mncolinlee wrote: post #140

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.

Your comment reminded me of this blog from Netflix: http://techblog.netflix.com/2013/01/reactive-programming-at-...

Re: Yahoo Mail moving to React

#163

Post by woah »

rtpg wrote: post #44
__mrwhite__ wrote: post #14

Earlier quoted context omitted.

Any particular reason why you feel like server-side JavaScript feels fragile? Also if by DOM manipulation you mean libraries like jQuery, have you tried more declarative approaches found in frameworks like Angular and React?

not OP, but some issues I get with JS are mainly due to refactoring. I think the tooling isn't as mature as in other languages, and moving around code has proven difficult (oh the joys of `this`!) Software development is one part creation, one part understanding existing software, and one part changing existing stuff. Javascript has proven a bit difficult on the last part.

This is likely an issue caused by code that is too monolithic in nature. Writing idiomatic node code involves making many small npm modules. Refactoring becomes very easy within the tiny code base of a module, and moving them around is a matter of require them somewhere else.

Re: Yahoo Mail moving to React

#164

Post by oceanstone »

meowface wrote: post #154
oceanstone wrote: post #145

Earlier quoted context omitted.

> That's not an objective comparison, since Javascript has been optimized to deal with arrays and numbers What were your thoughts on the regex-dna benchmark?

V8 is able to compile PCREs directly into efficient machine code (in some cases at least), CPython is not. See: http://blog.chromium.org/2009/02/irregexp-google-chromes-new...

Thanks for the insight!

Re: Yahoo Mail moving to React

#165

Post by woah »

tunesmith wrote: post #144

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.

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.

Re: Yahoo Mail moving to React

#166

Post by Kiro »

loxs wrote: post #123
general_failure wrote: post #93

Earlier quoted context omitted.

Thanks for your suggestion, I will definitely look into erlang. I have tried to look into it but I have found it quite unapproachable. You have to be really motivated on your own to learn it. Everytime someone points a erlang, they bring up whatsapp. And everytime they do that, I tell them facebook the company that owns it is a php shop (Atleast, that was the core driver. Things might be different today with hiphop).

Writing something in PHP made sense in 2004. Although Erlang was around at the time, it wasn't at all well known. And no, you are not absolutely right, Facebook is not a PHP (only) shop. Their chat backend is in Erlang and that's a much bigger tell-tale than their legacy code. Also, a lot of us Erlangers speculate that Facebook bought WhatsApp (not only but also) because of their huge infrastructure know-how and (Erl…

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

Re: Yahoo Mail moving to React

#167

Post by woah »

fideloper wrote: post #55

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.

Re: Yahoo Mail moving to React

#168

Post by dan15 »

Todd wrote: post #76
xtrumanx wrote: post #51

Earlier quoted context omitted.

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…

Hey, I'm the developer of ReactJS.NET. Thanks for trying it out!

> Any client-side routes will need to be mirrored on the server if you want isomorphism. This means you're using two routers.

A while back I worked on a library called [RouteJs](http://dan.cx/projects/routejs) that would expose certain ASP.NET MVC routes to JavaScript. The use case here was to have a way to build URLs client-side rather than hard-coding them (similar to the `Url.Action` helper in Razor) but a similar technique could be used to do client-side routing. That's actually a really good feature request for RouteJs :)

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

Yeah, that's true. I have one page using server-side rendering in production, and it's a page on my site/blog: http://dan.cx/socialfeed.htm. It's also a simple page but I used it for building the original proof-of-concept for server-side rendering. I haven't actually tried using ReactJS.NET to build a single-page app, but I think that would be an interesting use case.

Re: Yahoo Mail moving to React

#169

Post by CitizenKane »

dschiptsov wrote: post #89

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. "Si…

It's honestly not as much of an issue as it's often made out to be. There are a ton of ways to manage asynchronous code out there including but not limited to all the various promise libraries such as when.js(https://github.com/cujojs/when), q (https://github.com/kriskowal/q), and bluebird (https://github.com/petkaantonov/bluebird). Not to mention the Async library (https://github.com/caolan/async) which is full of tools to help manage it.

As for blocking, it's something you deal with. Realistically speaking if you're doing CPU intensive tasks then Node is definitely the wrong solution. However, if you're doing tasks that are IO oriented then Node is fantastic.

Re: Yahoo Mail moving to React

#170

Post by serve_yay »

marknutter wrote: post #134
mygreetings wrote: post #9

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?

Are you kidding? I can't remember the last time a node.js or javascript related article on the HN homepage didn't have a barrage of highly up-voted "javascript sucks" themed comments. I'm beginning to wonder the opposite - is there anyone like me in the community that doesn't have a problem liking javascript?

No kidding.
Post reply on HN