

React and Angular Meeting - scriptle
https://docs.google.com/document/d/1QZxArgMwidgCrAbuSikcB2iBxkffH6w0YB0C1qCsuH0

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

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

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

~~~
adambratt
The problem is that a lot of these js tools that are being built are being
built on top of other hobbyist js libraries that are built on top of others
that creates this weird chain of dependency that appears to arise from nothing
other than the author's coding style preference.

Take a look at just one of gulp's dependencies (and arguably one of the most
important) vinyl-fs which it uses for file watching. This is the actual chain
of abstractions for the file watching functionality in gulp.

vinyl-fs < glob-watcher < gaze < graceful-fs

    
    
        * gulp.watch uses vfs.watch provided by vinyl-fs
    
        * vfs.watch is actually just glob-watcher (lol)
    
        * glob-watcher is a simple 20 line wrapper around gaze watch
    
        * gaze uses graceful-fs to watch full paths
    

4 levels of library abstraction for file watching. Something that the built-in
fs.watch handles natively.

Here's the actual description of the gaze library "A globbing fs.watch wrapper
built from the best parts of other fine watch libs."

Yet apparently that wasn't enough as the gulp authors had to toss in 2 more
layers on top of it. And at the end of the day gulp still sucks for watching
files on linux.

I understand that there are other pieces of vfs that are being used by
gulp...but it still doesn't make any sense to me how there can be SOOO many
accepted libraries dealing with just file watching. And instead of making a
pull request for new features on existing libraries, developers are just
building other libraries around them to do what they want.

There's so much fragmentation in the JS world and no one can seem to ever
agree to work together on anything. In comparison, in the Python world there's
pretty much one agreed upon library for something like file watching
"watchdog". There are alternatives but it stands out above all the rest.

~~~
contrahax
fs.watch actually doesn't work just fine, not sure what gave you that
impression. We went with the best file watcher that was around at the time
because we didn't feel the need to write our own. The layers of abstraction
are there so other people can make use of them as modules. We are (and have
been) evaluating other solutions for file watching but gaze is still the best
option for us to use under the hood.

~~~
thealphanerd
I've been stuck in file watching hell before... CHOKIDAR!!!!!

I actually had a really interesting conversation with Bert Belder about some
of the lower level problem with file watching. It came up that perhaps there
could be a working group around fixing this issue.

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

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

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

~~~
brackenbury
Regarding angular, please see this previous discussion:
[https://news.ycombinator.com/item?id=8651641](https://news.ycombinator.com/item?id=8651641)
There appears to be lots of things the 1000 contributors didn't get. They are
after all abandoning Angular 1 and working on Angular 2 which is a completely
new framework which just happens to share the same name as the older
framework.

I agree designers shouldn't touch code (i.e., javascript). But designers
should be able to directly edit the visual aspects (i.e., templates). This was
one of the goals of XAML.

~~~
Bahamut
This discussion about what contributors got/didn't get is completely off -
Angular was conceived at a time when a lot of what we have today in standards
and better practices weren't here. To a large degree, Angular popularized many
of them in frontend development, or at the least highlighted a need for a more
standardized solution.

Angular has a lot of strong & smart contributors. Angular also grew more
organically, and broke a lot of new ground. That says nothing about what
contributors got/did not get. To equate the two requires a false assumption.

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

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

------
thekaleb
what was the context and purpose of this meeting?

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

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

------
Stephn_R
_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

------
cturhan
When? Where? Is it open to audience?

