7 ms·

React and Angular Meeting

210 points by scriptle 11y ago

thekaleb 11y ago
what was the context and purpose of this meeting?
M8 11y ago
If Facebook would agree on using standard Typescript, instead of their own thing, that would be amazing.
- mudetroit 11y ago
  It is worth noting with the structural support they have for bare js classes (or really just the js equivalent of classes since they are really just syntactic sugar); React can handle Typescript just fine.
- Ciantic 11y ago
  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?`.
  - vdaniuk 11y ago
    They are not compatible in one quite important area. Declaration files syntax for external modules is different for flow and typescript.
- stupidcar 11y ago
  Typescript isn't a standard though, it's one company's implementation of type-checking for JS. Hopefully, the lessons learned from Typescript, Flow, Dart, etc. will be fed back into the TC39 committee and be used to inform an actual standard for optional types in a future version of EcmaScript.
  - bsaul 11y ago
    At that point, is think typescript should basically become the official next version of javascript (with the added modification to have things like import work in a browser). That would save everybody time. Imagine google, facebook and microsoft agreeing on that, and i think it wouldn't take more than 6 months to see it working in chrome, internet explorer and all the other major browsers would follow. With the new microsoft, and now facebook and google talking to each others, this is the first time something like this could actually become a reality.
- EugeneOZ 11y ago
  If Angular 2 will adopt Flow as replacement for rtts, it will be amazing.
- hajile 11y ago
  As pointed out in their discussion, TypeScript is closer to C# while flow is closer to ML. Those type systems are very different. Considering how functional JS tends to be, I suspect that something based on Hindley-Milner inference could be a great match.
colinramsay 11y ago
THIS MAKES SO MUCH SENSE. I love that they're talking with the Ember guys too, as their approach to a CLI seems to be one of reusing other people's work and just wrapping it. There have been too many cases of wheel reinvention, and I'm particularly glad to see that no-one's talking about yet another package manager. > so folks can declare dependencies like for JSX transpilation This is an interesting one. It'd certainly solve a lot of the toolchain headache for front-end development. It's good to see discussion on animation as it seems to have been a long-term headache for React, at least. I'm not 100% convinced by the Web Worker talk - I think the complexity could mean it's not worthwhile. But it's good to see people unifying their thoughts in order to test it once and for all. All in all, great stuff. It'd be interesting to see if this could be regularised into some kind of "steering group" for the front-end...
joeyspn 11y ago
Finally... there's light at the front-end of the tunnel...
Aleman360 11y ago
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.
- mattmanser 11y 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.
  - knotty66 11y ago
    I thought XAML was really simple to learn.
    - mattmanser 11y ago
      No. No-one's ever said that about xaml.
- brackenbury 11y 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.
  - aikah 11y ago
    > 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.
andrewstuart2 11y ago
> 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 setting up your build, test, deployment environments using whatever combination of grunt & gulp you want to build into your generator. I'm starting to get weary of this constant need to reinvent the incredible tools that we have already instead of iterating and improving them.
- sehr 11y ago
  We’re working with the Ember CLI team who are extracting reusable bits. Working with Joe from broccoli and reusing those bits. Current changing the Angular build from gulp to broccoli. Working with the NPM team on package management and resolution. The package managers that exist today aren’t good, but NPM is the closest of all of them. Sounds like they're doing exactly that!
  - dpritchett 11y ago
    I wish they'd gotten Jo's name right. Luckily her work speaks for itself.
- mixonic 11y ago
  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 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 contents, not tasks. This makes Broccoli a faster and easier to use tool for implementing complex asset pipelines. The main domain object is "trees". A tree represents a directory hierarchy of files that will be regenerated on each build. Broccoli uses directories of symlinks in tmp/ to cache un-changed files from step to step, allowing it to restart a build at any depth and only process those files that change. Some links you might enjoy on Broccoli: * http://aexmachina.info/intro-to-broccoli/ http://aexmachina.info/intro-to-broccoli/ * http://moduscreate.com/better-builds-begin-with-broccoli/ http://moduscreate.com/better-builds-begin-with-broccoli/ * http://hashrocket.com/blog/posts/broccoli-the-build-tool-not-the-vegetable http://hashrocket.com/blog/posts/broccoli-the-build-tool-not... (how Broccoli is used in Ember-CLI) I can't speak to the weariness, but I can say that Broccoli is completely unlike Grunt, Gulp, or Yeoman and without it (or something like it) Ember-CLI and the next generation of build tools would be impossible. Broccoli has been in development since fall of 2013, and been used aggressively by Ember-CLI users since summer 2014. Give it a look!
Stephn_R 11y ago
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
orand 11y ago
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.
- aikah 11y ago
  Well, if AngularJS 2.x is made of modular components as the team says one could be able to ditch Angular view layer and swap it with React.Angular got dependency injection right that allowed easy communication between multiple components. If they plan to ditch scopes and the digest cycle then there would be no relationship whatsoever between directives and injection. The only difference between Angular view layer and React would be the use of Typesript for the former and JSX for the later. > It's as if ReactNative is being treated (strategically) as a more powerful version of PhoneGap. ReactNative is like Titanium/Alloy. It uses native components to render views, not the DOM. So it has nothing to do with Phonegap except for the use of javascript.
  - woah 11y ago
    I'm not that familiar with angular, but the whole advantage of react is that components don't need to communicate at all. Angular seems to be a framework devoted to wrangling state. React eliminates state.
  - mts_ 11y ago
    > ReactNative is like Titanium/Alloy. It uses native components to render views, not the DOM. So it has nothing to do with Phonegap except for the use of javascript. I believe the original poster was referring to the fact that Cordova's whole purpose is to be a testing ground for new browser APIs - and that the goal of the project is to basically become irrelevant at a later point because browser vendors hopefully will have implemented similar APIs. Sort of like a testing ground for web standards. But yes, in a technical sense React Native is closer akin to Titanium than Cordova/PhoneGap in its current state.
  - olegbl 11y ago
bpp 11y ago
ReAngular was an April Fools' joke just 10 days ago: http://moduscreate.com/reangular-angular-react-merger/ http://moduscreate.com/reangular-angular-react-merger/
cturhan 11y ago
When? Where? Is it open to audience?

210 points by scriptle 11y ago

thekaleb 11y ago

what was the context and purpose of this meeting?

M8 11y ago

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

mudetroit 11y ago
It is worth noting with the structural support they have for bare js classes (or really just the js equivalent of classes since they are really just syntactic sugar); React can handle Typescript just fine.
Ciantic 11y ago
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?`.
- vdaniuk 11y ago
  They are not compatible in one quite important area. Declaration files syntax for external modules is different for flow and typescript.
stupidcar 11y ago
Typescript isn't a standard though, it's one company's implementation of type-checking for JS. Hopefully, the lessons learned from Typescript, Flow, Dart, etc. will be fed back into the TC39 committee and be used to inform an actual standard for optional types in a future version of EcmaScript.
- bsaul 11y ago
  At that point, is think typescript should basically become the official next version of javascript (with the added modification to have things like import work in a browser). That would save everybody time. Imagine google, facebook and microsoft agreeing on that, and i think it wouldn't take more than 6 months to see it working in chrome, internet explorer and all the other major browsers would follow. With the new microsoft, and now facebook and google talking to each others, this is the first time something like this could actually become a reality.
EugeneOZ 11y ago
If Angular 2 will adopt Flow as replacement for rtts, it will be amazing.
hajile 11y ago
As pointed out in their discussion, TypeScript is closer to C# while flow is closer to ML. Those type systems are very different. Considering how functional JS tends to be, I suspect that something based on Hindley-Milner inference could be a great match.

colinramsay 11y ago

THIS MAKES SO MUCH SENSE. I love that they're talking with the Ember guys too, as their approach to a CLI seems to be one of reusing other people's work and just wrapping it. There have been too many cases of wheel reinvention, and I'm particularly glad to see that no-one's talking about yet another package manager. > so folks can declare dependencies like for JSX transpilation This is an interesting one. It'd certainly solve a lot of the toolchain headache for front-end development. It's good to see discussion on animation as it seems to have been a long-term headache for React, at least. I'm not 100% convinced by the Web Worker talk - I think the complexity could mean it's not worthwhile. But it's good to see people unifying their thoughts in order to test it once and for all. All in all, great stuff. It'd be interesting to see if this could be regularised into some kind of "steering group" for the front-end...

joeyspn 11y ago

Finally... there's light at the front-end of the tunnel...

Aleman360 11y ago

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.

mattmanser 11y 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.
- knotty66 11y ago
  I thought XAML was really simple to learn.
  - mattmanser 11y ago
    No. No-one's ever said that about xaml.
brackenbury 11y 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.
- aikah 11y ago
  > 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.

andrewstuart2 11y ago

> 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 setting up your build, test, deployment environments using whatever combination of grunt & gulp you want to build into your generator. I'm starting to get weary of this constant need to reinvent the incredible tools that we have already instead of iterating and improving them.

sehr 11y ago
We’re working with the Ember CLI team who are extracting reusable bits. Working with Joe from broccoli and reusing those bits. Current changing the Angular build from gulp to broccoli. Working with the NPM team on package management and resolution. The package managers that exist today aren’t good, but NPM is the closest of all of them. Sounds like they're doing exactly that!
- dpritchett 11y ago
  I wish they'd gotten Jo's name right. Luckily her work speaks for itself.
mixonic 11y ago
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 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 contents, not tasks. This makes Broccoli a faster and easier to use tool for implementing complex asset pipelines. The main domain object is "trees". A tree represents a directory hierarchy of files that will be regenerated on each build. Broccoli uses directories of symlinks in tmp/ to cache un-changed files from step to step, allowing it to restart a build at any depth and only process those files that change. Some links you might enjoy on Broccoli: * http://aexmachina.info/intro-to-broccoli/ http://aexmachina.info/intro-to-broccoli/ * http://moduscreate.com/better-builds-begin-with-broccoli/ http://moduscreate.com/better-builds-begin-with-broccoli/ * http://hashrocket.com/blog/posts/broccoli-the-build-tool-not-the-vegetable http://hashrocket.com/blog/posts/broccoli-the-build-tool-not... (how Broccoli is used in Ember-CLI) I can't speak to the weariness, but I can say that Broccoli is completely unlike Grunt, Gulp, or Yeoman and without it (or something like it) Ember-CLI and the next generation of build tools would be impossible. Broccoli has been in development since fall of 2013, and been used aggressively by Ember-CLI users since summer 2014. Give it a look!

Stephn_R 11y ago

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

orand 11y ago

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.

aikah 11y ago
Well, if AngularJS 2.x is made of modular components as the team says one could be able to ditch Angular view layer and swap it with React.Angular got dependency injection right that allowed easy communication between multiple components. If they plan to ditch scopes and the digest cycle then there would be no relationship whatsoever between directives and injection. The only difference between Angular view layer and React would be the use of Typesript for the former and JSX for the later. > It's as if ReactNative is being treated (strategically) as a more powerful version of PhoneGap. ReactNative is like Titanium/Alloy. It uses native components to render views, not the DOM. So it has nothing to do with Phonegap except for the use of javascript.
- woah 11y ago
  I'm not that familiar with angular, but the whole advantage of react is that components don't need to communicate at all. Angular seems to be a framework devoted to wrangling state. React eliminates state.
- mts_ 11y ago
  > ReactNative is like Titanium/Alloy. It uses native components to render views, not the DOM. So it has nothing to do with Phonegap except for the use of javascript. I believe the original poster was referring to the fact that Cordova's whole purpose is to be a testing ground for new browser APIs - and that the goal of the project is to basically become irrelevant at a later point because browser vendors hopefully will have implemented similar APIs. Sort of like a testing ground for web standards. But yes, in a technical sense React Native is closer akin to Titanium than Cordova/PhoneGap in its current state.
- olegbl 11y ago

bpp 11y ago

ReAngular was an April Fools' joke just 10 days ago: http://moduscreate.com/reangular-angular-react-merger/ http://moduscreate.com/reangular-angular-react-merger/

cturhan 11y ago

When? Where? Is it open to audience?