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

Why Learning Angular 2 Was Excruciating

hackernoon.com

Post reply on HN
Print view View original

91–100 of 226 posts

Re: Why Learning Angular 2 Was Excruciating

#91

Post by stupidcar »

mooseburger wrote: post #84
plexicle wrote: post #17

Your first foray into web development and you picked a large, unfinished (it wasn't final) framework to learn with? Then you are complaining that there were breaking changes you had to deal with? I get your beef with the ecosystem, but this is a very unfair knock on Angular 2. Angular 2 was not the problem here at all. Am I missing something obvious?

I did the Angular 2 TypeScript quickstart this weekend, and it bothers me that it relies heavily on Decorators, which are an experimental feature in TS ( https://www.typescriptlang.org/docs/handbook/decorators.html ). I also recall there being around 30 issues for Angular 2 Final on github milestones the day they announced the release, but they were mysteriously gone in the afternoon. Angular 2 Final seems to be anyt…

It was the TypeScript team that invited the Angular team to build Angular 2 on top of TS (at the time, they were planning their own JS dialect called AtScript), so I would be surprised if they later changed in a way that seriously broke compatibility with Angular 2.

Re: Why Learning Angular 2 Was Excruciating

#92

Post by meredydd »

lemmsjid wrote: post #6

I've found that learning new technologies from first principles is better than starting with frameworks, unless you're willing to put up with a lot of ambiguity. For example with Javascript I'd start with basic manipulations (e.g. get to know the prototype model, the debuggers, the DOM, etc.), work up to a make-life-easier library like JQuery, then try a framework. It may depend on your learning style, of course.

This is fundamentally because every Javascript tool is an incredibly leaky abstraction.

The problem isn't so much that "raw" Javascript has a lot of problems; it's that every solution requires you to fully understand the problem and the architecture of the solution.

Promises ease the pain of async in JS, but you've got to understand async well enough to implement Promises yourself in order to accurately predict their behaviour.

JQuery eases the pain of the DOM, but you've got to understand how the DOM (and events) work to use it properly.

Angular eases the pain of structuring large applications, but you've got to understand...everything...before you can use it properly. And also jQuery. And also the DOM. And also a build tool to manage the heap of complexity you've just bought.

This sort of thing does occurs in other ecosystems: for example, I love Clojure, but you're going to have a bad time with it if you don't grok how Java works. But the JS ecosystem is absolutely teeming with it - often nested several layers deep!

The JS community seem to have Stockholm syndrome about this. In other contexts it is just not normal to have to operate simultaneously at all levels of the abstraction hierarchy, at all times. Joel Spolsky wrote his famous "leaky abstractions" essay because it was not immediately obvious that when (eg) using a TCP connection, you'll eventually want to know about how IP works. If TCP/IP had been written in the modern JS ecosystem, you'd need to have a working knowledge of ICMP packet types before you finished debugging "Hello, World" in TCP v2.0.1-rc4(deprecated).

Re: Why Learning Angular 2 Was Excruciating

#93

Post by jbigelow76 »

jkkramer wrote: post #36

It's interesting to contrast how Google and Facebook both approach open source for the web. Google tends to release code and promote it without really using it much internally first. Documentation is prolific but confusingly organized and often fragmented among several versions simultaneously (cough, Google Analytics). Facebook, on the other hand, actually seems to use their code before releasing and promoting it. Lo…

Google tends to release code and promote it without really using it much internally first.

According to Brad Green, the Engineering Director over Angular, Google AdWords, Google Fiber, and some internal tools are all built with NG2. AdWords is kind of big deal to Google.

Edit: source for AdWords reference, http://angularjs.blogspot.com/2015/11/how-google-uses-angula...

Re: Why Learning Angular 2 Was Excruciating

#95

Post by shriek »

Nemcue wrote: post #63
codelike wrote: post #47

Earlier quoted context omitted.

That's one of the pros often mentioned about React. In practice, I haven't found it to be true so far. Once you start using React, you'll almost certainly have to use one the Flux implementations. So let's say you use Redux. Suddenly you also have Actions, Reducers and Stores that you have to learn. If you want to use Async Actions (which is very likely in a web application), you'll probably need Redux Thunk, so that…

The difference is that you're spending time learning about concepts that you are unfamiliar with, as opposed to learning Angulars many APIs. For instance if you've already spent time learning about Redux you'll have a very easy time re-using those in Angular 2 (with ngrx).

Absolutely this. While it might be tedious to put those pieces together at first the knowledge that you gain is very transferable to the other app that you build instead of being one-trick pony in angular.

Re: Why Learning Angular 2 Was Excruciating

#96

Post by WalterSear »

RKoutnik wrote: post #82
WalterSear wrote: post #25

Earlier quoted context omitted.

Unfinished? How about never finished. >Angular 2 is going to have breaking changes only every 6 months from now on. So the next one would be around February with Angular 3. Yes exactly, they’re also finally switching to semantic versioning which is a huge win in my opinion. IMHO, breaking changes every six months is the recipe for an shitshow of an ecosystem. http://juristr.com/blog/2016/09/ng2-released/

One other project comes to mind that also updates every six months: Ubuntu. Last I checked, their ecosystem was doing fairly well. I wouldn't consider Ubuntu "unfinished" unless we're talking about the state of all software everywhere.

Does Ubuntu ship breaking changes every six months? Do Ubuntu developers rely on other developers to keep their shared code updated and/or fork their repositories to support both new and old versions of the framework, every six months?

Re: Why Learning Angular 2 Was Excruciating

#98

Post by oldmanjay »

janfoeh wrote: post #76

I've said it before here and I'll say it again: the JS ecosystem is moving in the wrong direction. Sometimes I feel that with Javascript, we developers have taken something that wasn't ours, and we're in the process of destroying the best thing there ever was about it. One of its best qualities used to be that you could have absolutely no idea what you're doing, read a few bad tutorials somewhere on the web, mash you…

If it were impossible to trivially build low-function websites, you'd have more impact with your point. As it stands, it comes off more like union guys complaining that hardworking people make them look bad.

Re: Why Learning Angular 2 Was Excruciating

#100

Post by Udik »

plexicle wrote: post #74
OskarS wrote: post #59

Earlier quoted context omitted.

He didn't pick up a pre-alpha nightly build of the framework, he used the release candidate for christ's sake. A release candidate is a "release candidate", that is to say "we're pretty sure we could release this whole thing right now, but we want to send it out to the community to make sure there are no catastrophic bugs we haven't noticed". In other words feature-complete, and with most of the kinks ironed out. It'…

RCs should IDEALLY not have breaking changes. You can dice it up any way you want, but it wasn't a final build and there were obviously some rough edges. Angular 2 is final now and they've committed to no more breaking changes until the next major build (at least 6 months away). If s/he started learning with it today, then ~90% of what s/he was complaining about in this post wouldn't have been a thing. That was my on…

Not that I find the debate particularly productive, but "there will be no breaking changes" doesn't mean "final", it usually means (at most) release candidate. Or even beta. While "it works but we might still introduce breaking changes" is not a release candidate but maybe a technology preview.
Post reply on HN