React Native: Initial Thoughts
unredacted.redalemeden.com
unredacted.redalemeden.com
The actual objection, which was perfectly obvious from the comments you were replying to, is with the use of the word "Javascript" alone without any further explanation, as if it was axiomatic that the use of Javascript is bad.
When an article includes such an extreme opinion without explanation, it inevitably puts off anyone who doesn't share it. Moreover, it calls into question the ability of the author to review the technology in a fair way, and the purpose of them reviewing it at all. React Native's entire raison d'etre is to provide a native version of a web development stack. If you are inherently biased against web development technologies, then you're obviously not going to get on with React Native, or any similar technology.
Sure, I'd like to know why he thought Javascript is a negative. I'd also like to know why some think its a positive. But I fail to see how invalidating his entire argument is going to prompt that discussion. Seems to me like those who disagree with him about Javascript just want to shut down the whole discourse - whereas there could, indeed, be very good reasons why Javascript is a negative.
So using a project and disagreeing with it's entire purpose for existing is silly without further explanation of why javascript is bad for this type of thing.
In his argument he says they should be using Objective-C over Swift, which is just wrong. Apple says to use Swift, it's faster and easier to use.
Beyond not liking javascript as a language it's super fast and easy to learn why not make it so more people can start developing apps using that language. It will create better apps that phonegap apps.
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.
Popularity has nothing to do with quality. Node is popular because so many people knew JavaScript anyway. JavaScript is popular because it was the only widely-supported programming language for the browser (other than ActionScript, which is itself an ECMAScript flavor).
And that has nothing to do with the discussion at hand.
The statement "Most of us use it because we have to" is pretty clearly refuted by the fact that no one had to use JS on the server-side, yet plenty still pick Node over other alternatives (even ones they know well).
I wasn't saying that people use it because they have to. There are a lot of reasons to use Node on the server side that are still unrelated to the quality of JavaScript as a language.
1) Easy asynchronous execution (something that is also making Go very popular)
2) Easy to get started
3) Lots of existing libraries
4) Everyone, including frontend devs, knows it already
If you're starting a Python project, you're probably going to prefer hiring Python devs. If you're starting a Node project, you can hire anyone who has done full-stack or frontend work, including Ruby and PHP devs.
Again, all of those are really compelling reasons to use Node, but they have nothing to do with the way JavaScript is designed. The seminal JavaScript book ("The Good Parts") even alludes to the fact that it's not a thoroughly good language.
Further evidence that it's not a good language are the huge number of compile-to-JavaScript projects popping up (TypeScript and Go come to mind).
I also went to a JavaScript conference, and not a single company was using Node through their whole stack, even for new projects. They were typically using Ruby, Python, or PHP for the bulk of their backend, and JavaScript was a thin API layer. I know this is also the case at Yahoo and probably some other companies.
I could write a lot about why I (and lots of others in the dev community) find JavaScript to be Blub-y and fragile, but this is long enough already. The dynamic typing and many ways it behaves unexpectedly are among the major problems.
Is that true, though? I see very few JavaScript developers with a solid background in computer science or software engineering on the job market, compared to the demand these days, as more and more stuff goes to the browser or native HTML applications. Taking kids out of web design schools is too much of a gamble unless you already have a senior JS dev on the team to keep an eye on them.
But then again it might be different in places like Silicon Valley.
That's exactly my point. A huge amount of labor for developing web apps are people who have not come from CS/engineering backgrounds. They're self-taught, and a lot of them started with web technologies.
So it was really easy for those people to transition into backend development because they already knew JavaScript.
I find this topic to be intellectually insulting. You know that JavaScript has its (tens of thousands of) fans. Why tell yourself otherwise? Is your hatred of it so overwhelming that you're not even ready to admit to yourself that others disagree with you?
> But JavaScript is a bad language, objectively. There's little debate on that subject.
Which is obviously false, there is lots of debate on the subject. So can we grow up and get past these blanket statements?
(Disclaimer: I actually think that many facets of Windows are better than anything else, but I know many here do not.)
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.
And their reasoning makes sense. I totally get why they would avoid constraint-based layout.
I disagree with the rest, but yeah... that's a sore point.
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 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.
If only there was some way to pull out a hunk of code so that it could be reused. Hm. Somebody should invent that.
- 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.
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.
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.
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 :)
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.
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.
The meaning of 'immutable' must have changed lately.
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