When "The Bad" list start with the single word Javascript, it loses a lot of credibility for any unbiased judgment.
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.
React Native: Initial Thoughts
31–40 of 105 posts
Re: React Native: Initial Thoughts
#32When "The Bad" list start with the single word Javascript, it loses a lot of credibility for any unbiased judgment.
But JavaScript is a bad language, objectively. There's little debate on that subject. 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.
Re: React Native: Initial Thoughts
#33- 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.
Re: React Native: Initial Thoughts
#34When "The Bad" list start with the single word Javascript, it loses a lot of credibility for any unbiased judgment.
But JavaScript is a bad language, objectively. There's little debate on that subject. Most of us use it because we have to, even though there are much better languages available.
Re: React Native: Initial Thoughts
#35Flexbox 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.
Re: React Native: Initial Thoughts
#36Is there an FRP library in iOS? The author states that React "feels superior" than FRP, so I'm curious what the comparison was.
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.
Re: React Native: Initial Thoughts
#37Why is Chrome Developer Tools meh? 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.
Re: React Native: Initial Thoughts
#38> 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.
Re: React Native: Initial Thoughts
#39Earlier quoted context omitted.
But JavaScript is a bad language, objectively. There's little debate on that subject. Most of us use it because we have to, even though there are much better languages available.
> 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).
Re: React Native: Initial Thoughts
#40> 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.