Live data from Hacker News

Angular 2 Core

docs.google.com

201–210 of 279 posts

Re: Angular 2 Core

#201

I'm quite disappointed by this presentation, I see only new syntax everywhere for approximately zero benefit. There is not even any mention to the Object.observe integration which would be the most exiting feature to improve Angular apps. Angular looks and feels now like a Java framework, with ugly decorators and bloated APIs, that's really sad...

Agree 100%. Things like dependency injectors have no real place in JavaScript, where programmatic wiring and modules already solve the problem in an idiomatic way. Angulars modules factories services etc are absurd and attempt to reinvent what the language naturally provides.

The topic of DI and/or IOC in dynamic languages is an interesting one.

I've seen a similar debate play out in the Python world and the debate seems to polarize into two camps:

"You have never built anything complex enough and therefore you don't understand the benefits of DI/IOC"

vs.

"You've come to a dynamic language from some verbose public static void main hell-hole and are suffering from some form of Stockholm Syndrome"

Re: Angular 2 Core

#202
post #32
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.

I remember when I looked into React that I was basically writing HTML templates into javascript code. Are there ways around doing that now with React? Because I find that to be a pretty big affront to separation of concerns

Having used React for a year now, I have long concluded that React doesn't violate any separation of concerns at all.

React implements UI views and controllers. You write views that know how to render themselves, and then you write views that control them; the latter type of view fulfills the role of the classical MVC controller.

For example, consider how Cocoa works. It's a classical MVC framework: You have a view controller, which mediates between data and views. The controller doesn't know how to render anything, but it listens to data modifications, and sends update commands to the views; it also listens to changes to views and propagates those changes to the data model. (You can also let Cocoa Bindings do it for you, for the most part.)

In a single app, you typically end up with many such controllers, typically one per window, and controllers can reference each other to facilitate communication; also, there are often controllers that individually control just a single view, because it's easier to encapsulate reusable components that way. For example, if you need a text field that autocompletes, you could subclass NSTextField and build this special behaviour into the view itself, but it's cleaner to create a controller that can bind to any normal NSTextView.

In React, you have the same distribution of controllers (some handling big, multi-view layouts, some targeting discrete views), but the controller actually takes part in the view hierarchy: A controller has views as its children. It may not even use DOM elements, but consist entirely of custom view components. And it does exactly the same stuff as a controller would. For example, it may contain this:

    
      
      
    
In this example, TextField and NumericField would be generic view components, just like the standard Cocoa views; the controller wouldn't be doing anything view-related like working with the DOM, but it would mediate between the data model and the child views that it controls.

This is very much like building out a form in Interface Builder and connecting the actual controls to variables using IBOutlets. In fact, I would argue that there is hardly any distinction at all. The difference is that the UI is declared in the controller. And why not? Interface Builder is separate, and keeps its view data stored separately, because a WYSIWYG editor can't touch code. (Actually, Delphi showed that it was possible, but that's another story.)

The fact that there is a separation isn't actually useful to anyone. You generally cannot edit the view layout without breaking code, and you can't edit the code without breaking the view: They have to be maintained completely in sync with each other. So you might as well just keep the view layout in the same file as the controller. Which is what React does.

Re: Angular 2 Core

#203
post #124

Earlier quoted context omitted.

>> where programmatic wiring and modules already solve the problem in an idiomatic way Can't agree with that. Not sure what you mean by 'programmatic wiring' as it sounds vague, but certainly modules do not solve the same problem that DI solves. Modules, (assuming you mean stuff you require() or equivalent), provide module-level dependencies but do not provide object instances. For example, if an instance of House re…

For example, if an instance of House requires a Door it is not enough to just require('Door'). You still have to do the equivalent of `new Door()` in your House module to get an instance. By doing so within the House module you just tightly coupled House to Door (your House now knows how to create Doors). So what? What is so bad about House and Door being "tightly coupled"? Here's a House constructor that can take an…

I felt the same way about DI until I watched this video: http://www.youtube.com/watch?v=_OGGsf1ZXMs

Re: Angular 2 Core

#204
post #148

Earlier quoted context omitted.

I agree. There is virtually no way you can smoothly upgrade an Angular 1 project to this. You'd have to redo most of it from scratch. There are a lot of huge projects that are built on Angular 1 -- many enterprise products too. And this is a huge blow to maintenance. It might be a reason for a lot of people dropping Angular and going for something that makes more business sense. Maybe it's React's time to shine.

The thing with React is that either Facebook's engineers are incredibly prescient or lucky. React very is really well designed and feels natural with ES6. It's so incredibly designed, even without the ES6 optimizations of 0.12.0 (coming soon) you can code today in ES6 (I use 6to5 with JSX transformer harmony just in case).

Yeah I am betting on React. I am not a Web GUI developer and learned about Angular and now React just out of curiosity. Well I tried to learn Angular and got stuck at the termology soup of "directives", "digest cycles", "factories", "services", "dipendencies", "scopes". I understand all those English words but I still don't quite have an idea of how they are helping me.

With React somehow the whole data flow and how components work and even JSX make a lot more sense.

Re: Angular 2 Core

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

Not to mention, it's much simpler than Angular. You can get upto speed with React in 2 or 3 days. Once you make the shift to specifying single states for your interactions and letting React rebuild the DOM on changes, you'll never go back to anything else.

100x that.

Never got beyond all the directives, digests, factories, services, scopes, dependency injentions, all the ng-* tags and so on. That is a lot of terminology for something that is supposed to make developing web appliclations easy.

Granted I am not a Web UI developer was just curious what everything was excited about.

Maybe all this complexity just makes sense to someone who already did all the more complex stuff wiht jQuery? Not sure.

Anyway React made sense to me. The whole data flow ideas, minizing mutable state and inter-dependencies between components, VDOM and even JSX.

So I like React a lot better.

Re: Angular 2 Core

#206
post #66

Earlier quoted context omitted.

Not to mention, it's much simpler than Angular. You can get upto speed with React in 2 or 3 days. Once you make the shift to specifying single states for your interactions and letting React rebuild the DOM on changes, you'll never go back to anything else.

I disagree (about never going back) - I spent some time playing around with React (I authored https://github.com/wesleycho/angular-react ), and I found the lack of a framework for application development to be a massive void. Code organization and modularity is becoming an increasingly important problem with JS as more logic is happening in the client and more components need to be modular for fast changing requireme…

> HTML mixed in with JS via JSX is also an abomination,

Ha! It made sense to me. It was very easy to explain its purpose and it is entirely optional.

Re: Angular 2 Core

#207
post #191

Earlier quoted context omitted.

I have to agree. Will there be backwards compatibility? If not, upgrading to angular 2 is going to require so much work and we'll probably end up switching frameworks. This could end up like Python 2 & 3.

It is not an upgrade if your old stuffs stop working. Man, 1.0 used to mean something.

Really? Well when it came to programs, one used to expect that older versions of the files used with that program would themselves be upgraded, or would just work. However, when it comes to languages, the major version number is used to indicate breaking changes.

So where does angular lie on that continuum?

Re: Angular 2 Core

#208

I'm quite disappointed by this presentation, I see only new syntax everywhere for approximately zero benefit. There is not even any mention to the Object.observe integration which would be the most exiting feature to improve Angular apps. Angular looks and feels now like a Java framework, with ugly decorators and bloated APIs, that's really sad...

Came here to say this. In the last slide, when they were piling "RIP Directives", "RIP DI", "RIP Modules", etc., the only thing I had in mind was "RIP Angular". Very disappointing.

Really? Because I found angular to be highly convoluted in practice (and I have implemented it in practice).

Most of my team eventually settled on the conclusion that "the cognitive load of working through the implications of how these nested directives play out in an application is simply not worth it". Or something to that effect.

We all studied angular studiously, we all did our best to implement it in an effective and sound manner, and when things went wrong, and they always go wrong, the shear complexity of the framework tied our hands and forced us to do some very ugly hacks.

I look at our application as it stands, and I regret using angular.

If angular 2 is simplifying it's framework, the only thing I have to say to that is "Thank god, maybe I'll try it again"

Re: Angular 2 Core

#209
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…

React is just newer. Give it some time.

Those that can't evaluate the technology for what it is have to find other proxies. Number of forks. Number of meetups per year. Blog posts. What color shoes does the creators wars. Etc.

I think once proponets start to point to all these other things and not to nherent benefits or advantages of the technologies, they have already lost me.

Re: Angular 2 Core

#210
post #54

Earlier quoted context omitted.

Indeed. If number of contributors is the only metric that counts then, since React has more contributors than jQuery, I guess that means we shouldn't bet on jQuery. Nobody's gonna be using that fly-by-night project in a year!

That's why I wrote "for reference". jQuery, of course, is a different kind of library. A proper argument would be: jQuery has about three times the contributors that mootools has. If I had to decide between mootools and jQuery, I'd pick the second because of that metric alone, yes. (And this is how the market ended up playing out.) Angular (born Jan 2010) has 2.5 times the number of contributors of ember (born Apr 20…

Pro-tip: Instead of pointing to forks and contributors, and complicated metrics, you'd do better advocating for Angular on this site if you instead point to benefits of the technology itself.

We are big boys and girls here we can take the technical details. No need to use all these external proxies.

Post reply on HN