There's this post kinda making the rounds lately. It's a nice post. Everything in there, I agree with, for sure. Especially as someone who feels a lot more comfortable with Node than with, say, Angular's mostly ungrokable API. I get why people like React. I get React. It's not exactly hard to pick up, anyway. It's very logical and intuitive. And I really do like the concepts behind React. But I still have problems with it.
Part of the problem is that React is Facebook. It doesn't matter how much React is actually community-lead; we've seen before that when a company owns/controls a library/framework/language, things can get hairy, sometimes, and cause issues. Besides which, Facebook is kind of absolute pure evil. I mean, maybe not quite Google-level evil, but at least Google provides a lot of useful tools for people. (Google also screws over developers using their frameworks with huge breaking changes and no upgrade paths, but that doesn't make their suite of online tools any less useful.) Facebook's entire business model, the way they actually manage to stay afloat as a company, is one of exploiting their users, dumbing them down, and selling their secrets (okay, yeah, if it's on Facebook it's not a secret anymore, but you get what I mean). That's kinda, like, pretty shady, man.
But, look, I get it. It's just a library. And it really is mostly community-lead. That's pretty great. What's not so great is how some things are implemented. I do like the theory behind React. I like that it can be used (and usually is used) just as a view. MVCs are all well and good, but what about all the times we don't need a whole MVC framework? That's nice. I like the data flow. I like that it's much more naturally modular (or componentized, I guess). But that doesn't mean it manages separation of concerns. That means it manages separation of elements. Yeah, it's a paragon of atomic design, and that's really really super nice, but the way it does this isn't really really super nice.
I'm not going to go deep in and bring up examples from the hordes of React-alikes out there, because chances are half of them will be deprecated (or 'Enterprise', in front-ender speak) by next week. But there are a lot of similar libraries, and some of them do React better than React does. The biggest thing that makes them better is keeping markup, logic, and styling apart. There are a lot of ways to do that and still get use a component structure and workflow, and still work against a virtual DOM (or the real one, that's a thing too), and still base everything on state, and still have a fully one-way data flow. It can be done. I won't go and write up a bunch of examples, but I will mention a few alternatives you might check out.
render()(which is acceptable, since this is programming, after all), and if you ever want to directly control the DOM, you have to fight React to do it. And anyway, you'd still have to be writing your markup and styling in your scripts, which is gross. Vue, like Riot, is a lot simpler than React. Unlike Riot, it doesn't want to be React. It also doesn't want to be Angular, or Ember, or Polymer. It does take inspiration from all of them, and it shows it some design decisions (Vue components and Polymer elements are somewhat similar, for example). It's fast, too. And a pleasure to write. Vue's single-file-component style is better at a true separation of concerns than React manages, since it's still fully modular and pluggable, but doesn't require mixing up two or three languages all in the same mess just to get anything done. Vue (if you couldn't tell from the name) is just a view layer, like React. Vue's reactive data-binding is simple and sensible; make changes to the data, things happen on the view, so there's no need to be messing around directly in the DOM. Because of how you separate your styles, logic, and markup in a Vue file, it's very easy to write each in whatever compiled/transpiled language you like. ES7064, YAMAHAMJADEL, StyLASS? Go for it. If there's a plugin for your build tool, you can do it. You will need to take a few minutes to get comfortable with Browserify and/or Webpack to get everything you can out of Vue, but if you're using React, you're probably already using Webpack, so that shouldn't be an issue.
I won't go on too much about Vue. Maybe I'll save that for some other blog post. It really is just downright fun to write, and it makes a lot of sense. Given the rate of growth in Vue's community (and the big names on some projects that have used Vue so far), I think keeping an eye on Vue and taking an hour or two to get familiar with it might be a pretty good idea.
So, really I just wanna say... I don't hate React. I hate JSX, because it's disgusting, and writing React without JSX is significantly more work than just using an alternative. None of these has all of React's features, I think, but some of them have some additions that are very welcome, and React itself (and the common community additions/components/libraries for React) is actually not exactly small, at all (no, really, React core 133kb, minified, and you still need to figure out routing, state containers, and all the other bits!), so almost all of these React-ish alternatives will load faster in the browser. Riot, Vue, and Mithril, in particular, are a definite improvement in most ways, though Mithril's ugly 'HTML' (and the fact that it's a full-on framework) put it a little bit lower than the other two in my mind.
On that note... I've successfully procrastinated the entire day away, writing this and another post on front-end performance (which is not nearly as rambling, I promise). Yay, procrastination. Boo, I still need to read the docs for Socket.