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.
Why Learning Angular 2 Was Excruciating
111–120 of 226 posts
Re: Why Learning Angular 2 Was Excruciating
#112Earlier 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.
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
#113To 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 mean why use one package manager/module loader when you can use 4?
Re: Why Learning Angular 2 Was Excruciating
#114I'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…
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
#115Earlier 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".
Re: Why Learning Angular 2 Was Excruciating
#116Your 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/
The scope of the breaking changes matter more, and that story has yet to be told.
Re: Why Learning Angular 2 Was Excruciating
#117Earlier 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.
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
#118As 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
#119Your 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/
Re: Why Learning Angular 2 Was Excruciating
#120I'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…