Live data from Hacker News

Why Learning Angular 2 Was Excruciating

hackernoon.com

51–60 of 226 posts

Re: Why Learning Angular 2 Was Excruciating

#51
post #4

I never used Angular 2, but that sounds like the biggest issue is a release candidate that should have been called a beta or alpha release. I sometimes tend to try out beta releases when learning something new and interesting, but that does tend to backfire now and then when it's unstable enough that I can't tell if I'm doing something wrong, the framework is buggy or the documentation is simply outdated.

In general, if I understand correctly, "Release candidate" implies "unstable." The emphasis is on "Candidate," not "Release," i.e. "This bundle could end up being the final version, but it probably won't. "

RC absolutely means non-breaking API changes. Bug fixes yes, but the API will be stable.

Re: Why Learning Angular 2 Was Excruciating

#52
post #4

I never used Angular 2, but that sounds like the biggest issue is a release candidate that should have been called a beta or alpha release. I sometimes tend to try out beta releases when learning something new and interesting, but that does tend to backfire now and then when it's unstable enough that I can't tell if I'm doing something wrong, the framework is buggy or the documentation is simply outdated.

Release candidate to me means "We think this software is pretty much done. Does anybody in the community think otherwise?". You don't expect new features or breaking changes. That wasn't what happened during angular2 development.

I started a project at around RC4. It's my own fault to some extent for doing that and not waiting or using angular1.

I found that most of the core functionality like component annotations, ngInit, template syntax didn't change - although I wasnt trying to use the router or forms modules which did experience large changes over the 6 months.

For me most of the pain was in keeping up with changes in the boilerplate stuff in the root of the app like main.ts, modules and and the same keeping up with recent big changes in angular-cli.

Re: Why Learning Angular 2 Was Excruciating

#53
post #18

TL;DR - developer learns the meaning of Release Candidate or rather...does not: "To be fair, I have been using versions of the library that have thus far not been officially released. Maybe, you say, it’s my fault for trying to download and use a version of the library that is still in alpha/beta/release candidate and expecting it to work and be relatively easy to use. Perhaps you are right. But, considering the fact…

You do so in a derogatory manner, but you bring up a decent point. This doesn't really seem to be a JavaScript issue so much as an open source issue.

Using libraries in Perl and Python, they are generally a lot more finished that JavaScript in my experience.

Re: Why Learning Angular 2 Was Excruciating

#54

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…

This reminds me of the excellent episode of Changelog in which Facebook's head of open source discussed the logistics of managing React so that the public version is exactly the same as the version used by Facebook itself: https://changelog.com/211/

Really drove home the concept that open-source requires significant thinking and discipline when a library becomes heavily used.

Re: Why Learning Angular 2 Was Excruciating

#55
post #4

I never used Angular 2, but that sounds like the biggest issue is a release candidate that should have been called a beta or alpha release. I sometimes tend to try out beta releases when learning something new and interesting, but that does tend to backfire now and then when it's unstable enough that I can't tell if I'm doing something wrong, the framework is buggy or the documentation is simply outdated.

In general, if I understand correctly, "Release candidate" implies "unstable." The emphasis is on "Candidate," not "Release," i.e. "This bundle could end up being the final version, but it probably won't. "

"Release candidate" != "Release" but in my understanding "RC" is "almost finished, but we might have some bugs to fix before"

Anyway my personal attitude is to keep away from alphas, betas, RCs and stable-from-yesterday. Applies to frameworks, operating systems and virtually everything, and each time I don't follow that rule, I regret.

Re: Why Learning Angular 2 Was Excruciating

#56

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.
Is this actually true? My understanding (from watching many AngularJS presentations) is that Angular was developed with input from many teams at Google.

(edit: Angular was first used on an internal app at Googel: https://www.youtube.com/watch?v=r1A1VR0ibIQ&feature=youtu.be...)

Re: Why Learning Angular 2 Was Excruciating

#57

To me this is still why React feels like the first front end UI framework that got it "right." It stays close to vanilla Javascript. There's a tiny API surface area to learn, and the rest is vanilla Javascript classes and functions. Angular's API, and apparently Angular 2.0's API, is still large, and strays far from vanilla Javascript

I still firmly believe Angular 1 got the right pieces into the framework (directives and services), but that the community latched onto some of the extraneous pieces (controllers, controllerAs, etc), which don't offer enough cost/benefit and simply make things much harder to grok. You often end up babying references and being bitten by implementation details of JS and somewhat-confusing names for things (e.g. $scope does not behave like the variable scope of any ES version).

Angular 1 still beats the pants off of everything else in my experience, if you know how to trim the fat. I'd very much like to write more about my approach in the near future.

Re: Why Learning Angular 2 Was Excruciating

#58

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?

[deleted]

Re: Why Learning Angular 2 Was Excruciating

#59

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?

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's sheer insanity to make breaking changes or upgrade the dependencies between a release candidate and a final version. The upgrade from a release candidate to a final version should be the easiest upgrade in the world.

Re: Why Learning Angular 2 Was Excruciating

#60

Earlier quoted context omitted.

In general, if I understand correctly, "Release candidate" implies "unstable." The emphasis is on "Candidate," not "Release," i.e. "This bundle could end up being the final version, but it probably won't. "

RC absolutely means non-breaking API changes. Bug fixes yes, but the API will be stable.

It does not "absolutely" mean that.

It certainly means API changes are not anticipated, and that there should be a very significant problem with an API to lead to an API change at that point; certainly one would hope that fundamental flaws in an API that make it unsuitable for release would be identified well before an RC.

But its certainly possible to have reasons to make a breaking change from an RC (e.g. -- not necessarily relevant to a front-end framework, obviously -- a security vulnerability uncovered that reveals a critical flaw in the logical design, rather than implementation, of an API.)

Post reply on HN