Live data from Hacker News

React and Angular Meeting

docs.google.com

11–20 of 60 posts

Re: React and Angular Meeting

#11

These guys should take a look at how XAML is implemented. I feel like they're trying to solve tons of problems that Microsoft already did 10 years ago.

The trouble with xaml is that it has such a steep learning curve that it takes a while to reach the point where you start appreciating the design decisions.

Re: React and Angular Meeting

#12
post #3

If Facebook would agree on using standard Typescript, instead of their own thing, that would be amazing.

As long as typed syntax of Flow and TypeScript are compatible, it doesn't matter what they do with Flow.

There are things Flow gets right compared to TypeScript. For instance requiring to check the nullness when using the question mark type e.g. `SomeType?`.

Re: React and Angular Meeting

#13
post #9

> There are a lot of JS tools, but none of them do what we want. We’re trying to coordinate them. We want to provide a good default experience out of the box, so we’re building a CLI to: scaffold, skeleton files, set up build, set up testing environment, possibly even deployment Was there something wrong with the yeoman & grunt/gulp combo? The yeoman tool is great for the scaffolding and skeleton story, and even for…

Yeoman, Grunt, and Gulp are (I believe) all various implementations of a task runner. They chain tasks in different ways, but at the end of the day think of your asset build as a set of discrete steps. Broccoli ( https://github.com/broccolijs/broccoli ), the build tool written by Jo Liss and supported by the Ember community, is truly an asset pipeline tool. It is concerned with transformations to filesystems and file…

Yeoman is for scaffolding

Re: React and Angular Meeting

#14

These guys should take a look at how XAML is implemented. I feel like they're trying to solve tons of problems that Microsoft already did 10 years ago.

And what is it that you think is good in XAML? Two-way data binding? Angular and Ember tried that and are now moving away from it. XAML is poorly designed, especially those over-complicated data bindings. I prefer the jQuery way where the template just contains an id or class, then you set data from code, as opposed to the template trying to pull data. The template needs to be simple (since designers also have to edit it), and the intelligence should be in code.

Re: React and Angular Meeting

#15

These guys should take a look at how XAML is implemented. I feel like they're trying to solve tons of problems that Microsoft already did 10 years ago.

The trouble with xaml is that it has such a steep learning curve that it takes a while to reach the point where you start appreciating the design decisions.

I thought XAML was really simple to learn.

Re: React and Angular Meeting

#16
post #9

> There are a lot of JS tools, but none of them do what we want. We’re trying to coordinate them. We want to provide a good default experience out of the box, so we’re building a CLI to: scaffold, skeleton files, set up build, set up testing environment, possibly even deployment Was there something wrong with the yeoman & grunt/gulp combo? The yeoman tool is great for the scaffolding and skeleton story, and even for…

Yeoman, Grunt, and Gulp are (I believe) all various implementations of a task runner. They chain tasks in different ways, but at the end of the day think of your asset build as a set of discrete steps. Broccoli ( https://github.com/broccolijs/broccoli ), the build tool written by Jo Liss and supported by the Ember community, is truly an asset pipeline tool. It is concerned with transformations to filesystems and file…

Grunt and gulp are task runners, yeoman is a scaffolding tool that does exactly that, and all the generators I've used and written will scaffold out Grunt or Gulp tasks which take care of the build/test/deploy story. Usually with live-reload and filesystem watches for autoupdate.

Re: React and Angular Meeting

#17
fingers crossed

I am so happy to see how much effort and consideration that everyone is putting in towards React and Angular as a Modern Web App Framework standard*

* - Standard for Client Side Web Frameworks

Re: React and Angular Meeting

#18
post #12
post #3

If Facebook would agree on using standard Typescript, instead of their own thing, that would be amazing.

As long as typed syntax of Flow and TypeScript are compatible, it doesn't matter what they do with Flow. There are things Flow gets right compared to TypeScript. For instance requiring to check the nullness when using the question mark type e.g. `SomeType?`.

They are not compatible in one quite important area. Declaration files syntax for external modules is different for flow and typescript.

Re: React and Angular Meeting

#19

These guys should take a look at how XAML is implemented. I feel like they're trying to solve tons of problems that Microsoft already did 10 years ago.

And what is it that you think is good in XAML? Two-way data binding? Angular and Ember tried that and are now moving away from it. XAML is poorly designed, especially those over-complicated data bindings. I prefer the jQuery way where the template just contains an id or class, then you set data from code, as opposed to the template trying to pull data. The template needs to be simple (since designers also have to edi…

> I prefer the jQuery way where the template just contains an id or class

Are you saying you "got" what a project like angular that has more than 1000 contributors "didn't get"?

> The template needs to be simple (since designers also have to edit it), and the intelligence should be in code.

Designers shouldn't touch the code. Designers should stick with design. It's your role as a developer to do design integration. At best designers should only deal with CSS and HTML, they should never see a template tag nor be responsible for placing them inside html files.

Re: React and Angular Meeting

#20
Fascinating comment from Christopher Chedeau of React: "The end game isn’t ReactNative. We want the web to win. Would be great for Angular to try to implement on top of our same primitives to see if we could share the work."

It's as if ReactNative is being treated (strategically) as a more powerful version of PhoneGap.

Post reply on HN