Most of us use it because we have to, even though there are much better languages available.
Node's popularity is a pretty dramatic counterexample to that assertion.
Flexbox is the saner API we've all be waiting for, in my opinion. I'm curious what the author's objections to it are. That's really my problem with the whole piece — statements like this are thrown out there without much justification or explanation.
There's the javascript being bad with no explanation. As if there's something bad with developing tools for the javascript adept to contribute to a platform.
Browsers already doing too much comment. What? Would this person rather the team create new tools from scratch instead of leveraging a tool that the target market for this project is already using?
Notice that the "good" parts have very little or nothing to do with web development and a good number of the "bad" items do. I believe this person is not one of people intended to make use of this tool.
If nothing else, the list of very large companies making use of React, seemingly without concern, makes me unworried about this.
> it's "be a patent troll and suffer the consequences"
[1] https://twitter.com/floydophone/status/581486099240873985
If you're forced to split out your view, your template, your stylesheet, your controller, your model, your business logic, et cetera into separate files you are forced to keep components large.
However, if you have a component-based structure, whenever you notice a very small piece of common functionality it becomes trivial to create a new component for that functionality. You end up with a very large number of very small, very easy to understand components, with clear areas of responsibility.
Why exactly does this force you to keep your components large?
This is located in « The Meh » section. IMHO, it should be in the « The Good ». Using the official spec instead of reinventing the wheel is always a good move.
It's something people are familiar with and has a full debugging suite
I think he's trying to convey that the browser is getting too bloated and that there should perhaps be a native app to handle the debugging.
If there were things being added to Chrome Dev Tools specifically to support React Native, that'd be different.
- Better native integration
- Integration with the SDK tooling
- Support of all three major mobile platforms
- Performance
As soon as I saw what React Native offers, it was meh for me.
API-wise, MoSync really stands out. Unfortunately, it is dead now. Same goes for Adobe Flex/AIR.
Personally, I would also like more Qt Widgets love, but only due to binary size.
You can create a ListView and the performance (and feel) are great, but it's not a UITableView. You can draw a chevron and make it kind of look like a UITableView but if you have to manually re-create the native UI, it's not really native anymore, is it?
It certainly is slick to get instantaneous feedback when you edit your javascript file, though.
Eventually it'll be available for Android, so that's a valid reason.
It strikes me as a funny comparison. I agree that the react approach can feel like a better fit than FRP at the view layer, but it's not like there aren't positive reasons to use FRP/signal-based programming in your model layer or when wiring up your models to React views.
Maybe there will be stronger overlap in the long run.
For the rest of the properties I imagine anything that's really needed will be coming - many seem trivial to implement.
The meaning of 'immutable' must have changed lately.
If only there was some way to pull out a hunk of code so that it could be reused. Hm. Somebody should invent that.
It's so interesting how once you get used to instant feedback loop, anything that's longer is perceived as a pain. We want to find a solution for this though :)
