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

Angular 2 Core

docs.google.com

Post reply on HN
Print view View original

161–170 of 279 posts

Re: Angular 2 Core

#161

Post by gfodor »

skore wrote: post #36

To everybody trying to make this into a tech fight about Angular vs. React/whatever, I've been repeating this like a mantra and even mentioned it in a talk on javascript once[0]: You can argue about the minor details of the tech stack till you turn green and blue, but Angular wins because it succeeds in the only metric that really counts. jQuery: (for reference) 5,656 commits 7 branches 122 releases 199 contributors…

The only thing that matters wrt software libraries is if it helps deliver and maintain software more efficiently and with less frustration than others. There are three dimensions to this, how great is the library today (with regards to efficiency of construction and maintainability of software), how much better (or worse) will it get in the future, and how long will it be around. Unfortunately these things are hard to measure and predict.

The number of committers only gives you some insight to any three of these things, and can actually mislead you. The Javascript ecosystem is ridiculously fast moving (which is a nice way to put it :)) so number of committers doesn't tell me if all those folks will just jump onto the next thing that comes along. Also, the Javascript community has developers of a wide variety of skill levels, so the number of committers doesn't necessarily say much about the quality of the library without understanding who these committers are. I'd argue there is often a small number of key contributors to any open source project, with other folks contributing small patches to fix bugs or minor enhancements, so the total number of committers doesn't tell you a much more important thing: who are the key contributors, what is their background and views on software engineering, and how likely are they to remain committed to the project over the long term?

It seems to me the main thing Angular has going for it is that Google has bought in to it, so that means no matter how flawed it is (or not), it's not going anywhere anytime soon so you can be sure security fixes and bugs will continue be addressed over the long term. Then again, Facebook seems all-in on React (and I'm not sure about Ember) so maybe this isn't much of a differentiator.

Re: Angular 2 Core

#164

Post by spicyj »

Bahamut wrote: post #89
purpletoned wrote: post #80

Earlier quoted context omitted.

> Angular has a void with the lack of a useful enough eventing solution - $scope eventing ... I've found that using a publish/subscribe system for communicating between components makes them more loosely coupled and modular. In most cases, the components I've written are naturally somewhat slightly coupled so I just pass around functions as props from parent to child components. > HTML mixed in with JS via JSX is als…

> I've found that using a publish/subscribe system for communicating between components makes them more loosely coupled and modular. In most cases, the components I've written are naturally somewhat slightly coupled so I just pass around functions as props from parent to child components. I agree - my company is going to open source an event machine for Angular sometime in the next couple of months which should addre…

> Unfortunately it doesn't seem like React documented React.DOM :(

React.DOM.div(), etc. are part of React's public API -- if we didn't document them, that's a mistake.

Re: Angular 2 Core

#165

Post by joeevans1000 »

Can anyone suggest which practices can be added to the use of 1.3* to ease the transition to 2.0? For instance, if I start using grunt-ng-annotate or gulp-ng-annotate now, will that help ease the transition? If it would, I'd be curious what other things I could do to make the switch less abrupt.

Re: Angular 2 Core

#166

Post by Bahamut »

spicyj wrote: post #164
Bahamut wrote: post #89

Earlier quoted context omitted.

> I've found that using a publish/subscribe system for communicating between components makes them more loosely coupled and modular. In most cases, the components I've written are naturally somewhat slightly coupled so I just pass around functions as props from parent to child components. I agree - my company is going to open source an event machine for Angular sometime in the next couple of months which should addre…

> Unfortunately it doesn't seem like React documented React.DOM :( React.DOM.div(), etc. are part of React's public API -- if we didn't document them, that's a mistake.

At the least, I cannot find any mention of the specifics anywhere on the main GitHub page - this is the best that I can tell: http://facebook.github.io/react/docs/top-level-api.html#reac... . I do know the recommendation is to use JSX, and I can see why, but more visibility of the API would be better.

Edit: As a note, I did find out how it worked by doing source code diving two months ago.

Re: Angular 2 Core

#167

Post by RivieraKid »

bryanlarsen wrote: post #23
gasping wrote: post #17

Angular 1 developers should see this as an opportunity to abandon Angular and move on to React. React is by far and away the best the market has to offer right now. From my perspective client-side applications are a solved problem thanks to React.

Angular 2 steals the best ideas from React and Meteor and everything else that has come along in the 5 years since Angular 1 came along, and puts them together in a really nice fashion. IMO, definitely the best of breed for the time being. A few months later, something new and shinier will come along. Really the choice comes down to whether you're a "single big framework" or "lots of little libraries" type of guy. Th…

I have zero knowledge of Angular, just skimmed through the presentation but didn't find it very similar to React. What ideas does it steal? Specifically, does it internally do diffing thing as React?

Re: Angular 2 Core

#168

Post by ChrisCinelli »

I understand wanting to appeal to the same user base and tell that it was develop by the same team. It's a brand decision. Nevertheless Angular 2 "deserve" a completely new name. It has no resemblance of Angular 1.x. Welcome to a new framework.

Re: Angular 2 Core

#169

Post by malandrew »

rantanplan wrote: post #160
malandrew wrote: post #140

Earlier quoted context omitted.

Engineering is taking all the bits and pieces out there and choosing the right ones for the problem you're trying to solve with engineering. It's not just choosing those components, but doing all the work to figure out how they should work together to solve your problem and building the pieces that bring them all together. Using something that does all that for you is tantamount to outsourcing all the engineering wor…

You are in a different conversation. Unless you're trying to tell me that people who build e.g. KDE with the Qt framework are plumbers and people who develop with Backbone.js are engineers. In which case I wouldn't want to engage in such a discussion.

Nice strawman.

Neither Angular nor React nor Backbone are equivalent to KDE or Qt, so those are false equivalencies use to construct a poor excuse for a strawman.

The user agents (browsers) and the web as a platform is the closest equivalent to Qt, since collectively, they abstract away all the differences between platforms as Qt does. Collectively and individually they represent excellent examples of engineering. The problem with them is that the problem they are trying to solve basically changed from what Tim Berners-Lee originally tried to solved. He tried to make a hyperlinked document platform, not an app platform. The web is now trying to evolve to supporting apps while also remaining a good documentation platform.

React would be most closely equivalent to added the paint/draw and retain-mode graphics part of Qt to the web. Flux and its different implementations and the various libraries out are likely equivalent to different solutions for events and data stores available in the Qt ecosystem, but I'm not a Qt developer so I wouldn't know. Those who built react are doing engineering as are those who build with react, it's just that the latter are absolved from solving the engineering problems related to render/paint/layout and retain-mode graphics.

Angular is an attempt to bundle everything together (render/draw, events, data) into one monolithic framework solution, doing reasonably well, but none exceptionally well. Those who built angular are doing engineering. However, those who build with angular are basically doing plumbing.

People who build with KDE and people who build with angular are basically performing the same type of work.

I don't know what backbone is equivalent to in the KDE or Qt world, but I would imagine it's probably some early library/quasi-framework in the Qt world when it was still the wild west and there weren't very good engineering practices and project organization strategies in Qt projects.

I can't believe I wasted my time responding to your logical fallacy.

Post reply on HN