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

111–120 of 301 posts

Re: Yahoo Mail moving to React

#111

Post by twerquie »

romaniv wrote: post #107
twerquie wrote: post #94

Earlier quoted context omitted.

I'm no zealot, and don't think these are absolute truths by any means but I've worked extensively on enterprise solutions in both C#/.Net and Node.js and can respond to your points below. 1. It turns out the reactor pattern is a good way to build network servers that scale reasonably well with minimal developer effort. In my experience developers tend to avoid writing threaded code in synchronous languages, and threa…

I think your answers to 2-3 are not real answers. You're not giving an explanation that would convince someone who doesn't share your opinion. You're simply saying that you don't care about there concerns with nothing to demonstrate that your viewpoint is somehow more valid.

I'm just conceding that these argument cannot be won. Tomes have been written and the argument becomes unproductive very quickly. It's like people who believe in God arguing with those who do not. It's not about JavaScript or Node, it's about your entire belief system.

They're both good, in both cases.

Re: Yahoo Mail moving to React

#112

Post by nwienert »

truncate wrote: post #105
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…

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 use any number of libraries to add consistency there. It's incredibly easy to include a JSLint file in your repo and as a git hook to ensure consistent syntax usage. ES6 introduces lots of nice features for writing code, and is usable today with transpilers.

Re: Yahoo Mail moving to React

#113

Post by nwienert »

cmicali wrote: post #96
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…

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…

What complexity does it bring?

I'm writing apps from the ground up using React and I've found the isomorphic bits take <10 lines of code as long as you design for it from the start.

Re: Yahoo Mail moving to React

#114

Post by pkhagah »

stepstep wrote: post #67
loxs wrote: 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…

> All of these are valid points except 1.

I have another counter-point for this as a rails developer tinkering with golang recently. I think Go got this correct in many ways. Having light weight goroutines that can scale well; having good IO which does epoll/libuv style wait in the background transparently when you read/write. Easy to understand multiprocessing language in general. I have no idea why it's not taking off in web development though.

Re: Yahoo Mail moving to React

#115

Post by swah »

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?

For the browser, no. Its native there and that's fine by me. But on the server, yes, I have that feeling.

Re: Yahoo Mail moving to React

#116

Post by adamors »

nwienert wrote: post #112
truncate wrote: post #105

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…

Yes but if you're using a language that transpiles to Javascript, you might as well use another language all together (for backend programming). Debugging becomes much simpler with a language that doesn't has to turn into something else.

For frontend development, a lot of frameworks and libraries only work consistently with Javascript. I've looked at TypeScript for instance, and it indeed looks nice. But it has a bunch of edge cases with Angular and/or Backbone. You're just piling on complexity with these languages.

Re: Yahoo Mail moving to React

#117

Post by syntern »

Todd wrote: post #26
remon wrote: 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…

If you are a C# developer, you'd probably find a Dart-based stack much better.

Re: Yahoo Mail moving to React

#118

Post by marcosdumay »

stepstep wrote: post #67
loxs wrote: 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…

> How many Rails processes can you fit on one machine? 5-10?

Wat?!

By the end of the 90's, people started the "10K project", aimed at adjusting Linux and Apache so that a hight-end machine could support 10k simultaneous Apache threads, all doing IO at the same time. And they were successfull.

That was more than 14 years ago.

Re: Yahoo Mail moving to React

#119

Post by euroclydon »

virmundi wrote: post #53
guard-of-terra wrote: post #23

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, Node has clustering, and there is probably some nifty load-balancer that works with Nginx and Node.

http://nodejs.org/api/cluster.html

Re: Yahoo Mail moving to React

#120

Post by romaniv »

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?

Same here, to a greater extent. Why? At the highest level, because it's a language that was chosen based on a whim (not merit) and is now being extensively worked on and showed down everyone's throats. I like languages, plural. I like new languages. I like to have a choice. (And no, I cannot "simply chose something else" if I have to work with people who say every other choice is invalid by default. And yes, this is the mentality I commonly see.) In a way, JavaScript is the new Java.

The core language (syntax, available directives) hasn't changed much since the time everyone deservedly hated it. Its performance was optimized, it got many more libraries and it is still the only language supported by browsers. But the question is, why all of this applies to JavaScript and not Python/Ruby/whatever?

A lot of its benefits people claim simply weren't around when they chose to stick with it. It's like saying you chose IIS over Apache because of features of C# 5.0 and ignoring the fact that you chose IIS in 2004, where C# 5.0 was not around. It's a dishonest argument.

Speaking of which. How can people claim that JS benefits from the same language running on client and server when 90% of server-side libraries do not work on the client and there are potentially major differences even in core library (e.g. forEach)?

Also, a huge part of JS ecosystem are kludges, crutches and workarounds that make the stack way, way more complex that it should be. (E.g. source maps. Imagine someone minifying PHP for faster parsing and then asking everyone to use some source mapping technology for debugging. They would be laughed out of any conference or discussion.) This mentality permeates everything. I mean, seriously, require directives need to be implemented as a library? Namespace isolation is a closure-based hack? Can you imaging stuff like that being tolerate for any other language?

Post reply on HN