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

171–180 of 279 posts

Re: Angular 2 Core

#171

Post by vanadium »

vayarajesh wrote: post #93

It took a lot of time for me to get the hang of AngularJS 1.x and now AngularJS 2 seems very promising but shifting along with the new syntax, programming logic is really painful.. They should provide a path to easily shift programmers thinking from 1.x to 2 (hopefully it is already in their roadmap)

IIRC, in the larger Google Doc cache of their Core documentation for Angular 2.x, they've stated in the manifesto of sorts that, well, that "easy shift" may just not be possible. Primarily when it comes to migrating existing applications.

Re: Angular 2 Core

#172

Post by purpletoned »

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.

I think there's a page or two that describes what the jsx transformer does(which is it converts them to React.DOM elements IIRC). I think that's where I learnt that you could use raw JS functions instead of jsx, even though it said that jsx should be preferred or something to that effect.

Re: Angular 2 Core

#173

Post by rantanplan »

malandrew wrote: post #169
rantanplan wrote: post #160

Earlier quoted context omitted.

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

Take a deep breath and relax.

First of all I stupidly thought that the part about KDE/GTK which is in this comment of mine https://news.ycombinator.com/item?id=8508094, was included in the comment to which you replied. So my bad and -1 for me.

What I meant is I don't think that anyone sees Qt or GTK as monolithic systems and they are about 1000 times more complex than any JS library you could name, as they solve a myriad problems to which JS is oblivious and wouldn't be able to solve anyway.

Contrast that with the web situation today, where they can't even decide which is the view, which the controller or "hey, maybe these don't map very well on the web side of things". Yes I agree about Tim Berners-Lee and the http stuff. But at some point things have to converge into something coherent, because the problem we have to solve is quite elementary, compared to other technologies.

Also if you honestly believe that people who developed KDE and people who develop with AngularJS are performing the same type of work... it just betrays the fact that you're just a JS programmer and haven't seen some real engineering work.

Javascript touches the tip of the iceberg with regards to technical challenge and Software Engineering, so please... just take a breath :)

Re: Angular 2 Core

#174

Post by zghst »

swalsh wrote: post #129
dodyg wrote: post #84

Earlier quoted context omitted.

It's not about you, the developers. You can easily move on and jump from frameworks to frameworks. Your clients or employers suddenly have to worry about one extra thing because their newly developed applications/systems suddenly become 'out of date' simply because the crazy churn in on JavaScript frameworks API. It is not a good thing. We are invalidating people's investments, time and money for no good reason.

Honestly, that's why you don't develop a new production system in a framework that's just a few years old. I had a coworker suggest using Angular on our main product that pays our bills. My reply was, it looks great... i'm excited about it, but I think we should use it on less critical systems until it matures. There's too many unknowns. There's no reason every new platform you develop needs to be using literally the…

Too many unknowns is way too broad of a reason when it comes to JS. JS is already the language of unknowns. It really depends on the framework, timing of things, people behind it. Angular is by Google, but also Google is pushing Web Components at the same time, which can integrate with Angular 2, but it challenges it as well. Also with Angular 2's goals being known for a long time, anyone could tell that ES6 would be a dramatic wave of change to the framework.

With JS, all the frameworks and libraries out there are just a few years old. Angular is about 5 years old, but Google doesn't even use Angular in their sites, which should be extremely telling (along with the complexity learning and figuring out the API). In fact I think Google isn't even planning on Angular on any Google sites in the future. They are waiting until Web Components are finalized.

With React, it is apparently mature enough, it is used on Facebook (1 billion users), Instagram (a child company of Facebook, like Youtube for Google), Khan Academy, Github (github issue viewer), AirBnB, CloudFlare, and a lot more:

https://github.com/facebook/react/wiki/Sites-Using-React

In the JS world, there's a lot of reason to keep moving forward with tech. Sure it doesn't have to be the latest and greatest, but since JS is such a "poor" language, a lot of these newer tools, features, framework, and libraries help build more professional, quality code. Shying away from newer tech (again not the latest and greatest, but away from tech that improves quality of code) highlights obstinance and ignorance about the technology behind it, as well as how little someone understands the industry today.

Re: Angular 2 Core

#175

Post by pjmlp »

zak_mc_kracken wrote: post #98

Even though this is still called "Angular", this new version has barely any resemblance with the previous one, it's really a totally new framework. It's a bit sad to think that all this knowledge I have of Angular 1 is now obsolete but I'm excited to dive into this new framework. If it's half revolutionary as Angular 1 was, it's going to be a pretty interesting time.

Yes, I think I will keep the reference to the slides for the case when people state Microsoft is the only company changing their mind about libraries.

Re: Angular 2 Core

#176

Post by spion »

zghst wrote: post #152
realusername wrote: post #47

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

Ever since reading Angular 2's goals, I put 2 and 2 together, the API was definitely going to have to change massively to accommodate ES6. I'm sure they're using Object.observe it just wasn't mentioned in the presentation.

This is not even ES6, its some weird abomination (AtScript) on top of ES6.

We definitely wont be switching to Angular 2.0. Hello React.

Re: Angular 2 Core

#177

Post by zghst »

spion wrote: post #176
zghst wrote: post #152

Earlier quoted context omitted.

Ever since reading Angular 2's goals, I put 2 and 2 together, the API was definitely going to have to change massively to accommodate ES6. I'm sure they're using Object.observe it just wasn't mentioned in the presentation.

This is not even ES6, its some weird abomination (AtScript) on top of ES6. We definitely wont be switching to Angular 2.0. Hello React.

While terribly written and in poor format, it has some semblance to ES6.

Re: Angular 2 Core

#178

Post by spion »

Bahamut wrote: post #66
purpletoned wrote: post #20

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"

Why?

Re: Angular 2 Core

#179

Post by spion »

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

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

The question is whether those concerns need separating. I've come to believe that the price to pay for that "separation" is too big and ends up being a re-implementation of shared scope (see angular's $scope)

Re: Angular 2 Core

#180

Post by Bahamut »

joeevans1000 wrote: post #165

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.

I think the biggest win would be to start using ES6 and getting used to using the import/export syntax.
Post reply on HN