I think this is because you're interpreting it as "Javascript is bad" instead of "Javascript is bad for this purpose." I think there are plenty of places where the latter is a totally logical statement that needs no real further explanation.
The article probably should have removed any ambiguity on the way it could have been interpreted. An explanation as to why javascript isn't a good language choice would have been even better.
Why? Javascript is not without its thorns and glitches. What makes it perfect for this use, in your opinion? Is it just the general "I don't like something you like" reaction - in which case, what is it that he's wrong about here?
Who said it was perfect, for this or any other use? You're just constructing a straw man.
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.
I don't think that just because someone doesn't like Javascript it makes their opinion less valid, or that they are a poor developer .. by many professional, highly-productive developers standards, Javascript is a mess and ought to be avoided. For some, the use of Javascript to solve the cross-platform web development problems is a poor decision .. whereas your argument seems to be "everyone else is doing it therefore it must be good and anyone who disagrees with the collective mind is clearly stupid".
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.
Why, because the entire point of react native is so you can use javascript to handle your logic in your app. This lets you bring in a ton more developers for your projects than just the few people who know Objective-C/Swift.
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.
> 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).
No one "has to" use anything, even if they only know that one thing. It doesn't take that long to learn a new language.
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.
More important that "so many people knew JavaScript anyway", is the fact that using the same code in the browser as on the server means that they can share code, data-models, tests, and it makes it trivial to develop isomorphic web applications.
> Node is popular because so many people knew JavaScript anyway.
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.
> Is that true, though? I see very few JavaScript developers with a solid background in computer science or software engineering on the job market
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.
How would you measure such a thing? NPM has more modules than any other language package manager, isn't that evidence that Node is at least somewhat popular?
I didn't say it's not popular. I'm just saying Node's popularity is not even near to Java or PHP. But I agree that Node's/io.js hype is much louder nowadays :)
Does it have to be the most popular runtime to counter the "no one really likes JavaScript, we just use it because we have to" claim? As the grandparent said, no one has to use Node, but people do; a lot of them.
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?
"we have to" was not my phrase and it was about client side, not server side. And it's true. Somebody love JS, somebody not so much - nothing wrong with it. People are different and it's the key of evolution.
Node is definitely popular, but the fact that there are more modules than any other language is a bit misleading. Python, specifically, tends to only have one main/popular package that does something, whereas in other languages' cultures I've noticed that there are a few alternatives to choose from.
There's nothing objective about that statement, since it depends on what you value. If you value having a language that is supported natively by every browser, I would argue JavaScript is - subjectively - quite fantastic!
"StyleSheet is not CSS. You will be quickly disappointed if you adventure outside the few CSS-inspired properties that React Native ships with." < I can see how that can be quite annoying, everytime you want to use a property, you'd have to go back and check if RN supports it.
Maybe there will be stronger overlap in the long run.
The one pain point I can see coming up again and again is that the way of making something full-width isn't to specify "width:100%" but instead to use flexbox. While that makes sense to me, I've already seen quite a few people (on SO for example) tripping up on this.
For the rest of the properties I imagine anything that's really needed will be coming - many seem trivial to implement.
While react-native isn't for me, some of the features are really nice. Hotswap for mobile development is definitely a very nice thing to have. I do wonder how that handles app state. Is only the UI reloaded or all of the code?
At the moment I believe it's everything JS-side. It's not like webpack hot-swapping where just the component gets replaced. The one caveat is that if you've got a native module written in Obj-C obviously you'll need a full rebuild to see any changes there.
It ruins every single discussion on the topic when armchair lawyers wade in. I have no doubt that we'll see commenters now provide their own opinions on this clause without having the faintest idea of what they're talking about.
If nothing else, the list of very large companies making use of React, seemingly without concern, makes me unworried about this.
I agree that having this issue dominate discussion is incredibly annoying, however I have to say, Facebook needs to make this more clear. There should not be confusion about this.
This, I do agree with. Like I say, I'm not bothered about this issue, but I'm sick to death of seeing the endless stream of internet warriors throwing themselves at it. A clarification blog post would help a lot.
The fact that large companies are making free use of this surprised me. Is it because they don't think that the seconds clause is actually enforceable? I would love to hear more on this.
> Flexbox. The authors missed the opportunity of offering a saner API and favored sticking to the official spec instead.
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.
Agreed, though it must be stated flexbox is not yet a fully implemented and deployed API, and most certainly not the easiest to use (but it is not for a trivial problem anyway.)
I think in either the first or second keynote back to when React native was announced they talked about their reasoning behind using flexbox. I think it's also 'the good'. They were able to use a web technology and make it work in react native just as if it's the browser, pretty impressive. If they had to come up with their own 'css' style layout api I would then have put it in 'the bad' myself.
I think these are fair concerns, but it also sounds like this person comes from a more iOS native development background. Why not stick with that? I like the idea of react native as i use react more and more in the browser, and I enjoy the workflow.
I thought the APIs would still be different though. Maybe not. Either way, I think it's great for people who do use native to try new tools. But yeah I can accept that they will probably miss certain features.
ReactiveCocoa is a fairly mature FRP library from GitHub.
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.
He knows they just released it right? A good number of "The Bad" should probably be seen as coming soon. Probably could've named those "will be better when..." Especially Stylesheet and Swift support.
Which is daft, because to produce a separate app specifically for debugging React Native would be a huge undertaking with zero extra benefit. Chrome's Dev Tools are best in breed (IMO) and it makes sense to leverage them.
If there were things being added to Chrome Dev Tools specifically to support React Native, that'd be different.
Component-based file structure is firmly in the "good" column for me. It makes small components much more feasible.
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.
> 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.
Why exactly does this force you to keep your components large?
I have. Not uncommon in Backbone development for instance to keep templates in separate files from the views. If the templates are short you can inline them, but sometimes its easier to just be consistent and give every template its own file. It definitely does add friction compared to React though.
It's a bit like comparing a particle accelerator to a bagel. Easier to explain them each on their own. Try running through some sample code of both to feel out the philosophy.
I wish Qt Widgets (C++, not QML) was more mobile friendly... Xamarin will be good when it finally becomes free (acquired by MS?), or at least gains more indie-friendly license.
API-wise, MoSync really stands out. Unfortunately, it is dead now. Same goes for Adobe Flex/AIR.
> Flexbox. The authors missed the opportunity of offering a saner API and favored sticking to the official spec instead.
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.
I'd much rather be writing apps using constraint-based layout, much like AutoLayout. It took me a while to grok it, but it's much simpler once you get it.
I disagree, but I suppose this a matter of preference. For whatever it's worth, the React team did explore using a constraint-solver, but nixed the idea. They explain their reasoning here: https://www.youtube.com/watch?v=7rDsRXj9-cU&t=14m20s
Not sure what I think about React Native as a whole but I wholeheartedly approve of using flexbox for layout. It's much more declarative and easier to understand. Autolayout is a fundamentally flawed approach to layout. Building layouts in AL is very tricky and debugging them is twice as tricky as writing them. And lord help you if you have to programmatically add or remove views from a layout at runtime.
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.
OP mentions you can enable auto refresh, instead of having to Command + R every time I assume. I couldn't find that info anywhere, does anyone know how to do that? I'm really used to that workflow now with Figwheel + Om.
Yes, in the simulator if you go to the "Hardware" menu, then "Shake Gesture" while the RN app is running, it'll pop up a menu that gives you the option. It is very cool.
Awesome, thanks. That should really be mentioned in the Quick Start and/or Tutorial in the docs. I think a lot of people would really appreciate that feature. :)
> Styling nested view controllers is a pain. You are taken back to the root view controller after each refresh.
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 :)
I played around with it a bit over the weekend. You can call it native, but at the same time, it's not completely native. For example, there is no UITableView support. That's one of the most common ways to present data. Hell, one of the first things I tried to do. (There is a bug report. They tried to support it but the code was ugly and didn't really play well with react-native so it was dropped).
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.
I don't ever find myself using the default uitableview much, usually it will contain completely custom cells. Does their ersatz table view have any issues beyond the lack of a chevron?
"Component-based file structure. Handling styles, view hierarchy, and business logic all in one file is a step backwards. Poor style reusability is one direct consequence of this approach."
If only there was some way to pull out a hunk of code so that it could be reused. Hm. Somebody should invent that.
> Immutable user interface. You no longer have to track state in both the model and the view; the latter is a function of the former. As soon as the model changes, React Native re-renders a virtual tree of the view hierarchy, then applies the delta to the native views.
The meaning of 'immutable' must have changed lately.
Can you help me understand which part of that you think stertches the definition of immutability too far? The developer doesn't change the UI state, it is just a pure function applied to the domain state. Is it the fast path they implemented that does the diffing to speed up the function that bothers you?
104 comments
[ 3.6 ms ] story [ 170 ms ] threadThe 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.)
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.
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
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.
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.
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.
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?
- 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.
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.
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 :)
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.
If only there was some way to pull out a hunk of code so that it could be reused. Hm. Somebody should invent that.
The meaning of 'immutable' must have changed lately.