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

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

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.

https://flowtype.org

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.

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

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.

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.

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.

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.

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.

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)

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

  interface Props {
    bla: string
    ble: number
  }

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

  }

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.

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...

Both are similar in that they are component-oriented.

There are two important factors in my mind.

1. The ecosystem (as you mentioned). React has a clear head start here, but I expect Angular2 to make some gains over time.

2. Angular2 gives you a full framework, and as they say now, a whole platform. React is smaller and you rely on a bunch of other packages to get all the extra features you need. If you want a full solution, Angular2 gives you that.

This can be argued as a good thing or a bad thing. More flexibility with React, but also more things you need to figure out and make a decision about. With Angular2, once you buy in, you don't need to make all of those decisions.

In my particular circumstance, which is to migrate an Angular1 app to a newer framework over time (mainly for the server side rendering features), Angular2 provides a clearer path and offers some nifty features like component styles that allow a similar migration with CSS.

So did Angular 1, and then they threw it under a bus. Now developers have to either refactor for a whole new framework or get stuck with a legacy one.

Javascript ecosystem is becoming so hostile a project deprecates itself in favor of a clean rewrite and the migration path is an afterthought.

Will think twice before adopting google frameworks and tools.

Javascript ecosystem is in dire need of stability and trust.

They didn't just do this "because." There were sound technical reasons to do so. Angular made the correct decision, in my opinion, and decided to cut its losses immediately and right the wrongs within the framework.

Not saying ng-2 is not an improvement, just that it's a big change to take in.

But to contrast all three, I'll pick the area I'm most interested in - templating. The purpose of a framework is to render a dynamic view without the programmer having to wire up every state transition with a corresponding view transition. This is done by templating content with state, mediated by the framework. And how this is done affects the entire design of the framework and apps written on them.

Angular and Ember allows state and logic inside HTML. They figure out which state variables and corresponding templates go together and re-renders them automatically. The pro is that writing a modified version of HTML without too much code lets us have a dynamic app running in no time. The con is that there is a new language to study - with its own parser, control structures, scoping, and quirks.

React on the other hand lets us specify templates as Javascript functions which are run whenever the state changes. The pro is that there is no new language abstraction to learn; it re-uses Javascript. External DSLs especially are in an uncanny valley - they're not full-blown languages but have enough quirks to be bothersome. Language abstractions forces a virtual machine (the language parser/interpreter) to evaluate the code, and it is an opaquely magical layer that makes it hard to see the entire stack of abstractions during day-to-day programming. It also forces a separation between our view (written in the templating language) with the rest of our code.

The con of this approach is simply more code to write; the programmer has to anticipate and inform the framework of any state changes. With setState this isn't as bad a trade-off as we'd imagine. And MobX meanwhile brings an Angular like state abstraction to React - it watches over observables and automatically fires re-render.

The other big difference is that React is not opinionated. It is a very much a framework alright, but it for example doesn't ship with a router, nor does it prescribe a framework for organizing the code. Ember has so far done a great job here - I often wish I could combine the Ember ethos of backwards compatibility, great documentation, and a fanatic love for the existing users of the framework, with the way React approaches templating and composing components. I haven't had the chance to look at Angular 2, but for me, Angular 1 started the front-end revolution happen, and I'm curious what they have done this time.

Cx adds declarative data-binding, controllers and router on top of React and includes composable widgets and charts. It looks for a sweet spot between development speed and freedom to do whatever you want. Here's a quick example https://cx.codaxy.com/fiddle/?f=42vDn4I1.

Disclaimer: I'm the author of Cx.

What I need time to get around to is the concept of controllers and how it works when we want to compose things together. For example, how to write a multi-select widget that exposes a clear API to the rest of the world (onChange), and encapsulates all other details within. Cx does deserve a deeper look, and I'll definitely give it a whirl some time. Also kudos for the extensive documentation you've so far written!

Here's an example of a complex lookup field in practice. https://github.com/codaxy/cx-starter-kit/blob/master/app/rou...

It's perfectly fine to add multiple bindings between lookup options and field's data. That works for multivalue fields too.

If you have any other questions I'm happy to answer in this thread https://news.ycombinator.com/item?id=12495728

> Angular and Ember allows state and logic inside HTML.

State updates do not occur in Ember templates. Templates specify the follow data from one component to another, as well as callbacks which are names of actions defined in a javascript portion of a component, or a parent component.

But it does not allow you to specify how state is updated within the template. In terms of Logic, there's just if statements & loops which is pretty conservative imo.

edit: rephrasing words

But by logic I meant all sorts of control structures, which though looks light-weight at first, needs a large number of language elements to function. To name a few: variables, expressions (which in turn need operator precedence rules), scoping, and even composition if we count partials/templates with it. Loops on the other hand requires not just simple array iteration syntax, but also over hashes, and it also needs other constructs like filtering (`todo in todos | filter:search`).

This is my biggest complaint with adding logic to text templates; behind the apparent simplicity there is always an entire language.

All good, I'm probably tired (Australian time).

Maybe it's my inherit bias as an Ember user, but I'd argue Ember's templating language is alot simpler than you're suggesting

> But by logic I meant all sorts of control structures, which though looks light-weight at first, needs a large number of language elements to function. To name a few: variables, expressions (which in turn need operator precedence rules), scoping, and even composition if we count partials/templates with it.

Admittedly partials are a little weird, while I don't see them very often, it's still a fair point, however Ember templates don't deal with operator precedence as it doesn't have binary operators (entirely polish notation).

> Loops on the other hand requires not just simple array iteration syntax

Iteration doesn't have a blessed syntax, but instead utilises syntax that can be utilised by other components, and a better way to think of it is, the block inside the component is actually a function being passed to the component, which the component calls with every item of the collection.

> but also over hashes, and it also needs other constructs like filtering (`todo in todos | filter:search`)

It doesn't have pipes/filters, as that's easily expressed as a computed property in the js portion of a component. And I personally think scoping is pretty predictable imo.

Maybe you're just making a general remark about templates in general & i've read too far into it, then fair enough but in the case of Ember some of those don't apply, imo.

> behind the apparent simplicity there is always an entire language

Technically this is true, but I'm not sure why this matters, especially if it's trivial to learn? Because flip side of the argument, technically JSX is a different language to JS & HTML with even more complex semantics than a templating language because it carries the semantics of JS on top of it. You could make the same argument in favour of css over SASS/LESS, so I don't really see this as a big deal

SASS and LESS both add language semantics over CSS and suffer from the same problem. So does for example Jekyll's templating language. But in case of CSS, the language additions are a practical necessity - it lacks even basic abstractions, which the pre-processors provide.

So there - trade-offs.

I've written in more detail about this topic at http://www.jasimabasheer.com/posts/evolution-of-view-templat..., if you are interested.

React expects you to do your development on some flavor of Unix, and really doesn't have a sane plan for Windows, so you lose VS.NET and its huge productivity gains. And it needs tools upon tools upon tools to set up, whateverify, transpile and pack the files you write into something that can display in a browser. Again, this all seems to want to run from a Unix command line.

I want to edit some HTML and Javascript, then reload the browser and see my changes. Angular isn't perfect, but at least it lets me do my thing without adding a bunch of extra hoops.

I think this was true six months ago but now there is create-react-app. You might want to try it out - you won't need to whateverify your code, you just need that one tool. Also it works on Windows.

https://github.com/facebookincubator/create-react-app

I want to edit some HTML and Javascript, then reload the browser and see my changes.

With create-react-app the browser will know you've made a change, and reload for you ;-)

The fun thing watching the new world of Javascript is that overtooling is so built in to everything that nobody even realizes how many tools they're using. You can't even install this thing until you have the standard pile of javascript tooling in place. And it never occurred to them to even mention how to get said pile set up.

Once set up, this still uses all the same stuff. It just removes a few steps to produce the Big Red Button you press to run it all.

But then again, the thing about the overtooling is: I can't find anything in my React stack that is unnecessary or can be removed. And really, all it is is React, Redux and Webpack. I think the complexity of front-end Javascript development is blown a little bit out of proportion.

React could be replaced with Preact or Inferno.

Redux could be replaced with MobX or RxJS.

Webpack could be replaced with JSPM.

No thanks.

Isn't that hot reloading of components which they say is unsupported?

Our projects compile from Typescript to ES6 and then ES6 to ES5 through babel. All of that takes place in webpack, and it was pretty easy to setup. We also all use Visual Studio Code and it's a joy to work with.

If you use something like hjs-webpack it gives you (hot-)reloading for code changes out of the box.

I despair these days at the ridiculous number of command line tools you need to run, but once you've completely wasted 2 or 3 days of your life on these pointless things, cut and pasting command lines from setup instructions that give no indication what any of the flags actually mean, you can forget about them.

There were days when you just had to run an installer and then you were good to go. Or just get the latest version of the tools (and by tools I mean actual tools with a GUI and everything, gasp!) That's obviously really untrendy now.

But yeah, you can set it all up in VS to deal with the insanity for you. Good thing too, as the ASP.Net team have been drinking heavily from the command line insanity kool-aid.

And worse still, yes, that's the case for most people. Most people prefer using mice + GUIs. Why are we going back in time? Why can't we have tools that work as both GUIs and CLIs?

CLIs are great for automation (and keyboard obsessed users).

GUIs are great for discoverability and making it obvious to users what the 'normal' usage is.

It's absolute madness to go back to the days of CLIs.

Have you considered that part of the problem is the stack you use causes other people to be unproductive because it's not clear what all the tools you're using are doing?

I've done both React projects with Python and C# apis. React is perfectly usable in VS.NET - are you aware of the Task Runner Explorer - https://blogs.msdn.microsoft.com/webdev/2016/01/06/task-runn... - hooks whatever you want into the build cycle, watches etc - once I discovered that, everything just clicked into place.

Yes, the majority of code is still written by Evan, due to speed required. but we know that vue is heading in right direction.

React would mean to rewrite your whole application as it has a totally different basic concept. Following the ng2 migration path you're able to migrate slowly.

With that, we could put a React component anywhere in our Angular app, and reuse Angular directives inside of React until we got around to rewriting them.

That ended up quite smooth.

The "React component inside of Angular directive" is fairly trivial and there's a million examples on the net. Just make a directive that calls ReactDOM.render on the element in the link function.

Angular inside of a React component is harder to google for, namely because there's so much misinformation saying its impossible.

It ended up being a variation of the discussion here: https://github.com/ngReact/ngReact/issues/80

(The code in the example isn't quite there...and its been a very long time since I did it, so I don't quite remember the tweaks I had to make).

I don't see what is a problem to just drop in React into `<script>` tag and use for single part of the page, gradually refactoring stuff.

1. as others mentioned its a fuller framework, mostly akin to using react with redux (or flux etc...) and a di framework. This also means that angular 2 third party components are probably easier to integrate.

2. Reactive Expressions, which angular2 uses in many places, is a joy to work with (though they might become maintenance hell later on I think). You can use RxJs with React of course, but it's easier when your framework is based on it

3. It uses string templates - which means that some things such as dynamic templates and per user customization of html would probably be much easier to do then in React.

4. It has Ionic - which is much much faster to develop for mobile with then react-native (though obviously there are important differences). It's unlikely that an Ionic like framework for react will gain traction with react-native to compete with.

The key with React is that you manipulate JS instead of HTML. In my experience, using JS to manipulate elements turns out to be easier and a much better experience than the conventional way of using templates.

For me, the power offered by Razor(cshtml) is too much to abondon.

Only downside is trying to hire Scala frontend devs.

http://www.lihaoyi.com/hands-on-scala-js/#Autowire

material-ui's tutorials are really bad examples on this. They teach you to import from specific dir path inside material-ui. (e.g. import Pen from 'material-ui/lib/pen' or whatever)

Instead, they should recommend: import { Pen } from 'material-ui' since most of their exports are already in material-ui/src/index.js file (or some index.js file from package.json's main part)