Earlier quoted context omitted.
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…
You assume everybody uses these tools... in unity, harmony, and applying the best practices (that are not established yet). You assume all libraries in JS is mature, well-supported, and will be there in the next 4 years at least. I echoed other comments: JS ecosystem is unstable and confusing at the moment. Case and point: EmberJS. I have to use ember-cli, npm, bower, and broccoli. Some of them overlap.
Yahoo Mail moving to React
201–210 of 301 posts
Re: Yahoo Mail moving to React
#202Earlier quoted context omitted.
First-class functions and closures are nice if you're coming from Java.
Those are in Java now. Always have been, really, with a lot of boilerplate.
Many uses of first-class functions is for reducing boilerplate to begin with.
Re: Yahoo Mail moving to React
#203Earlier 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…
And no, you don't really need global variables in frontend that much; and backend PHP programs (which you should not do of course) have long-lived global variables.
Re: Yahoo Mail moving to React
#204Yahoo's React/Flux projects mentioned at the end are intriguing. I have tried implementing Flux architecture in an app and found it really tedious and boilerplatey. I'm still looking out for well-implemented Flux dispatcher libraries. https://github.com/yahoo/dispatchr https://github.com/yahoo/routr https://github.com/yahoo/flux-router-component
Re: Yahoo Mail moving to React
#205Earlier quoted context omitted.
Sadly, I have to agree :(. This is the weakest aspect of the Erlang ecosystem...
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).
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.
Re: Yahoo Mail moving to React
#206Earlier quoted context omitted.
> 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.
What did they switch to? Source?
Re: Yahoo Mail moving to React
#207I 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…
Re: Yahoo Mail moving to React
#208I'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 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.
(edited for clarification)
Re: Yahoo Mail moving to React
#209Earlier 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…
Have you used Async.JS? In my experience, it has always solved my deep callback problems.
Re: Yahoo Mail moving to React
#210Is finding Clojure people that hard (honest question)? The Clojure + ClojureScript approach has many more batteries included. You get all the benefits of reusing the codebase on both sides of the fence while the language is solving the "Transactional Store", efficient dirty checks, nice server-side concurrency primitives and many unrelated problems for you.
I've been using and enjoying React and am excited to learn more about Reagent. It seems like Clojure + Reagent will make development quicker and more enjoyable.