HN Explorer

32 comments

[ 3.0 ms ] story [ 78.3 ms ] thread
jwaldrip
There are so many wrong things said in this post. First off, much of this is a comparison between react (not react-native) and flutter. React-native does not use webviews or a DOM. It uses similar paradigms to flutter, just written in dart rather than javascript.
cmjqol
>It uses similar paradigms to flutter

But it's common these days to confuse reader to make self promotion for their tech/services

A huge amount article's on Medium are similar to this one, they stay at the surface and don't really bring anything new to table.

thosakwe
The point of this article wasn't self-promotion at all, and I certainly mentioned the similarities between Flutter and React. The point is to highlight the differences, and that when using Flutter, you need to keep said differences in mind.

EDIT: I'm not so sure as to what you mean by "staying at the surface," though - I included examples of patterns that are common in React, their analogues in Flutter, and the reasons why said patterns may or may not apply well in Flutter.

k__
Yes, and this articles does the writer a huge disservice, especially when it comes on the HN front-page :(
thosakwe
I could have worded it better, but my point in that sentence was that React targets the DOM. Overall, the goal of the article isn't to say that React or Flutter is better than the other, it's specifically to say that to be effective with Flutter, you can't view it as being the same as React, which I feel was clearly stated.
k__
React isn't Flutter competition, React-Native is and it doesn't target the DOM.
k__
Well, they list "Inheritance + Polymorphism" as a pro.

Sounds like the writer hasn't too much experience, so be kind :)

matthewmacleod
Mmmm, no kidding. Stateless functional components are the absolute bomb from a “reasoning about your code” perspective.

FWIW I’ve found the most prosuctive front-end combination to be React + Typescript, which has the benefit of being seamlessly interoperable with JavaScript, really excellent at capturing common errors, and allowing the type system to be exploited for much more expressive code. YMMV of course.

k__
I tried Flow with VSCode and found it rather flaky. Had to open up files to get autocomplete etc.

Is TypeScript better in that regard?

lol768
> I tried Flow with VSCode and found it rather flaky. Had to open up files to get autocomplete etc.

Sounds like an editor issue. Have you tried it with something like IDEA/WebStorm where there's a bit more code intelligence?

matthewmacleod
I’ve had no problems with Typescript in that regard (in fact the typechecking and linting is astonishingly fast) but I’m using Sublime integration. From what I understand though, VSCode has very thorough Typescript support, given its Microsoft pedigree and all.
wstrange
This seems like a very uncharitable reading of the article.

Inheritance has it's place in the toolbox.

steeve
Except that Flutter does not compose the native UI widgets but draws its own (with physics etc...)
solidr53
I highly recommend reading the DSX issue on github, I am one of the supporter and highly disagree with the author of this article.

They don't seem to know how JSX works, tell us what Flutter wont be instead of what it could be. I am truly sorry for their fatal decisions in this aspect.

https://github.com/flutter/flutter/issues/11609

k__
They should at least add some factory functions, so you don't have to throw all these "new"s around...
solidr53
Yes definitely, and enforce a naming convention for widget childrens. They are currently all over the place.
thosakwe
The "new" and "const" are optional now, as many people requested it, since it creates a lot of extra noise.

I too would appreciate a naming convention; that would make things a lot easier.

wstrange
I don't think this is a fatal decision at all.

With Dart 2 syntax making new optional, widget layout is quite compact and easily readable. I think the Flutter team has made the right call here. Sticking with pure Dart has a lot of advantages (tooling, IDE support, etc.)

thosakwe
I agree with this, and in reference to the prior comment, yes, I’ve seen the issue in question and read it, I even commented on it a few days ago.

IMO the benefits of something like JSX really don’t make as much sense in Flutter. For me, the main thing is, why use XML syntax to represent something that’s truly not XML at all?

natecavanaugh
If you think of JSX as a DSL rather than a souped up XML, it makes more sense. XML is just a different kind of abstraction, so rather than thinking of it's output, it's good spots are in the way it helps structure your input.
maxdo
code and layout should be separated in my opinion, and jsx with thinks like styled-components did a great job, so you can easily read the UI structure rather then "complite" in your brain those tons of dot's braces align differently.
breatheoften
Does Dart’s type system not support Non nullable types?? I can’t see why I would want to use a language without non-nullable types ... — is there a justification for not supporting this somewhere — I’m curious why this wouldn’t have been an early requirement for the type system.

  const FrogColor({
      Key key,
      @required this.color,
      @required Widget child,
    }) : assert(color != null),
         assert(child != null),
         super(key: key, child: child);

    final Color color;
thosakwe
At this point in time, there's no support for NNBD, though people within the Dart team have proposed it. I can't speak on their behalf, though, as you can imagine.
k__
Some Dart dev wrote here on HN once there was a huge opposition in the dev team against non-nullable types, don't remember why tho
thosakwe
The post you're looking for, I think: https://news.ycombinator.com/item?id=14547826
breatheoften
Interesting — thanks for the link! I really hope they aren’t too late to get non-nullable by default into the language as well... seems like it would influence a lot of the language design ...

I personally found typescript almost impossible to use until turning on the non-nullable by default option and no implicit any (and really started liking it after). I see dart had “no implicit dynamic” — is that widely used in dart? I would turn that on with a quickness ...

Reliable constraints were really important for me to figure out how to use the the optional typing model of typescript to my benefit. Maybe Dart’s programming model is simpler since it doesn’t maintain JavaScript compatibility... but my suspicion is that features like implicit-dynamic and nullable types will just make it harder to learn how to interpret compiler errors and harder to learn how to write good code in the language...

hguhghuff
Sounds like all the very best bits of javascript like spreads, arrow functions and destructed arguments are missing from dart.

I’m quite attached to stateless functional components too.

_pdp_
A bit of a side-topic but I am not sure why people use flux/redux and it is constantly mentioned when talking about react.

We have over 20 very complex projects built in react with no flux. The whole state is managed by react itself and some helpful decorators. You could just easily not use flux/redux - the article should not mention it.

iliaznk
People use Redux or any other state management solutions for the same reason they use frameworks and libraries in the first place – all the tough design decisions have been made for them, they just have to follow the rules. Of course you can do with React's internal state alone, but do get it right for complex apps it takes some prior experience and knowledge.

Could you elaborate a bit on what those decorators you mentioned are?

_pdp_
This not my point - my point is that although it is optional it is mentioned as the defacto standard. I don't think it is because it complicates things way to much.

I cannot enumerate all decorators in this comment but we have one called useGlobalState where you pass several prop names and a scope name and in return it manages those props for your like any other controlled component. It is fast and it is effective in what it does.

There are a few others that are more specific.

nudiustertian
Yeah it certainly seems like whoever wrote this doesn't know much about react
tones411
Your article makes it sound like ReactNative uses webview to render the UI, which is not correct.