Live data from Hacker News

Yahoo Mail moving to React

slideshare.net

241–250 of 301 posts

Re: Yahoo Mail moving to React

#241

Earlier quoted context omitted.

> The runtime performance is already very good and continually getting better Have you checked out the Computer Benchmarks Game? Here are some benchmarks they provide, comparing the JavaScript V8 to Python [1], Ruby [2], and PHP [3]. Looking at statistics such as these, I'm left thinking, "1. This is awesome! 2. Is there something about these other languages that prevents V8-like performance, or is this more a matter…

V8 does precompilation to native code and JIT optimization, which can typically turn numerical computations into efficient, and often highly optimized, machine code. These benchmarks seem to primarily be testing algorithms which require a lot of numerical computation and can take advantage of Javascript's typed arrays, which V8 is designed specifically to optimize. A somewhat more fair comparison would be V8 vs. PyPy…

I don't think more code will be a big problem for javascript. It seems to mostly affect start up time. Look at the asm.js tests with Massive. Also think about all js projects that use anywhere from 10 000 lince of code (LOC) to 100 000 LOC. I haven't heard anyone saying that the runtime got into any problem. There is always some problems with organizing that amount of code but that is true in almost any language. And javascript is actually quite effective to write in meaning a js program is probably much shorter than the same program in Java (at least before Java 8).

http://kripken.github.io/Massive/

I just remembered that there are demos of Unreal Engine running in js with a lot of LOC and fast performance.

Re: Yahoo Mail moving to React

#242
post #230

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) […

> I'm not sure why you consider the JavaScript ecosystem unstable ? Well I'd say his opening might be the reason: "As the companies I work(ed) for evolve from JS => jQuery => Backbone.JS => Backbone.JS + Marionette => EmberJS, so does my skill have to evolve." It's evolving fast, and this makes it unstable in terms of knowledge and what's being used. Depending on outlook (or age?) this can make it exciting. It's also…

Even though the frameworks evolve quickly in JavaScript, nobody is stopping you with sticking to an "older" one if it works for your project.

It's true though that your value as a developer shifts quite fast depending on the trends. But I feel that a fast moving world is merely a consequence of super large communities like the JavaScript one.

By "stability" I meant that NPM and Bower are quite reliable. Also, if you look at the usage stats for the top plugins, the still show in my opinion stability since you have a lot of devs contributing through pull requests.

Re: Yahoo Mail moving to React

#243

Earlier quoted context omitted.

The notion that SPA automatically gives you better user experience is a fallacy. Better UI design gives you better user experience, and good UI design is possible using the classic approach to web development. As an added bonus, you get searchability for free and you don't have to move away from your existing server-side stack.

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.

Re: Yahoo Mail moving to React

#244
post #208
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)

But is that because you like Python, have a large code base that takes time to convert, is missing some tools, don't think javascript is mature enough or something else?

I use C# myself and would not like to convert our whole app to js but I could be ok with Dart or TypeScript instead (or Go but that is not a scripting language).

Re: Yahoo Mail moving to React

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

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 feel that if you go the whole react and SPA route you should use the tool mostly used with that : grunt/gulp, npm/bower, browserify/webpack. Even MS is going this route the VS 2015 projects will use grunt/npm/bower in the starting template, don't expect to have updated Nugget package for all those JS lib you will use for so long. And the is no Nugget packages for most lib you will have to use with React. The only thing that make it interesting is for the initial render but I don't know if it is easy to set up.

Re: Yahoo Mail moving to React

#246
post #206
post #186

Earlier quoted context omitted.

What did they switch to? Source?

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

Thanks. Sounds like they didn't really figure out what the problem was with the Erlang implementation but instead reimplemented with C++ systems that were existing, built in-house, and better understood. Makes total sense but shouldn't be taken as a point for or against Erlang as much as it's a point for using a stack your team is familiar with (or has a deep motivation to get familiar with).

Re: Yahoo Mail moving to React

#247

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…

I agree there are some serious problems. But a lot of the problems are worked on, like modules. I agree they should be in the language and it looks like they will be in ES6. Regarding the different languages on the server and client you don't really have a choice. JS is what runs in the browsers. If you want the same on the server the server has to change. Very few people seems to want Java in the browsers again. And you can write gateway systems in Node that then connects to servers further back which may still use Java/C#/Python or something else. This seems to be the natural route for many projects.

Re: Yahoo Mail moving to React

#248
post #98

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 disagree. Every time I try to get into node, I am stonewalled by poor debugging support. I end up wading through obtuse stack traces only to find poor quality libraries are the culprit. Tracing dynamic languages is so hard already. The only thing I can tolerate is Python with Werkzeug.

We use

1. Bluebird with longStackTraces, [1] to get complete stack traces for an entire chain of async operations with minimal performance penalty, and

2. node-debug from node-inspector [2] as a debugger (same UI and features as chrome dev tools)

[1]: https://github.com/petkaantonov/bluebird [2]: https://github.com/node-inspector/node-inspector

Re: Yahoo Mail moving to React

#249

Earlier quoted context omitted.

> The runtime performance is already very good and continually getting better Have you checked out the Computer Benchmarks Game? Here are some benchmarks they provide, comparing the JavaScript V8 to Python [1], Ruby [2], and PHP [3]. Looking at statistics such as these, I'm left thinking, "1. This is awesome! 2. Is there something about these other languages that prevents V8-like performance, or is this more a matter…

benchmarksgame is not a serious comparison site, it's in the name. The comparisons they do is not of idiomatic code... for example in python they do a lot of array programming and don't use numpy ( http://www.numpy.org/ ). So for most languages the results in there are completely meaningless.

The name "benchmarks game" signifies nothing more than the fact that programmers contribute programs that compete (but try to remain comparable) for fun not money.

The performance of those programs with CPython explains the existence of numpy, and if you look you'll find that numpy programs are shown.

Re: Yahoo Mail moving to React

#250

Earlier quoted context omitted.

I switched from WPF, C# dev to Angular JS with Typescript and Web API with relative ease and I'm digging it. Typescript definitely helped though. I know I have plenty more to learn, but it's not as shitty as people make it out to be.

If you're using Web API (built on ASP.NET) then you're not using Node, which is a Web server written in Javascript. But I do think it's cool that someone can transition from WPF to Web development with Angular without feeling too lost. Dynamic Web development used to be a very, very different ballgame from client application development.

What if you use Node to serve up the client and use Web API as the back end which you make calls to?
Post reply on HN