Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React and Angular Meeting

docs.google.com

Post reply on HN
Print view View original

21–30 of 60 posts

Re: React and Angular Meeting

#21

Post by dpritchett »

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

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!

I wish they'd gotten Jo's name right. Luckily her work speaks for itself.

Re: React and Angular Meeting

#22

Post by coldtea »

aikah wrote: post #19
brackenbury wrote: post #14

Earlier quoted context omitted.

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

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

Sorry but that's a BS argument if I ever saw one. It's basically an arguemtn from authority and/or popularity.

Something could have 100000 contributors and still be crap and they could still "not get" that it's crap.

JavaEE circa 2002-5 had all the enterprise world using it, tons of aftermarket companies, the best people at SUN and more. And yet, it was utter crap, and a few years later everybody admitted it and were ashamed to be associated with it.

Or take PHP. I'm not against it, but it has tons of contributors (tens of thousands if we count the whole core ecosystem) and it's widely considered a "fractal of bad design".

Re: React and Angular Meeting

#23

Post by pfooti »

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

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 not supported, or customize how things work, not so much. As an example, I submitted a PR to configure where and how broccoli stores its temp directory structure a year ago (./tmp wasn't right for my project), which is still open (and admittedly wasn't the most elegant solution).

Gulp and Grunt, on the other hand, make far fewer assumptions, provide very little in the way of out-of-the-box "just works", and are far more easy to tweak. In my own experience, my issue was getting certain cat/minify/sort processes to work in broccoli (to deal with angular module declaration ordering) was annoyingly complex enough that I just moved to gulp where it was easier (and someone else had already written a gulp plugin).

Re: React and Angular Meeting

#24

Post by brackenbury »

aikah wrote: post #19
brackenbury wrote: post #14

Earlier quoted context omitted.

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

Regarding angular, please see this previous discussion: 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.

Re: React and Angular Meeting

#25

Post by Bahamut »

brackenbury wrote: post #24
aikah wrote: post #19

Earlier quoted context omitted.

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

Regarding angular, please see this previous discussion: 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…

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.

Re: React and Angular Meeting

#27

Post by stupidcar »

M8 wrote: post #3

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

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.

Re: React and Angular Meeting

#28

Post by bsaul »

stupidcar wrote: post #27
M8 wrote: post #3

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

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.

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.

Re: React and Angular Meeting

#29

Post by aikah »

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

Re: React and Angular Meeting

#30

Post by woah »

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…

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.

Post reply on HN