

Ask HN: When learning a new framework, should I try to understand everything? - J-dawg

I&#x27;ve recently been learning AngularJS. The framework makes it easy to get a lot of stuff done fast, but I&#x27;m finding it very challenging to understand what&#x27;s going on under the hood.<p>I feel like I&#x27;m in danger of becoming a cargo cultist, copying and pasting boilerplate code because &quot;that&#x27;s the way it&#x27;s done&quot;, not because I really understand it.<p>Am I being too hard on myself? I guess a balance has to be struck between productivity and understanding, I&#x27;m just not sure where that line should be drawn.<p>What works for you? Is it better to dive in and finish a project, even if it&#x27;s cobbled together from StackOverflow snippets and code borrowed from tutorials? Or should I take it as I sign that I&#x27;m out of my depth and study the underlying JavaScript until I understand it?
======
lollipop25
> Am I being too hard on myself?

Yes

> What works for you? Is it better to dive in and finish a project, even if
> it's cobbled together from StackOverflow snippets and code borrowed from
> tutorials? Or should I take it as I sign that I'm out of my depth and study
> the underlying JavaScript until I understand it?

No and No

\---

The purpose of a framework is to abstract the nuts and bolts of MVC into...
MVC (or whatever pattern Angular uses). All you need to know are assumptions
on how it works, and not drill down to the if statement that caused this code
to run.

For instance, to get myself acquainted with Angular (I had prior experience
with Ember and Backbone), I needed to know how it was the same and different
from the approaches I already know:

\- How the rendering cycle works (when data is set, when it gets rendered).
All you need to know about it is what runs when.

\- How Promises work, because most of Angular is Promise-based (resources,
$http methods). All you need to know is when they're resolved and rejected,
not how they work internally.

\- How dependency injection works. Angular does some weird static analysis
under the hood, and _doesn 't inject the dependency or run code if not being
used_. You don't need to know the logic of how it resolves them, just use
them.

\- How to structure code properly and write it elegantly (because directives
are not all that elegant to build). This is based on personal preference.
Learn from terribly copy-pasted code.

Everything else in Angular is plain JS and generic programming concepts (event
emitters, watchers, inheritance) which you can learn but need not pry open the
machine to understand.

------
akbar501
1\. I don't think you have to understand everything. However, you should
understand the parts that you use.

2\. I find it critical to be able to rationalize about what the language,
compiler/runtime and framework should be doing. This is never learned up
front, but do take time periodically to understand what should be happening.
For example, take 2 weeks to re-read JS the Good Parts. As you read, apply
what you're learning to your code.

3\. "the ways it's done". IME, "the way it's done" is too often "the way one
engineer blogged about it and then 1,000 engineers reblogged without actually
understanding why". Just because a solution is repeated over and over, does
not mean its the right one for your situation.

4\. the balance between understanding and productivity. Long term, the more
you understand, the more productive you'll be. However, there is a time
investment in the short run. Just balance the two based on your immediate
needs. As for understanding, set a schedule of 30 minutes per night where you
read. You won't learn everything at once, but it will happen over time.

5\. Study JavaScript the language. JS, due to its async nature, is very
different. Getting to know the language will make the Angular and/or any
future frameworks you use a lot easier to think about.

------
philipov
If you want to understand everything, you first have to understand one thing.
To start using a framework, learn the Table of Contents to its documentation.
As you go about accomplishing objectives, pick features that look interesting
and read the documentation for them.

If you do that while cobbling the project together with code snippets from
StackOverflow, you'll end up understanding them when you optimize their
implementation for your use case.

------
bikamonki
Do you understand everything about your OS? Your browser? Your user's
browsers? Networking? Security?

The short answer is no, frameworks are yet another level of abstraction where
some assumptions are made and [ideally] are well implemented/tested.

My long answer would be: try to understand how it works, what are it's
assumptions and what does it do differently/similarly to other frameworks; but
do not try to understand down to the code, unless you spot and dig for a bug
or are interested in collaborate with its development.

------
PaulHoule
Both book learning and learning by doing have a place.

When I am learning something challenging I load a lot of PDF documentation on
my tablet and read it while I do cardio at the gym. I expect to read the docs
cover to cover five times or so.

While I am doing this I am also learning by doing, but the book aspect means I
get to understand what is going on.

