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

31–40 of 226 posts

Re: Why Learning Angular 2 Was Excruciating

#31

Post by fixermark »

fabian2k wrote: 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."

Re: Why Learning Angular 2 Was Excruciating

#32

Post by Zyst »

I was reading and stopped half way, it really comes across as disingenuous when you yourself picked an ecosystem that wasn't stable, then the main complaint in the article was about the lack of stability and how the JavaScript ecosystem "Sure is crazy!".

I seriously do not understand what your expectation was.

Re: Why Learning Angular 2 Was Excruciating

#34

Post by olavgg »

JohnnyConatus wrote: post #12

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…

A release candidate is NOT supposed to have breaking changes.... its a friggin "release candidate".

Projects with lot of breaking changes for minor releases should raise red flags, so steer away! Instead of wasting valuable time being bleeding edge, take a deep breath, turn your focus 180 degrees and say to yourself: I think will check it out in 5 years. There are a lot of other great, stable and mature web frameworks out there.

Re: Why Learning Angular 2 Was Excruciating

#35

Post by brentvatne »

nichochar wrote: post #28
stevebmark wrote: post #9

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

"tiny" nope.

import React from 'react'; import ReactDOM from 'react-dom';

function App(props) { return Hello {props.name}; }

ReactDOM.render( , document.getElementById('root') );

Or the alternative component API that has componentWillMount, componentDidMount, componentWillReceiveProps, shouldComponentUpdate, componentDidUpdate, componentWillUnmount, and render.

That's pretty much all there is

Re: Why Learning Angular 2 Was Excruciating

#36

Post by jkkramer »

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. Look at how they handled GraphQL: spec and reference implementation released a year ago, clearly labeled as a "Technology Preview". A lot of design work went into it before that, informed by the problems of internal product teams. Only a few days ago was it promoted as ready for production. The spec hardly changed it the last year. Documentation is good, and they work with the community to improve DX.

Why the difference? Hard to say, but my feeling is that there's a more direct link between Facebook's product-driven open source work and their bottom line. There are other startups constantly nipping at their heels, so they need to be on their game product-wise. Better code -> better products -> profits.

Google is largely impervious in the search and ad space, which is their cash cow. It almost doesn't matter how good or bad their other products are. The company is not at risk. Their open source work reflects that.

Re: Why Learning Angular 2 Was Excruciating

#37

Post by lolc »

JohnnyConatus wrote: post #12

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…

Complaining about API breakage in release candidates is justified. It happens far too often so people are desensitized to it.

Maybe I'm old-fashioned but if you're still planning on changing the API, don't call it a release candidate.

Re: Why Learning Angular 2 Was Excruciating

#38

Post by fixermark »

adrianpike wrote: post #8
lghh wrote: post #5

Earlier quoted context omitted.

That's sort of the problem that the article was addressing. By the time things have been built, they are old news to the JS community - or at least those that you see on HN, Medium, blogs, etc. If you mention learning Angular 1 anywhere you get shouted at that it's old and should not be used and to instead look at Angular 2 and React. By the time those are established, it'll be on to something else. And that isn't ju…

Yep, I've been burned by that many times. Eventually you have to trust in authors' use of semver or other versioning systems, and that _too_ has bitten me poorly. I think a big portion of pain is around the sheer depth of the dependency trees we wind up in npm/js land these days - a trivial little service can wind up with hundreds of disparately maintained dependencies, and you just have to shrinkwrap, hope, and cros…

This wouldn't be a problem if people recognized that every version they release into the wild ends up used by someone, and backwards-breaking changes should be weighted appropriately.

I don't know that we're at that point in the ecosystem yet. Is there a good JavaScript framework that is operated by a team committed to keeping its API stable?

Re: Why Learning Angular 2 Was Excruciating

#39

Post by clifanatic »

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.

Yeah, I thought something similar as I was reading it - I don't think necessarily that the author's problem was in trying to learn Angular, but in trying to learn Angular from the "5-minute quick start guide" that's posted on the web site. That's not realistic, even if you're already an expert in Javascript, jQuery, CSS, HTML, Node.js, npm and even Angular 1!

Re: Why Learning Angular 2 Was Excruciating

#40

Post by dragonwriter »

olavgg wrote: post #34
JohnnyConatus wrote: post #12

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…

A release candidate is NOT supposed to have breaking changes.... its a friggin "release candidate". Projects with lot of breaking changes for minor releases should raise red flags, so steer away! Instead of wasting valuable time being bleeding edge, take a deep breath, turn your focus 180 degrees and say to yourself: I think will check it out in 5 years. There are a lot of other great, stable and mature web framework…

> A release candidate is NOT supposed to have breaking changes....

A release candidate isn't a release, and the release may have breaking changes from the RC, and obviously an RC of anything that would be a semver major release may have breaking changes from the previous actual release. So, in either direction, an RC may have breaking changes.

Ideally, the last RC should not have breaking changes between it and the actual release, but we wouldn't need a "candidate" if we knew things would be ideal.

Post reply on HN