They seem to be being used mostly as immutable constants for readability--which kind of fits with normal use, right? I'm just trying to see if there's anything else here I'm missing.
Honestly I think FB put the flux pattern out before that idea had become fully developed looking for feedback from the community. The flux repo explicitly states that none of the examples are used by facebook or even resemble facebook (client-side) code. The dispatcher, which was released months after they announced flux, is the only component in the flux they admit to using. Immediately after it's release (even before the dispatcher) we began writing client-side javascript code based on arbitrary examples meant to demonstrate a concept.
I also think flux's real-world implementation came from the necessity to build React components within pre-built apps, where they simply didn't have the ability to pass down props because they had to create complete separate components.
I discovered React after using Om, and I believe that Mercury comes with a lot of good practices enabled by default. But it's technically possible to achieve the exact same 'decoupled-state-pure-shallow-etc' using React. It's just not turned on by default and some additional boilerplate is needed, so it's harder to achieve this in React. The only reason I use React instead of Mercury is that React is battle-tested. No amount of testing can replace the real-world situations.I choose a path of higher resistance because I trust React most (due to it's popularity and usage), even though Mercury is better in theory. Ultimately it's a pattern, and that pattern is associated with a level of abstraction over the DOM as well as the way we write code. Mercury and React are two examples of this. I would like to see more competition and libraries to choose from, modular DOM abstractions, with declarative UI's and alternative API's and jsx-esc transforms. That'd be awesome IMO.
> The way you express your opinions is enormously important. It could easily be the difference between getting a raise and getting fired.
How is this relevant to the conversation? This isn't a letter to his boss, it's a blog post. Even so personality types differ vastly between individuals and your argument appears to be culturally conditioned in a different cultural. In other words, we live completely different worlds due to our cultural conditioning (or lack of - by that I mean our association with our inner voice).
> The first one is an absurd overarching dogma declaring every other app-building technology to be inferior to react with no backing whatsoever
It's just a matter of using the word 'a' vs. 'the'. We actually get it wrong MOST of the time. Replacing 'the' with 'a' provides much more clarity. For example, you could say 'Please bring me the green chair in the closet', but if there's more than one green chair? Well there's more than one 'right' way to build apps. React is 'a' right way to build an app. There are MANY wrong ways to build apps, and most web frameworks (in my opinion) build apps a wrong way. React is one of the few. That's how I feel.
I think you either have an ulterior motive for criticizing React itself (money, company), or you're just closed minded.
I began programming in September of last year. For loops were trivially easy to understand (took me about a day), 1-2 weeks to become proficient. I started with php, moved to 'jquery', and then rails. Rails pisses me off. I said fuck this class I'm learning node/javascriot. After a week of js I switched to clojure (my instructor hadn't even heard of it, this is a full day bootcamp coding course). Rich Hickey is my single greatest influence in programming habits styles. I spent a few months, off and on, learning clojure. I still can't program competently, but I learned how to replace for loops with map / filter / reduce. Once I realized what was going on there, I had my greatest 'ah ha' moment in programming thus far. Clojure blogs led me to Om, om to react, react to frp and gulp, gulp lead to streams / piping, and I haven't used a for loop in 6 months. It's boilerplate that's so trivial, you only need to code for about 3 months for the functional abstractions to become more useful to you. It took me a few weeks to learn how map, filter, reduce work. It took me a few hours to learn a 4 loop. I still consider myself am amateur programmer, but this trend of code abstraction will continue rapidly, and our CPUs and more that capable of handling the potential performance hits.
d3 is very powerful, has an amazing api, and it's incredible library. but my processor goes insane running trivial d3 animations (macbook pro core-2-duo 2009). with css 3d, webgl, I don't have processor issues, but god-damn the d3 api is one of the best I've ever used for animations
>the nature of JS means libraries move slower than other languages.
prior to node and npm maybe. The JS npm ecosystem is actually growing faster than any other language's module/library system, it's on the cusp of becoming #1 in the world. http://modulecounts.com/
It's a small and simple code base, and much easier way to grok the concept than reading a book.