React and Angular Meeting
docs.google.com
React and Angular Meeting
1–10 of 60 posts
Re: React and Angular Meeting
#2what was the context and purpose of this meeting?
Re: React and Angular Meeting
#3If Facebook would agree on using standard Typescript, instead of their own thing, that would be amazing.
Re: React and Angular Meeting
#4THIS 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...
Re: React and Angular Meeting
#5Finally... there's light at the front-end of the tunnel...
Re: React and Angular Meeting
#6These 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.
Re: React and Angular Meeting
#7> 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.
Re: React and Angular Meeting
#8> 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…
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!
Re: React and Angular Meeting
#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 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://moduscreate.com/better-builds-begin-with-broccoli/
* 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!
Re: React and Angular Meeting
#10If Facebook would agree on using standard Typescript, instead of their own thing, that would be amazing.
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.