Live data from Hacker News

Why Learning Angular 2 Was Excruciating

hackernoon.com

111–120 of 226 posts

Re: Why Learning Angular 2 Was Excruciating

#111

Earlier quoted context omitted.

Except for the tons of counterexamples at Google... Bazel, Tensorflow, protobufs, GWT (a web/JavaScript project!), dozens of utility libraries, etc. You are forgetting that Google is a huge company, much bigger than Facebook. It's more a collection of disparate entities than a monolithic giant. Each open source project is run differently.

It's my experience with their web-oriented and JavaScript projects. They definitely put out lots of high quality open source work in other domains.

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.

Re: Why Learning Angular 2 Was Excruciating

#112

Earlier quoted context omitted.

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 definite…

I think OP has made a mistake calling it a framework as it is not a framework, it is a library. People have added more libraries to it. On the contrary, yes Angular is a bonafide kitchen sink framework missing the major advantage of a framework: A STABLE somewhat opinionated stack. You are correct though that making React into a "framework" is a hot mess.

While React is certainly more lightweight in many respects that something like Angular or Ember, I still think it qualifies as a framework.

For me, the primary difference between a library and a framework is the the typical direction of instantiation and calls between your own code and that of the library/framework, and the ownership of the main workflow / event loop. E.g. does it feel like your code uses the 3rd party code, or that the 3rd party code uses yours?

Putting it more concretely, when you code is executed, does the 3rd party code tend to come after it in the stack, or before it?

With a library, you're mostly calling its methods. So, a library is something like jQuery, where you're just making a lot of calls to its methods. Those libraries might do some very complicated things, but they're still just operations that you have launched, and which eventually return control to your code.

With a framework, you're inheriting from framework classes, and conforming to a workflow that the framework controls. For me, that describes React. You write in its JS dialect (jsx), your classes inherit from React.Component, and you hand over control of the rendering workflow to ReactDOM.Render and the virtual DOM.

Re: Why Learning Angular 2 Was Excruciating

#113

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 definite…

I know you're using webpack but you could really add gulp to manage webpack and then manage gulp with grunt and then manage grunt with npm.

I mean why use one package manager/module loader when you can use 4?

Re: Why Learning Angular 2 Was Excruciating

#114

I've pretty much had the same experience with the JavaScript back end. The npm ecosystem is overwhelming, on several fronts. In many ways, it's great: 70,000+ libraries available with one command. But, my gods...grokking how they all interact, getting a stack of several libraries to work together, and rolling that stack into production, are astronomically more complicated than any other language/platform I've ever us…

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, but the very core framework has changed a lot... so in the Javascript frontend, things are much further away from a "battle-tested best practices" than the backend.

Re: Why Learning Angular 2 Was Excruciating

#115
post #24

Earlier quoted context omitted.

The point is to use the blog as an example to learn the tech, typically. Picking a familiar, not-too-big problem to solve is a good way to understand how new tech works.

A to-do list would've been a better choice. It's the classic choice for working with SPA frameworks. I thought the same thing as your parent's commenter when I read the word "blog".

To be honest, TodoMVC is the idea-that-needs-to-die™ for SPAs. IMO, if all the framework needs to be able to do is described by TodoMVC, you probably don't need a framework at all. It probably takes way less time to write a todolist in a vanilla language than to learn an entire application framework to build it.

Re: Why Learning Angular 2 Was Excruciating

#116

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

Re: Why Learning Angular 2 Was Excruciating

#117

Earlier quoted context omitted.

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 definite…

Lmao, this is exactly how I've felt, and why I'm using ordinary js with closures and a bit of jquery for the time being while I get up to speed and figure out wtf is going on. "Javascript the good parts" has served me well.

Eh, it really is not that bad. With just React and a fetch polyfil (to replace jquery's ajax) you can get pretty much the same power as with just jquery.

This will all settle down in a year or two, once we get the most basic features built-in into browsers. Like for example modules + HTTP2 will probably mean no more bundlers or build tools (which is where the vast majority of this craziness is coming from)

Re: Why Learning Angular 2 Was Excruciating

#118
I think as you yourself have said, it's the pain that comes with using something that's currently in alpha/beta/etc. True, Google's approach is different, but the end product is something that has gotten so much input from the wider community, as apposed to how FB does it. Now I'm not saying one is better than the other. I'm just saying it's the price for depending and using some thing thats still literally being worked on. As far as I know, thats pretty much a wavier on ease of use.

As far as your other conclusions around how this sort of problem exists in general in the JS community, I think you are wrong :) That's like me saying the Java community is chaotic because I experienced problems installing Java.

Unfortunatly, I think you may have bitten off more than you can chew with jumping in to web development with an in-progress framework which is also using completely new build/development workflow. But I guess the rewards are worth it since you really are at the bleeding edge :)

Re: Why Learning Angular 2 Was Excruciating

#119

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/

Rails introduces some breaking changes now and then. The only troublesome upgrade was when they added the asset pipeline. Was that 3.0 or 3.2? If Angular is adding some features while deprecating others it won't be a big problem. If they break compatibility in a big way every six months, maybe it's not the place to be. High maintenance costs means that it's hard to sell to customers and even for internal projects one should evaluate if it's wise to allocate resources on rewriting the same code again and again. We'll see.

Re: Why Learning Angular 2 Was Excruciating

#120
post #22
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 exactly the path I've taken. I figured if I start out with right off the bat, and not understand the foundation, I'd be screwed in the long run. My reasoning is that once I grasp JS's quirks/ins/outs (I'm looking at you 'this'), well I'd be ready to see the light and better choose a framework. So far, I think ReactJS nailed it, but keep in mind I am fairly new to Web Dev (coming from PC/Console/C++ world) so…

You'll certainly have a hard time if you think you can use any javascript framework without knowing javascript itself. Not understanding how 'this' works is like not understanding how classes work in an oo language, and no framework will ever hide that from you.
Post reply on HN