5 ms·

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

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.

kelvin0 10y ago
This is exactly the path I've taken. I figured if I start out with <ShineyNewJSFrameworkMVC> 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 YMMV. Also, I would like to thank the good folks at Twitter for Bootstrap, I don't know how my frontend would look like without it!
- Udik 10y ago
  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.
  - kelvin0 10y ago
    Although what you mention seems obvious, you have to remember that is quite easy nowadays to cobble up some functionality with minimal knowledge by applying ready-made 'recipes' and following the ton of tutorials available in any language/framework (especially as an experienced programmer). The gotchas become painful when you start to dig through without prior knowledge of the nuts and bolts for debugging/profiling/scaling your application. So I completely agree with you, but I've seen many programmers whip up something in a weekend and not be able to extend the functionality of their app because they had no idea how everything fit together in the 'magical framework' of their choice.
- michaelchisari 10y ago
  Personally, I think Mithril.js has done a better job than React of "nailing it" in terms of elegance, but it had the advantage of React bulldozing the path. I'm not new to JS, and React's approach was the first one in years that I found very interesting in a way that didn't feel bloated or over-engineered out of the gate.
copperx 10y ago
I love that approach myself; methodically learning the building blocks is the only way to get solid understanding. However, that's very hard to do if your time is limited and you need to add a feature to an existing app or get something working ASAP. Stumbling through the API is the norm if you're doing something fast. It reminds me of when I was trying to get Photoshop to do something before really sitting down and learning the principles. So much wasted time. In the end, it's always worth it to learn the basics first, but your team will not always agree.
clifanatic 10y ago
Yeah, I thought something similar as I was reading it - I don't think necessarily that the author's problem was in trying to learn Angular, but in trying to learn Angular from the "5-minute quick start guide" that's posted on the web site. That's not realistic, even if you're already an expert in Javascript, jQuery, CSS, HTML, Node.js, npm and even Angular 1!
meredydd 10y ago
This is fundamentally because every Javascript tool is an incredibly leaky abstraction. The problem isn't so much that "raw" Javascript has a lot of problems; it's that every solution requires you to fully understand the problem and the architecture of the solution. Promises ease the pain of async in JS, but you've got to understand async well enough to implement Promises yourself in order to accurately predict their behaviour. JQuery eases the pain of the DOM, but you've got to understand how the DOM (and events) work to use it properly. Angular eases the pain of structuring large applications, but you've got to understand...everything...before you can use it properly. And also jQuery. And also the DOM. And also a build tool to manage the heap of complexity you've just bought. This sort of thing does occurs in other ecosystems: for example, I love Clojure, but you're going to have a bad time with it if you don't grok how Java works. But the JS ecosystem is absolutely teeming with it - often nested several layers deep! The JS community seem to have Stockholm syndrome about this. In other contexts it is just not normal to have to operate simultaneously at all levels of the abstraction hierarchy, at all times. Joel Spolsky wrote his famous "leaky abstractions" essay because it was not immediately obvious that when (eg) using a TCP connection, you'll eventually want to know about how IP works. If TCP/IP had been written in the modern JS ecosystem, you'd need to have a working knowledge of ICMP packet types before you finished debugging "Hello, World" in TCP v2.0.1-rc4(deprecated).

kelvin0 10y ago

This is exactly the path I've taken. I figured if I start out with <ShineyNewJSFrameworkMVC> 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 YMMV. Also, I would like to thank the good folks at Twitter for Bootstrap, I don't know how my frontend would look like without it!

Udik 10y ago
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.
- kelvin0 10y ago
  Although what you mention seems obvious, you have to remember that is quite easy nowadays to cobble up some functionality with minimal knowledge by applying ready-made 'recipes' and following the ton of tutorials available in any language/framework (especially as an experienced programmer). The gotchas become painful when you start to dig through without prior knowledge of the nuts and bolts for debugging/profiling/scaling your application. So I completely agree with you, but I've seen many programmers whip up something in a weekend and not be able to extend the functionality of their app because they had no idea how everything fit together in the 'magical framework' of their choice.
michaelchisari 10y ago
Personally, I think Mithril.js has done a better job than React of "nailing it" in terms of elegance, but it had the advantage of React bulldozing the path. I'm not new to JS, and React's approach was the first one in years that I found very interesting in a way that didn't feel bloated or over-engineered out of the gate.

copperx 10y ago

I love that approach myself; methodically learning the building blocks is the only way to get solid understanding. However, that's very hard to do if your time is limited and you need to add a feature to an existing app or get something working ASAP. Stumbling through the API is the norm if you're doing something fast. It reminds me of when I was trying to get Photoshop to do something before really sitting down and learning the principles. So much wasted time. In the end, it's always worth it to learn the basics first, but your team will not always agree.

clifanatic 10y ago

Yeah, I thought something similar as I was reading it - I don't think necessarily that the author's problem was in trying to learn Angular, but in trying to learn Angular from the "5-minute quick start guide" that's posted on the web site. That's not realistic, even if you're already an expert in Javascript, jQuery, CSS, HTML, Node.js, npm and even Angular 1!

meredydd 10y ago

This is fundamentally because every Javascript tool is an incredibly leaky abstraction. The problem isn't so much that "raw" Javascript has a lot of problems; it's that every solution requires you to fully understand the problem and the architecture of the solution. Promises ease the pain of async in JS, but you've got to understand async well enough to implement Promises yourself in order to accurately predict their behaviour. JQuery eases the pain of the DOM, but you've got to understand how the DOM (and events) work to use it properly. Angular eases the pain of structuring large applications, but you've got to understand...everything...before you can use it properly. And also jQuery. And also the DOM. And also a build tool to manage the heap of complexity you've just bought. This sort of thing does occurs in other ecosystems: for example, I love Clojure, but you're going to have a bad time with it if you don't grok how Java works. But the JS ecosystem is absolutely teeming with it - often nested several layers deep! The JS community seem to have Stockholm syndrome about this. In other contexts it is just not normal to have to operate simultaneously at all levels of the abstraction hierarchy, at all times. Joel Spolsky wrote his famous "leaky abstractions" essay because it was not immediately obvious that when (eg) using a TCP connection, you'll eventually want to know about how IP works. If TCP/IP had been written in the modern JS ecosystem, you'd need to have a working knowledge of ICMP packet types before you finished debugging "Hello, World" in TCP v2.0.1-rc4(deprecated).