React and Angular Meeting • Hacker News Board

Re: React and Angular Meeting

#31

Post by mts_ » Sat, Apr 11, 2015, 4:48 PM UTC

aikah wrote: post #29

orand wrote: post #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.

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…

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

Re: React and Angular Meeting

#32

Post by woah » Sat, Apr 11, 2015, 4:49 PM UTC

pfooti wrote: post #23

mixonic wrote: post #9

Earlier quoted context omitted.

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…

In my experience using grunt, gulp and broccoli as task runner / build systems for complex applications, they all end up doing about the same thing. In a way, it makes a lot of sense that broccoli is part of the Ember-CLI system - I found broccoli to be the most opinionated of the runners. As long as your structure mapped easily onto the opinions of broccoli, things were easy and speedy. If you want to do something n…

I used to be really into gulp, until I discovered that I could replace my entire gulp file with a 1 line shell script in package.json

Re: React and Angular Meeting

#33

Post by amelius » Sat, Apr 11, 2015, 4:50 PM UTC

orand wrote: post #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.

If they want the web to win, then why didn't they design ReactNative to have an API that is a subset of HTML (where possible)?

With their current API, we can't use the code written for RN on the web.

Re: React and Angular Meeting

#34

Post by olegbl » Sat, Apr 11, 2015, 4:50 PM UTC

aikah wrote: post #29

orand wrote: post #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.

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…

> The only difference between Angular view layer and React would be the use of Typesript for the former and JSX for the later.

I think you meant either

1. the use of HTML for the former and JSX for the later

2. the use of TypeScript for the former and Flow for the later (this isn't true, can use either one with either framework)

Re: React and Angular Meeting

#35

Post by TazeTSchnitzel » Sat, Apr 11, 2015, 4:54 PM UTC

amelius wrote: post #33

orand wrote: post #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.

If they want the web to win, then why didn't they design ReactNative to have an API that is a subset of HTML (where possible)? With their current API, we can't use the code written for RN on the web.

Because HTML doesn't map to native components and provides a subpar experience.

Re: React and Angular Meeting

#36

Post by adambratt » Sat, Apr 11, 2015, 4:55 PM UTC

andrewstuart2 wrote: post #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…

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

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

Re: React and Angular Meeting

#37

Post by contrahax » Sat, Apr 11, 2015, 5:29 PM UTC

adambratt wrote: post #36

andrewstuart2 wrote: post #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…

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…

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.

Re: React and Angular Meeting

#38

Post by contrahax » Sat, Apr 11, 2015, 5:31 PM UTC

woah wrote: post #32

pfooti wrote: post #23

Earlier quoted context omitted.

In my experience using grunt, gulp and broccoli as task runner / build systems for complex applications, they all end up doing about the same thing. In a way, it makes a lot of sense that broccoli is part of the Ember-CLI system - I found broccoli to be the most opinionated of the runners. As long as your structure mapped easily onto the opinions of broccoli, things were easy and speedy. If you want to do something n…

I used to be really into gulp, until I discovered that I could replace my entire gulp file with a 1 line shell script in package.json

If you can do it in one line of shell then do it - you don't need a build system. I don't understand why everyone sees it as a competition - just use the right tool for the problem you need to solve.

Re: React and Angular Meeting

#39

Post by randomfool » Sat, Apr 11, 2015, 5:34 PM UTC

brackenbury wrote: post #14

Aleman360 wrote: post #6

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…

1) Type Converters to convert attributes from strings to real types

2) The options on Binding- one way, two way, etc

3) Element lifecycle events- HTML custom elements are a small step, but still missing so many

4) Extensible layout model.

5) Control Templates- shadow DOM is an attempt to do this, but is sub-par. Particularly in how styles and events are handled.

Re: React and Angular Meeting

#40

Post by mixonic » Sat, Apr 11, 2015, 5:38 PM UTC

pfooti wrote: post #23

mixonic wrote: post #9

Earlier quoted context omitted.

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…

In my experience using grunt, gulp and broccoli as task runner / build systems for complex applications, they all end up doing about the same thing. In a way, it makes a lot of sense that broccoli is part of the Ember-CLI system - I found broccoli to be the most opinionated of the runners. As long as your structure mapped easily onto the opinions of broccoli, things were easy and speedy. If you want to do something n…

> In my experience using grunt, gulp and broccoli as task runner / build systems for complex applications, they all end up doing about the same thing.

This may be true for a codebase of trivial size. With a sizable codebase and many build steps (defeaturefy, babel, es6 modules, es3recast, jshint, jscs) you quickly see grunt and gulp fall flat.

Gulp and Grunt absolutely have a simpler API for blindly chaining tasks. And they have the ability (as task runners) to define multiple tasks and compose them.

Broccoli is tricky to learn. In Ember-CLI we go out of our way to make it invisible to devs who shouldn't need to care what tool is running the internals. For the internals however, it is definitely the correct tool.