Live data from Hacker News

Why Learning Angular 2 Was Excruciating

hackernoon.com

181–190 of 226 posts

Re: Why Learning Angular 2 Was Excruciating

#181

Earlier quoted context omitted.

Seems to me OP is stating the exact opposite. That the JS ecosystem used to be more egalitarian with a much lower barrier to entry than (ironically) what frameworks like React and Angular provide.

If the OP is stating that it is possible to trivially create low-function websites then I am befuddled. Why complain that what is wanted is achievable? Or perhaps this is one of those things where people assert that the existence of things they don't want to use is somehow offensive. Still isn't a very helpful point to make.

> Or perhaps this is one of those things where people assert that the existence of things they don't want to use is somehow offensive.

It could be related to the signal-to-noise ratio. If I'm a non-dev looking to throw something together and 98% of the information I find is about some pro-level frameworks, it'll be hard for me to sort through that and find information appropriate to my skill level, level of interest, and needs.

Maybe it's still a net-gain for the world as a whole, but it's certainly a loss for the non-dev. It makes the learning curve (perhaps needlessly, perhaps not) more regressive.

Re: Why Learning Angular 2 Was Excruciating

#182

Earlier quoted context omitted.

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.

This release cycle is fine so long as you don't rely on anything but Angular 2. As soon as you rely on packages that support Angular 2, the 'good and ready' argument breaks, since you can't start till all the packages you rely upon have already made the upgrade, and you can't take to long either, because you can't expect further work or fixes to be made to older versions of the packages. 12-month breaking changes, th…

It sounds odd to me that an app would include packages that have dependencies on a framework. I'm having a hard time picturing an example, can you provide one?

Re: Why Learning Angular 2 Was Excruciating

#183

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/

I'd like to point out that React has had breaking changes roughly 6 or less months apart also. This is a red herring of an argument, we see lots of successful libraries make breaking changes that often doing fine. The scope of the breaking changes matter more, and that story has yet to be told.

> I'd like to point out that React has had breaking changes roughly 6 or less months apart

When? Can you cite an example? Keep in mind that for most breaking changes React typically goes to a deprecation warning for the duration of a major release instead of hard-breaking changes, so in reality you have roughly double the time between truly breaking releases, generally speaking.

Re: Why Learning Angular 2 Was Excruciating

#184

I'm just gonna leave this here: http://aurelia.io/ . Aurelia is truly a professional operation.

I've used both Aurelia and Angular 2. I enjoy Angular 2 very much despite its feistiness and the community around it is huge, but Aurelia just seems cleaner, easier to use and lightweight. If I were to pick one, it would be Aurelia, but I would never suggest someone abandon an established Angular 2 project in favor of Aurelia.

Well I don't think any significantly sized project in any framework can be expected to move to another framework without a major rewrite effort. I wasn't suggesting that. But if you are gonna start with something new then Aurelia is the way to go.

Re: Why Learning Angular 2 Was Excruciating

#185

Earlier quoted context omitted.

This release cycle is fine so long as you don't rely on anything but Angular 2. As soon as you rely on packages that support Angular 2, the 'good and ready' argument breaks, since you can't start till all the packages you rely upon have already made the upgrade, and you can't take to long either, because you can't expect further work or fixes to be made to older versions of the packages. 12-month breaking changes, th…

It sounds odd to me that an app would include packages that have dependencies on a framework. I'm having a hard time picturing an example, can you provide one?

I could have worded it better.

http://ngmodules.org

Re: Why Learning Angular 2 Was Excruciating

#186

Earlier quoted context omitted.

I'd like to point out that React has had breaking changes roughly 6 or less months apart also. This is a red herring of an argument, we see lots of successful libraries make breaking changes that often doing fine. The scope of the breaking changes matter more, and that story has yet to be told.

> I'd like to point out that React has had breaking changes roughly 6 or less months apart When? Can you cite an example? Keep in mind that for most breaking changes React typically goes to a deprecation warning for the duration of a major release instead of hard-breaking changes, so in reality you have roughly double the time between truly breaking releases, generally speaking.

Take a look at the changelog for breaking changes - they even timestamp it.

That is true about the deprecation, although some of the earmarked breaking changes have been quite painful too.

Hopefully the Angular team takes this route for planned breaking changes & apply engineering to ease compatibility.

Re: Why Learning Angular 2 Was Excruciating

#187
post #177

Earlier quoted context omitted.

IMHO the Node/npm ecosystem is far more stable than Angular 1&2/bower. Node core modules have been remarkably stable since 0.12.x, so most of npm packages one would install are libraries, with very narrow responsibilities. A few popular frameworks have also been fairly stable and well understood (Express, Bluebird). With Angular, you also have a myriad of libraries available to you, easily pluggable via Angular DI, b…

> IMHO the Node/npm ecosystem is far more stable than Angular 1&2/bower. I can't say if it's more stable than bower, but IME it's not stable at all. My simple blog static site generator breaks every time I write a new blog post.

What do you mean by breaks?

Re: Why Learning Angular 2 Was Excruciating

#188
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…

I feel the same. I've just straight up stopped using frameworks. I refuse to use ES6 or any module which depends on it. No more coffeescript, no SASS. No promises, no templates.

And really, what all of this boils down to is: avoid declarative control structures at all costs. Procedural design by default. There are a handful of situations where I will build a declarative API, but they are rare. I will use libraries, but only if they have a single well defined purpose and are largely procedural.

The result? It's wonderful. All of my code is completely traceable. If something doesn't work, I never have to go read online for an hour, dig around in the source code for random modules trying to understand boot and build processes well enough that I can form a hypothesis about where a bug is. I just start at whatever point my expectation is violated, and work directly back to whatever is broken.

I can always insert a debugger statement, and instantly stop state either in Node or in the browser. The execution path and data handoffs never disappear into a mysterious framework or executable. The code in production is always in . or ./node_modules.

The entire class of headaches so prevalent in Rails/Ember/every other declarative-is-best system are just gone. Granted, I deal with other headaches. I have to really think about how data moves through the system. I can't just add a flag to access data from one end of the system in a totally different part of my app, because there's no magical framework code using light AI to figure out how to marshal data around based on some declarative configuration conditions.

Essentially what I've decided is it's better to sacrifice convenience in order to get inspectability. You lose speed in your initial hacking, but you gain a predictable pace of debugging. Bugs never really stay mysterious longer than 15 minutes or so. I never have those instances where I spend a whole workday scratching my head about framework internals.

I do spend a day scratching my head about how my data should be structured and how it should flow through the system. But that's effort that will continue to pay dividends. It generally leads to better interfaces that require less maintenance. Work that is often continually put off when you have a framework that offers every shortcut that could be sanely crammed into it.

Re: Why Learning Angular 2 Was Excruciating

#189
post #180

Earlier quoted context omitted.

But you're clicking on a link, not downloading and installing an application.

You are downloading an application, arguably installing one temporarily too. Is this that much more efficient than "apt-get install foo"?

Yes, because it means all my users can install the same application and I only have to write it once for all platforms.

Not every platform/OS even has a (good) package manager. So I think this alone is what makes the web great.

Re: Why Learning Angular 2 Was Excruciating

#190
post #111

Earlier quoted context omitted.

Google does not actually do much with JavaScript. Sure they have gmail, but they put a lot more effort into graceful degradation than most web companies.

Google has larger and more complex JS apps than most other companies on the planet. They do a lot with Javascript besides gmail. Maps, Docs, Photos, G+, are all large Javascript applications. And those are just a few.

These are all separate applications which sit in their own silos. They are individually complicated, but they don't need to fit into some company wide framework.
Post reply on HN