Yahoo Mail moving to React • Hacker News Board

Re: Yahoo Mail moving to React

#271

Post by tracker1 » Thu, Nov 27, 2014, 12:46 AM UTC

peterwwillis wrote: post #229

LunaSea wrote: post #214

Earlier quoted context omitted.

I'm not sure why you consider the JavaScript ecosystem unstable ? JS has: - awesome dependency management systems like NPM and Bower - awesome task runners like Grunt and Gulp - NPM has thousands of plugins, more than Java's Maven and Ruby Gems [1] - Github badge support for builds, test coverage, dependency versions and NPM - Close second best StackOverflow support behind Java (without taking into account Node.js) […

'Most modern' ecosystem? That's likely, though it's honestly got the same things as every other programming ecosystem. I think the Perl ecosystem might be the most 'complete' programming ecosystem that exists today, in terms of implementing modern aspects of a programming ecosystem. 'Most stable' ecosystem? How do you figure that? It's only been around a short while in its current form. Other languages have had their…

I'm not as familiar with CPAN, but how is NPM significantly different?

As someone who used JS server-side from Netscape Livewire, to ASP JScript and even via Synchronet, and other JS runtimes... I've always appreciated the core language. Long before "The Good Parts" because Crockford only got a lot of coverage for what I already knew. Same goes for some recent adjustments regarding Object.create (and even inheritance chains in general).

JS at it's core is a decent language. ES5/ES6 enhancements make it very usable. Currently developing against Node 0.11.x --harmony, with a an es6ify for browser support. Given Node's very good async i/o interfaces, I've written a lot of bridges the past few years between systems that have trouble communicating directly.

Namely SOAP providers are a pain to consume in general a lot of the time. Not a problem to create a JSON endpoint in node that runs it fine. Need to process a huge XML or CSV file... Node is actually pretty nice... and can generally ship the final data where you need it.

Node is imho the ultimate service middle-ware... And to me, this extends to being the servers/services that web applications talk to... relaying to other backend systems/databases.

Re: Yahoo Mail moving to React

#272

Post by findjashua » Thu, Nov 27, 2014, 12:47 AM UTC

nostrademons wrote: post #243

findjashua wrote: post #173

Earlier quoted context omitted.

I used to think the same way, but trying out a non-SPA site really feels jarring now. The intermittent blank screen and the 2 second wait period makes for a shit user experience. I'm much more used to the fluid desktop-grade UI. My only gripe with SPA was the initial load-time (looking at you Gmail), but with virtual-dom, being able to generate the html on the server gives you the best of both worlds.

You don't have to go SPA to avoid the page reload. AJAX works just fine with regular webpages as well, judiciously applied on the most latency-sensitive actions. BTW, you're posting this on Hacker News, which is the ultimate in retro Web-1.0 technology. Heck, it even uses tables for layout.

SPAs use Ajax to sync data with the server, but the templates/assets are on the client already. In a regular webpage, Ajax would have to pull the templates for the new components as well.

I think this is what Gmail does, though it still takes forever for the initial load. Anyway, I can see this becoming a complicated mess very quickly, and find Ractive/React to be much simpler solutions.

As for HN, I doubt anyone comes to HN for the design. PG and YC's brand helped create a solid community with good content and good discussions, which is what keeps bringing us back. But let's call a spade a spade - the UI design here is a joke, even more so considering that its target demographic is the tech community.

Re: Yahoo Mail moving to React

#273

Post by findjashua » Thu, Nov 27, 2014, 12:48 AM UTC

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…

That's because React only makes sense if used with Flux. Otherwise just use Ractive.js - components can communicate with each other via events, so you don't have to pass event handlers down the hierarchy.

Re: Yahoo Mail moving to React

#274

Post by tracker1 » Thu, Nov 27, 2014, 12:49 AM UTC

romaniv wrote: post #217

woah wrote: post #151

Earlier quoted context omitted.

Are you kidding me? Source maps allow you to debug preprocessed as well as minified code. This allows seamless integration of multiple languages into the same ecosystem, libraries, etc.

You develop a language that is sent to the client in plain text. Then you write a lot of code in it. Then you realize that with so much code, file transfers take too long. You write a utility to strip out spaces and comments, as well as change variable names so files are smaller. Okay, so now you have unreadable plaintext files . After juggling minified and unminified version of the same code for some years you reali…

It seems to me, that without linking/debugging tools for {LANGUAGE_X} all your debugging would give you would be assembly symbols.

Re: Yahoo Mail moving to React

#275

Post by findjashua » Thu, Nov 27, 2014, 12:51 AM UTC

neftaly wrote: post #228

marknutter wrote: post #223

Earlier quoted context omitted.

So Facebook created an architecture to solve a problem their new web framework introduced?

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.

Re: Yahoo Mail moving to React

#276

Post by tracker1 » Thu, Nov 27, 2014, 12:54 AM UTC

twerquie wrote: post #94

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.

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…

An addendum to #1... node's i/o tooling and other libraries do run multiple threads against a pool, listening for events, then resolving those listeners into the event-loop. The main JS/v8 event-loop is single threaded.

Re: Yahoo Mail moving to React

#277

Post by spion » Thu, Nov 27, 2014, 12:56 AM UTC

woah wrote: post #220

edwinnathaniel wrote: post #199

Earlier quoted context omitted.

That's like saying write classes and methods. Not enough.

Yea, I'm not saying it's a miracle cure, but in general I have found the following to be useful: 1) Break any functionality possible into a separate npm module - not just a separate file with module.exports. Keep the npm module small and break it up further if it gets too big. 2) This module will be small enough that it is trivial to debug, refactor, test, and document. If it gets to a size where these tasks are hard…

I don't know, I kinda wish for strong typing even in smaller modules.

https://github.com/doxout/promise-observer

and its statically verified documentation as well (therefore never goes out of date)

Re: Yahoo Mail moving to React

#278

Post by tracker1 » Thu, Nov 27, 2014, 1:01 AM UTC

woah wrote: post #163

rtpg wrote: post #44

Earlier quoted context omitted.

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.

Not just via npm, but structuring your project via directory/file hierarchies that limit the amount of work in one file/module.

Avoiding the use of OO contexts and this helps a lot in terms of avoiding side effects, and improving testing and predictability as well.

Re: Yahoo Mail moving to React

#279

Post by spion » Thu, Nov 27, 2014, 1:04 AM UTC

somefoobar wrote: post #213

Anyone have more insight on why TJ Holowaychuk left Node? https://medium.com/code-adventures/farewell-node-js-4ba9e7f3... Anyone experience the same?

I think that his main issue is/was that node isn't robust enough. I agree, but personally think that promises largely solve that issue. Streams are still a bit icky though.

He also says that node isn't moving fast anymore, which is unfortunately true. The node core team was stuck trying to release 0.12 for quite a while because of some significant changes to internals (V8, AsyncListener). Once 0.12 is out, things should be much easier. On the plus side, the ecosystem is still moving at the same speed which is pretty great, and JS gets new advanced tooling every day: typescript, flow, 5 (!) es6 compilers...

Re: Yahoo Mail moving to React

#280

Post by spion » Thu, Nov 27, 2014, 1:14 AM UTC

kxo wrote: post #267

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…

My only problem is with 3. If you're already at the point where you are utilizing compilation, why not implement a compiler-level async/await solution (probably based off of a loop + a state machine, a la regenerator).

Even with generators we still need to yield something or await on something. C# awaits on Tasks, in JS Promises would be a logical choice. You definitely need a value though - you can't await for node style callback functions as they provide no value to yield (or otherwise pass to the runtime) between calling the function with a callback and your callback getting called.

Even so, lambdas, observables and some FP constructs such as map/reduce/filter/etc can potentially eliminate the need for imperative style code. There are also some semi-imperative solutions to certain problems that work okay [1]

Another advantage of functional code is that its easy to extend - adding a combinator that implements filtered (typed) catch for promises is a lot easier than implementing a language construct such as `catch (e if e.code == 404)` for generators.

  var only = (predicate, handler) => e => {
    if (predicate(e)) return handler(e) else throw e;
  }

  promise.catch(only(e => e.code == 404, e => {
    handle...
  }))

Here is another example (its a bit of an overkill though :)

https://github.com/spion/promise-streams/#example

[1]: https://gist.github.com/spion/8009559