Why Learning Angular 2 Was Excruciating • Hacker News Board

Re: Why Learning Angular 2 Was Excruciating

#61

Post by svachalek » Mon, Sep 19, 2016, 9:21 PM UTC

dragonwriter wrote: post #44

lolc wrote: post #37

Earlier quoted context omitted.

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.

> Maybe I'm old-fashioned but if you're still planning on changing the API, don't call it a release candidate. If you are planning on changing anything it shouldn't be a release candidate . OTOH, the reason for the "candidate" part of "release candidate" is that things may still change from the plan.

"Things that may still change" is generally expected to be bug fixes.

"RC" is not an excuse to flush semver down the toilet. If somewhere in the RC process you realize "this is never gonna work", you call off the 2.0 release ASAP and start working on 2.1 or 3.0 as appropriate.

Re: Why Learning Angular 2 Was Excruciating

#62

Post by olavgg » Mon, Sep 19, 2016, 9:21 PM UTC

dragonwriter wrote: post #40

olavgg wrote: post #34

Earlier quoted context omitted.

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…

No no and no. Breaking changes are not ok, not even slightly!

It's not acceptable after an alpha release, It's especially not acceptable after a beta release. And it is offensive against developers to have breaking changes from the first release candidate and onwards.

Even for major releases, breaking changes is a VERY BAD thing. But sometimes it is unfortunately unavoidable.

Re: Why Learning Angular 2 Was Excruciating

#63

Post by Nemcue » Mon, Sep 19, 2016, 9:21 PM UTC

codelike wrote: post #47

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

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

Re: Why Learning Angular 2 Was Excruciating

#64

Post by [deleted] » Mon, Sep 19, 2016, 9:22 PM UTC

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?

[deleted]

Re: Why Learning Angular 2 Was Excruciating

#65

Post by alexbecker » Mon, Sep 19, 2016, 9:22 PM UTC

brentvatne wrote: post #35

nichochar wrote: post #28

Earlier quoted context omitted.

"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

I believe they are complaining about the ~150kb minified filesize, rather than the API surface area.

Re: Why Learning Angular 2 Was Excruciating

#66

Post by peferron » Mon, Sep 19, 2016, 9:23 PM UTC

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

Is the comparison fair? I haven't tried Angular 2, but it seems much more full-featured than React. For example, I guess that Angular 2 includes a router, while React doesn't, and just a few days ago there was a vitriolic thread just here on HN about the state of react-router.

If you look at react-redux-starter-kit [1], I would absolutely not say that it's simple. This file [2] is only 12 lines of code but can you call it simple? I don't think so.

[1] https://github.com/davezuko/react-redux-starter-kit

[2] https://github.com/davezuko/react-redux-starter-kit/blob/mas...

Re: Why Learning Angular 2 Was Excruciating

#67

Post by plexicle » Mon, Sep 19, 2016, 9:23 PM UTC

WalterSear wrote: post #25

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?

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/

I don't think the idea of "planned" breaking changes every 6 months to be such a bad thing. A major release twice a year that you can upgrade to when you're good and ready.

Sounds like a way to prevent having to completely rewrite from the ground-up to keep up with the web a la angularjs.

I like React because it's a lot smaller but I totally see the advantages of Angular 2 and I kinda dig the major release cycle.

Re: Why Learning Angular 2 Was Excruciating

#68

Post by ajmurmann » Mon, Sep 19, 2016, 9:24 PM UTC

dragonwriter wrote: post #40

olavgg wrote: post #34

Earlier quoted context omitted.

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…

It's ok if the first RC had breaking changes but after that you should have only bug fixes between RC versions. It seems unusual that some breaking feature got for some reason left out from an earlier build that was considered a potential candidate for release.

Re: Why Learning Angular 2 Was Excruciating

#69

Post by stupidcar » Mon, Sep 19, 2016, 9:24 PM UTC

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

Tell me about it! Literally all you need is React.

Oh, plus react-router for routing, I guess. And Redux, obviously. Plus react-router-redux to link them together, and react-router-scroll for scroll history. Also react-intl to handle internationalisation. And react-helmet to do document header stuff. You'll need to use immutable as well, obviously, so you'll need redux-immutable. And redux-saga. Hmm, you'll definitely need a selector library like reselect. Better throw in reactcss too. Gotta get them inline styles going!

Anyway, just those and a couple dozen other libraries and you're good to go. Then once you've set up Flow types, Babel compilation, isomorphism, bundling with hot module reloading in Webpack, linting and testing, you've got a rockin' React app. Easy as that!

Re: Why Learning Angular 2 Was Excruciating

#70

Post by dragonwriter » Mon, Sep 19, 2016, 9:24 PM UTC

svachalek wrote: post #61

dragonwriter wrote: post #44

Earlier quoted context omitted.

> Maybe I'm old-fashioned but if you're still planning on changing the API, don't call it a release candidate. If you are planning on changing anything it shouldn't be a release candidate . OTOH, the reason for the "candidate" part of "release candidate" is that things may still change from the plan.

"Things that may still change" is generally expected to be bug fixes. "RC" is not an excuse to flush semver down the toilet. If somewhere in the RC process you realize "this is never gonna work", you call off the 2.0 release ASAP and start working on 2.1 or 3.0 as appropriate.

> "RC" is not an excuse to flush semver down the toilet.

That's true. Then again, an RC in semver is a prerelease version and "A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version." (SemVer 2.0.0, para. 9)

Breaking changes from an RC isn't flushing semver down the toilet, its fairly explicitly permitted in the semver spec.

> If somewhere in the RC process you realize "this is never gonna work", you call off the 2.0 release ASAP and start working on 2.1 or 3.0 as appropriate.

No, if anywhere before the 2.0 release, including in any prerelease version in the 2.0 line (even an RC) you discover the need for a breaking change, that's fine per SemVer, and the major release that comes out of resolving those issues will still be 2.0.