Hacker News Reader

Comment by kayoone | Hacker News Reader

I like the opinionated approach of NG2 over the flexibility of React because it takes a lot of decisions off of me that i am not too interested in when building a new project. I am a full stack developer leaning more towards backend in recent years and i found setting up and finding out about best practices and "what to use" for React a bit tedious, also it changes so much. The last Flux framework i used was alt.js which was popular last year but is hardly used anymore.

I also really like Typescript and believe enforcing it is a good way to get general JS code quality up.

View on HN

Of note, Facebook's create-react-app provides an "official' opinionated approach. https://facebook.github.io/react/blog/2016/07/22/create-apps...

There's even a pull request to bring typescript into the mix. https://github.com/facebookincubator/create-react-app/pull/5...

I'm just writing a first React app, and read beforehand that it was going to be difficult to choose which libraries to use, and to get them to work together, but I haven't found that to be much of an issue in practice.

create-react-app set up all the build tooling, for a router the clear recommendation is react router, and for a flux implementation the clear recommendation is Redux. It feels like there's a well defined path for beginners. Over time you'll have to figure out how everything works, as is always the case, but you can learn more as and when it's necessary.

The bumps were more whether to use ES5 or ES6 (but then I found an official position in favour of ES6), and whether or not you need to use flux (although that was really just learning how flux worked, which wasn't wasted time).

The only uncertainty I have now is whether TypeScript will be necessary/useful in future, and if so how to integrate it.

Having used TypeScript and also picked up recent projects where it is not being used, TS is definitely the way to go.

The issue is that TS 1.8 doesn't support async/await in the browser until v2.0, but a ts -> babel transpile does the job nicely.

TS 2.0.2 is stable enough for usage I've found, had no issues at all using it so far.

Yes, typescript betas/rc's are more stable than many products out there :p

Microsoft stuff not allowed in my stack...

Why? It's Apache 2.0 licensed...

People seem to have forgotten that MicroSoft was a gigantic threat to our industry, and still is. It owns 98% PCs world wide. What would we think if 98% of gaz stations worldwide where belonging to one company? That would be dangerous, right? Same with MS except it's worse, because PCs are eveyrwhere controlling everything. It's Big Brother in real life. Just imagine one moment how many critical decisions having world wide impact on the life of billions of people are done using Excel? What if Excel was remote controlled?

So, no, sorry, I don't eat that stuff. Bill Gates has built the most dangerous edifice and no amount of charity will save him from the Hell of digital beings.

This is garbage.

The sanctioned way forward for React is Flow. It's not as comprehensive as TypeScript, but there's no compilation required - Flow annotations just get stripped out. As of a couple of weeks ago it is part of create-react-app.

https://flowtype.org

Too bad flow doesn't work as well as typescript in practice. It has way more bugs, is not as tested.

It was very promising at first but typescript now has caught up with Flow best design decision: noImplicitAny, strictNullChecks.

Also, check on the "try typescript" website: typescript's JS output is almost left untouched. it's effectively a replacement for babel, if you only care for ES2015 stuff, and not some of the more recent stage 0 / stage 1 stuff.

this. tried flow, but it's too 'smart' for my iMac to handle. Flow reads all JS files without problems - which killed my iMac after using 6>gb ram. a partial solution was to manually set ignore on some node_modules packages. but still, really slow experience with atom/subl/etc.

Compared to this, typescript is actually dumb enough to require ts definition files to actually parse non-ts (js) files.

I replaced react-router with route-recognizer. The later is a simple tool your code is using, has proper documentation and stability, and do not get in the way of automated tests with jest. But react-router changed too much (i.e. removed named routes), has a lot of dependencies (browserhistory, etc), has very poor documentation, and did not allow me to do automated testing at the levels I wanted to. Moreover, it is a "framework": you're code lives inside of it, breathes through it, and that's something I dislike greatly (for such a moderate usefulness).

Agreed, react-router developers try too much to change and add new features to their baby. it has become a bit of a monster. 46KB for a minified router framework...

Good thing you don't have clients demanding IE compatibility. Bye bye ES6 :-(

Doesn't babel (ES6 --> ES5) solve this issue or is there more to it?

You're right. But I've avoided bringing transpiling or polyfill stuff into our big project at work. I'm the only dev at work who really like JS at all, anyway, so I'm trying to keep it simple for the Java-only crowd.

Don't have a dog in the fight-- I'm using both React and Angular2 in production. I just wanted to add that create-react-app (which was built by a few guys over a weekend or something like that?) I found to be IMMENSELY more useful than angular-cli.

I know a lot of work has been put in to angular-cli and it's been through a few iterations at this point, but I almost wish they would scrap the whole thing and fork create-react-app.

CRA isn't opinionated aside from the config and testing (Jest). It has no router, no Redux, etc.

It was made for demos, proof of concepts, and beginners (at the beginning, maybe not anymore). I don't know how Angular CLI works, but if it works like Ember's, then there's no comparison. Ember CLI generates models, controllers, etc. any kind of thing and it enforces a file and directory structure that makes all Ember apps look the same.

You can totally use typescript with React, in fact it's a game changer. It's actually way more beneficial than with angular, as you have properly typed components all the way down. No crappy string templates that are not checked by typescript.

True story.

But how did you get rid of the implicit anys when using JSX?

I used this compiler flag that forbids them and suddnendly nothing worked anymore. It seemed that almost everything returned any per default.

That compiler flag is wonderful, and so is the newer 'strictNullChecks'

I use these typings: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...

Then create my components like this:

interface Props {

}

interface State {

}

class MyComponent extends React.Component<Props, State> {

}

and everything is typed correctly (beside setState which is impossible to type exactly as of today)

Maybe it was the type definition I used...

Stateless component:

  interface Props {
    bla: string
    ble: number
  }

  export default function MyComponent({ bla, ble }: Props) {

  }

How would you do something like this with stateless components? (Where the component is just a function that takes props)

interface IMyComponentProps { x: number; }

function MyComponent(props: IMyComponentProps): JSX.Element { return <p>{props.x}</p>; }

Regarding the "Flux" frameworks, that's not a problem anymore - basically Redux (which improves on some of Flux's faults) has won. Its developer was hired by Facebook, so I guess it's kind of officially sanctioned now.

Has everyone who switched from Redux to MobX been informed that Redux won and they should switch back?

I didn't understand this. Isn't MobX the "classical" way of databinding everybody frowned upon for years? And now that React finally eased that pain with Flux and then Redux, they bring it back?

I don't think that many people switched to MobX to be honest. It's very similar to knockout observable and while it works, I don't think I would use that approach again. I suspect people like the familiar OO syntax of MobX. I can't think of advantages it has over plain old streams (most.js, flyd.js)

Who has switched? Do you have any example?

I've just finished my first major redux project and found it incredibly slow to develop with. Write an action type constant/action creator/dispatch/reducer/mapStateToProps just to show an element in response to a mouse click? I found myself cutting corners on the UI because the amount of code I'd have to write makes it seem like a huge task.

I'll be evaluating mobx for my next project, definitely, along with Relay. If I can maintain the same view-as-a-function-of-state approach of redux while writing less code, I'm sold.

That's interesting. I've only used redux for one project and you may be right. It is tedious to all those things for every little action.

I'll admit that I hadn't heard so much about MobX yet. Will re-evaluate when I have time.

Yup, this is a major strength of the front end frameworks. It can't be understated in my opinion.

I work daily on a large Angular app and a growing React app, and my React app, while being more pleasant to work with, is also much harder to keep standardised and clean. I'm also already experiencing perf issues because of not using immutableJS, which is quite annoying...

Reply on news.ycombinator.com