No. Not this. Net even close to this. Let me illustrate:
How to become great at Sports:
- Read books about sports.
- Watch other people play sports.
- Read in-depth analysis of past sports games.
How to become great at Playing Violin:
- Read books about playing violin.
- Real sheet music by the great masters.
- Listen to many concerts.
It's inherently obvious that the above approaches are totally and completely wrong. How do you become good at anything? You practice it. You do it. You have a coach or teacher or mentor who can give you pointers, but lets you make mistakes. You have someone who lets you get things wrong the first time, so that you can see the consequences.
There is a time and place for theory, for reading, for analysis, and this is too part of the learning process, but this is not at all the most important tool for becoming great at something.
Theory, analysis, critique, history, and context all matter when learning any skill, but first, you must build the fundamentals. First, you must do the thing and once you reach a level where you really understand the thing, then and only then can you begin the more introspective task of theory and analysis. Even without these steps, the best way of becoming great is to DO.
I don't think that's actually the best way to be great at chess, or math.
On chess, from a GM: "The key to their success is that they kept playing a lot, and learning from stronger opponents. Don't get me wrong: I am not suggesting stone age technologies in studying. Of course, you should take advantage of the best modern learning methods. However, the most important component of success (at least at weak GM and below level) is practice."
Well, wrt chess, we can have dueling GM quote battles over this point:
From "Andrei Istratescu's top 10 reasons for stagnation:"
1) Too much play
Playing chess - practice - is very important for improvement. When you play chess (over the board, at tournaments), you put into practice what you have learned, you use your brain to think chess, you are in the testing environment, you test your accumulated knowledge and skill against another person.
However, too much play and too little study holds you back. You can repeat the same mistakes over and over. You will tend to follow your own old patterns and not have time to develop a different, correct thinking process, and to learn proper strategy and new ideas.
In this case, you should take a long break from playing and concentrate only on study for several months. You will make a significant improvement.
In my experience, the first chess book I read (Logical Chess, Move by Move) probably bumped my rating by 400 points. Then, more specialized openings and tactics books another couple hundred. After that, simply playing got me mostly nowhere.
In chess below the master level tactics will dominate. How do you get really good at tactics? Not just by playing lots of chess, but by consistently devoting effort to studying tactics via printed collections of positions and/or tactics training software.
As to becoming great, after years of running chess camps for young players IM Greg Shahade formed his somewhat famous hypothesis:
There is one very reliable sign to how much potential and how strong a young chess
player is or is going to be, and it’s probably not what most people would think.
It’s not how quickly a student solves tactics or sees combinations (although
these two things always seem to be correlated with the main point of this article).
It’s not the student’s positional understanding. It’s not even how much they
claim to study chess.
Instead it is “How likely is this student to recognize a famous game/position
and know the players involved?” [1]
As one data point illustrating Shadade's point, the current world champion seems to be a whiz at what ordinary people would consider chess trivia. [2] Carlsen's comment:
"I like chess, I like chess books. You'd be surprised – I do read
as much chess as I can."
Completely agree. I never truly understood discrete math until I had to teach it. I didn't understand sales until I ran a vendor booth for my wife's sci-fi novel. I didn't understand ballistics until I built model rockets and potato cannons from scratch. I didn't understand cooking until my coworkers at Waffle House marooned me at the grill during a Sunday morning rush. I didn't understand linear algebra until I had to write a software rasterizer and a best-fit modeling function. I didn't understand money management until I was poor. I didn't understand relational algebra and database systems until I wrote an ORM. I didn't understand digital electronics until I had to build a kiosk system from scratch (for a client!). I didn't understand analog electronics until I had to build a music synthesizer. I didn't (really) understand AC until I had to rewire my house!
Maybe some people can read a book and just know how to do things based on that. I used to be very caught up into thinking I needed a book to learn things. But that's not really me. I have to do. Most books aren't written in that regard. The authors want to pontificate on minutia. Now, I know I just need to jump in the deep end of making something and--somehow, be it through Wikipedia or Wolfram Alpha or StackOverflow or MSDN or MDN or what have you--I will learn what I need to get it done. Give me a cheat-sheet, some pliers, and a bail of wire any day. Until then, it's all just noise.
I think it ties in naturally to the Lean Startup ideology, i.e. the whole "release early, release often" thing. Using the example of chess, if you're just reading books on chess and are not playing games, then you're no better off than a startup who is working out of someone's basement, no marketing plan, no market feedback, just coding away based on some blue-sky ideology. "Release early, release often" isn't so much about success as it is about getting out of the basement, seeing the flow of things, and opening your eyes to reality.
When I was in "prépa" (see https://en.wikipedia.org/wiki/Classe_pr%C3%A9paratoire_aux_g... ) my English teacher, an American told us that the way he saw the system was to train us at math, just as a way to discriminate us between those who'll get to pick the best school and those who will take what's left. And he said, they might as well train you to do chess for 2 years and let the strongest one pick his school.
He also told me that back in the US where he came from, with his local chess club he went to a prison play with the inmates. They got destroyed, because the inmates played chess all day long so they were all very good.
a lot of people out there don't have access to mentors, so I (unfortunately) feel that the self-learning by books approach is still the most practical, generally speaking.
This is a pattern of behavior I see in people, that they think they need a "mentor" to get good at anything. I've even had people explicitly ask me to be their mentor. Like, people here, on HN, reading my comments, contacting me through my email address in my profile, asking me to be their mentor.
Frankly, now that I'm experienced, if someone were to agree to be my mentor when I was a beginner, I should have been suspect of their expertise, because I don't know anyone who is actually any good at what they do who has time to do anything called mentoring.
Where does this idea of mentorship come from? I have never seen it. I've had examples in my life of people to look up to, but when people talk about mentorship they seem to be talking about some sort of creepazilla relationship where the student sits at the feet of the master and receives wisdom. Yeah, no, that doesn't exist in the real world, at least not for the vast majority of people.
If that's what it takes to be successful, to be reallly good at anything, then buddy, we're all in a world of hurt. It's an appealing idea, but who the hell does it ever actually happen to? I'm convinced it's a fantasy.
Strictly speaking, you don't need a mentor to get good at anything. However, it can really help in the areas that are defined more by people than by things working or not.
As a mentor, I have found that is mostly about reviewing others work and thinking and giving feedback. For instance, you don't really need a mentor to get better at solving problems. You may need a mentor to help you communicate details about the solution.
Any great chess player (let's define that as near-IM fide ratings and up) will tell you that it's a highly iterative process between practice, analysis and reading that is very much anchored around practice.
They play thousands and thousands of hours and, yes, also spend quite a bit of time reading, thinking, analyzing (both their own and others') games and learning from mentors/teachers. However, practice is king and all the reading/analysis would be worthless in its absence. They would have no anchors to grab onto in your brain - no way to really become operational.
A chess "player" that mostly reads, studies and analyzes with a little bit of practice sprinkled in between would indeed be hilariously weak.
Take a beginner player who has been playing at the local chess club once a week (two hours) for 12 weeks. This player enjoys the game and wants to be better. He plays anyone who will give him a game. He occasionally wins against other beginners. He loses to the stronger players when he gets a chance to play them. This player has 24 hours available to work on chess over the next 12 weeks. What is the best way for this player to improve? Suppose the options are, 1) continue attending chess club for the next 12 weeks, or 2) stay at home and study two hours a week for the next 12 weeks. The study material is Logical Chess Move By Move by Irving Chernev (mentioned above by msluyter). The book covers 33 master-level games in two categories: kingside attack, and queen's pawn opening. Chernev, a Grandmaster, explains the reasoning behind every move in all 33 games. When the player shows up at chess club on week 25, will he be better off having chosen option 1 or option 2?
Reading, watching and in depth analysis might be necessary conditions for true greatness but they do not constitute the biggest part of improvement/greatness.
The biggest part is the ability to move a large part of the necessary skillset to your unconscious mind. As a joke Capablanca said "I only see one move ahead, but it is always the best one", this is how every strong chess player thinks, they can instantly evaluate the position. It is just like once you have learned to drive well, you would recognize a potentially dangerous situation(a child playing with a ball on a sidewalk) without actually thinking about it consciously.
I believe this is how the best programmers work too, they have an immediate grasp of possible techniques they can apply without necessarily thinking about them or looking them up in google.
You become great at your craft when you internalize/obtain unconscious mastery of a large number of techniques in your craft. You become truly great when you can combine these techniques in novel ways.
I will mostly speak about chess, because I am an average programmer and average mathematician but am a pretty good chess player near IM strength FM (2350) and have spoken to various strong chess players (up to 2700) on this subject.
There have been players who have become very strong with very little reading (GM Flohr is a famous example from 1930s) but with a lot of playing, however I am not aware of anyone who become good without practice.
So let's start with a simple example. You must absolutely learn how the pieces move, this would be equivalent to what loops and conditionals are in a programming language. If you have to think how the horsie jumps when playing, you are not going to get very far.
A more complicated example, it is very useful to be aware of the standard h7/h2 sacrifice. As you get stronger, you develop a better sense on when this sacrifice will be strong and when it will be likely fail, even before starting to calculate consciously.
How do you obtain this knowledge, the best way is iterative by playing and applying in practice what you learned.
Dunno about chess, but when it comes to doing original pure math research, bookwork is necessary but not sufficient. Practice is also necessary, and lots of it. Even when it comes to reading math textbooks, the exercises are the most important part.
There is a saying in coaching: "practice does not make perfect. Only perfect practice makes perfect."
What that means is that the point of practice is to reset habits to the best possible technique, so that when the athlete is under duress, they are habitually as efficient/effective as possible. Any practice done with poor technique is basically wasted time, and potentially counterproductive. This is true at any point in the athlete's development, from day one to just before the title game (or match or whatever).
So, just writing a lot of javascript will not make someone a great javascript developer. If they write a lot of crappy code, they will become an experienced, crappy developer.
The best way to achieve greatness is to have a great coach (or teacher, or mentor). That person can help one shortcut to the best technique, and they can catch and correct one when one strays from that.
But if one does not have that, then disciplined self-study of known great performers is an ok substitute.
And, when it comes to "how to become great" articles, I think the writer usually assumes that the reader is already somewhat engaged--that their target audience is already writing javascript but wants to get better at it.
It continually amazes me that programming books are as popular as they are. I can't think of a format I'd prefer less than static text when it comes to learning new programming languages.
Much better to just jump in and start figuring things out. Google your questions, find Stack Overflow questions. Fiddle with CodePen (etc) examples to see what variables and functions do what. Once you're well versed, read the occasional blog post about emerging techniques and patterns.
I work in JS day in, day out, and this approach hasn't seen me wrong. But we're all different.
Books are about communicating experiences. A great book can give you the knowledge it would take years to get by personal experience alone. If anything, people involved in programming don't read nearly enough. We have giants on whose shoulders we should be standing, and instead we just retrace their footsteps. We need to stop ignoring our past.
Obviously, practice is also critical, but my point is most people who love to program love the act of programming, so they obviously already do a lot of that.
Because they have the depth of experience that is otherwise unavailable except by months or years of hard-fought struggle.
It only takes being bitten a few times by rushing into a new tech and doing everything completely wrong from the start. The smart learn from their own mistakes, but the truly wise learn from others'.
In my opinion programming is a linguistic skill. A more apt analogy is trying to learn French by reading textbooks on learning French. I spent 5 years teaching English as a foreign language and I can tell you that learning a language from textbooks will not allow you to be "good" at the language when compared to the fluency and proficiency of a native speaker. You will certainly be able to accomplish various tasks and to get your message across to others, but you don't really have a hope of being a "good" speaker or writer of the language compared to even the average child. Your language will be full of tortured constructions that are (hopefully) grammatically legal but idiomatically terrible.
I hope this situation seems familiar to programmers because we see it every day -- programmers who write code that "works", but is tortured in its design. We can see people who can not express themselves in code because they are not fluent enough to do so. We can see people who can not understand common idioms because they never have read other people's code (in quantity). They ivent their own idioms, just like baby talk, and often decide that their baby talk is superior to the living language around them.
The biggest difference between a human language and a computer language is that most people aren't exposed to incredibly fluent users of the language in great quantity. It is really easy to fool yourself into thinking that you are a great programmer, when actually you can just barely make the code work. The same happens very frequently to learners of a foreign language that are rarely exposed to native speakers. You have no yardstick to measure your progress other than your textbooks.
Although I agree with your assesment that you must DO, but even more so you need to seek out communities of fluent users of the language and interact with them. That means reading their code, writing code, having them correct it, etc, etc.
A professional software engineer should be regularly reading to keep up with their craft. It's a balance, and one that I've generally noticed is tipped away from focused reading/learning because the modern Stack Overflow-driven world nudges people to "just do it." Telling people "you should read a lot of books" shouldn't be necessary, but nowadays it is.
In one of my recent interviews, I was asked how do I learn a new language. I rely on good 'ol practice of reading from top to bottom intertwined with YouTube, conf videos and blogs. This highly experienced architect called my approach non-agile. He was expecting me to take a quick and dirty SO-route for fast results.
I think of books/knowledge as an experience accelerant. One could set a log on fire and it will burn, but it will burn a 'hek of a lot faster when liquid oxygen is poured onto it. Books do the same thing for practice. You'll get there one day with practice but you'll get there much faster when you're practicing under the influence of performance enhancing books.
One example from my own experience is Estimating.
It's something we all do, week in, week out. Yet there are still plenty of developers with years of experiences who delivery poor estimates week in, week out. I was one of these poor souls when I started developing. I would spend countless nights up late trying to finish a feature I promised someone else would be delivered yesterday.
So I did what my grandpa always recommended and I picked up a book, Steve McConnell's Software Estimation : The Black Art. And it taught me all types of tricks like making sure to break tasks into the smallest possible pieces.(Along with many other things. Seriously by this book, and every book Steve McConnell has written)
Maybe I would have eventually figured out tips like these on my own. But instead of having to wait to practice breaking up tasks into smaller more estimatable chunks, I got a 5 year head start and quickly was able to surpass many coworkers who had more years of experience but had spent less time in a book.
And now I can spend those late night posting on hacker news and not writing code trying to catch up for work :P.
TL;DR : Books are awesome. I read one once and I am a better estimator for it. And being a better estimator lets me spend more time on Hacker News. So if you wanna spend more time on hacker news, read a book.
Exercises are very different from projects. When you support a project over the long-term, you engage a very different set of skills than what you'll get in a book. You learn how to push your way through a seemingly unsolvable bug that nobody has encountered before, often one in code that you didn't write. You learn how to make technical choices that reduce the likelihood of encountering these bugs. You learn how to come back to your program in a few months and pick up where you left off, and what sorts of coding practices will inhibit this. You learn what sorts of bugs occur in practice, and how to avoid them. You learn how to diagnose performance problems, how to speed them up, when to speed them up, and you build up a mental model of how the systems you work with behave. You learn how to limit complexity, and what the complexity budget of your brain is, and how to break up projects so that you stay within that budget. You learn how to communicate with other programmers, and what they care about. You learn how to build up a codebase incrementally, how software evolves, and how the why of the code usually matters more than the how. You learn how to communicate with users, and how to accept their input, and how to weigh the costs of their feature requests against the complexity of the code base.
All of these are emergent problems that only occur when you work with large, long-lived software systems. You won't get them out of a book.
This is bad advice. Theory is vastly more important in computer science and math. Given your logic, one will simply practice their way to linear algebra, machine learning or AI. Good luck with that. There's a giant toolbox of shortcuts that seem like magic to the inexperienced. Becoming a great _user of tools_ (programming languages, etc.) is level 1.
Isn't reading books a good way to build fundamentals? I don't think reading a book necessarily precludes you from working on the exercises in that book, which would indeed be a great way to build your understanding of a language. This is the way I approach learning new languages - working through a tutorial, or, indeed, a book. Giving someone the advice, "Hey, just go write some JavaScript," probably isn't great if they don't know any JavaScript.
While I see where you're coming from I think your analogy is flawed and it doesn't quite apply here.
As a martial artist and weight lifter that totally makes sense - practice, sparring, doing the actual activity is what will make you good. The more you do it, the more you train your subconscious to intuitively know what to do.
As an engineer and tutor it only applies in a limited way. I have taught people who want to learn programming but lack all sorts of fundamentals. What they need to do is just go back to basics - read a book - do the exercises. I find that as an adult learner missing the basic background on things just makes everything hard. You will need to ask questions every step of the way. Who will be on hand to answer those questions? People like me, who have sat down and studied the basics and learned from first principles, i.e. worked through the books.
Coding is like math. Both practice and theory are important. If you don't read the chapter first and try to jump right into the exercises, you will not be able to do them properly. If you read the chapter but do not do the exercises, then you will forget everything you've read.
Having a coach is a luxury. For us software developers the closest thing we get to coaching is a code review by a more experienced developer. That is certainly valuable but rather hard to come by consistently if you are past certain level.
So what to do without a coach? Find something that will direct your practice. For this reading quality code is indispensable as it shows you the range of possibilities of what you can do with certain technology.
Considering your example of sports: past certain level it is essential to meticulously study video footage of yourself and your opponents in action as it provides insight into your weaknesses and your opponents' tricks which you can then adopt or learn to counter. Also when someone comes with spectacular advancement in technique (think Fosbury flop) it is quickly analyzed and adopted by others. So watching others is sometimes very useful.
I agree, one must oscillate between theory and practive. Acquire data, follow your intuitions, reflect on it, explore alternatives, communicate with others a little.
What do you think about Platonic teaching ? asking question to direct exploration without giving 'free' (~bad) knowledge.
This is the best comment I've read on HN! I guess you need to become great at something to understand this. For you to keep doing something though, you need to think it's fun! Then it will be much easier.
I kind of read it as the assumption is, if you're wanting to be a great JS programmer, that all these recommendations come on top of programming in JS as much as possible.
The best thing that happened to me as a JavaScript developer was being exposed to other languages. Especially the not-so-fancy Java and C++, really opened my mind about structuring code and planning for a long-term project.
Knowing JavaScript and JavaScript frameworks is surprisingly useless for the type of work JS devs usually handle. The documentation often consists of TodoMVC type of examples and approaches. Hardly anyone explains how patterns like DDD, SOLID, advanced REST, etc. fit into this. The highly appraised Flux is in reality just a pub/sub system like many on backend (and still it's a huge step forward - it admits JS systems are large and complex).
I'm just looking at a system design graph, preparing for a new job. There are about 30 nodes representing multiple services, databases, load balancers and processes on the backend. There are two for frontend - one says "JS" and the other "JSON". This is how most people think about frontend and to be a great JavaScript developer just don't be one of them.
I agree a lot with it. I also think it's useful to work with at least one statically-typed language (like Java for example) because it teaches some good maintainability practices. In JS world, I've seen far too often creating objects in random places, as a map of parameters, passing them around, and injecting new keys to the object in other random places, and when such an object goes around too much and is augmented randomly in a myriad of ways, it's really hard to reason about it.
In Java, you'd typically create a separate class for such an object, create fields, assign types to them and document them, and have a constructor which populates the fields with sensible defaults if not provided. Sometimes it's an overkill to do it this way, but often it pays off with a better understanding of the data model. In JS you have a lot of freedom, but too much freedom leads often to a mess when enough people are working on the code.
I enjoy the freedom to use a map/object/parameter object as named parameters, speaking as somebody who has suffered through much Java ceremony.
That said, JSDoc helps a lot: make a @typedef comment for parameter objects at the top of a file, then use the type in the @param annotations of the relevant functions. Makes understanding the JS code in an IDE much easer, as well as having something worth generating HTML documentation from.
I second this. Sometime back I did Python for a production work. That for the first time gave me a true sense of Object-based inheritance v/s class based inheritance. Prior to that I used take JS way as-is. But wholeheartedly, may be not so much.
I never said it should be more complex. It, however, should be also structured somehow. There is a persistence layer, models, collections, services reasoning about them and pipelines aggregating and rendering things.
Well written JavaScript is reasonably fast and it now makes sense to optimize transported information size. Many calculations can be done front-end side then, which accidentally is also more cost-effective, since data center usage is paid, while user CPUs are more or less free (and not doing much while browsing anyway).
Just adding my two cents. Wanna be a good JS dev? Go play around with a lisp. Like Clojure for a month or two. Get comfortable with functional programming. Then come back to JS. So many people come from a OOP to JS and they have a bad time with it. JS is more like a lisp with C syntax than it is a traditional OO language. Learning Clojure, not only improved my JS abilities, but just my over all programming maturity. IMO. Additionally, I agree with the author about reading books, and libraries. It's always good advice for any language.
Indeed, so the tale goes: Brendan Eich was originally going to make Scheme for the browser, but Netscape said their browser language had to look like Java, and that's how we wound up with this odd vaguely-functional browser language called Javascript.
In light of that, definitely seconded. Using Clojure (and watching Rich Hickey's amazing talks) made me a much better developer, and especially a better JS developer.
Somewhat relatedly, one thing I personally like about CoffeeScript is that it really lets the functional, Lisp-y side of Javascript shine through by melting away all the crufty syntax. That really helped me apply some of the style I picked up from Clojure.
JS brings a lot more to the table than just a scripted version of "C++ for retards" (aka Java), as it also lets you make use of many FP concepts like higher order functions and functional (vs object) composition.
For example, using currying (aka "dependency injection for functions") lets you often do with a single function what would take a silly-long class to do in Java. Use currying to inject leading parameters to a function that would normally be in the constructor (or setters, ugh) in a Java class, then the remaining "short arg list" function acts like the oh-too-common one actual "we're ready, now do something" method in a class.
Downside is that after using a proper functional language (clojure[script]) you end up wanting some really basic things such as immutable core data structures.
I feel like if you start from scratch on a javascript project, it's possible to program in a functional manner. I've found it really tough to introduce functional concepts to an already full stack javascript codebase.
BTW: I'd recommend ramda [1] for those interested in functional javascript programming. The auto-currying makes it way more powerful than underscore/lodash in terms of encouraging pure reusable functions.
If you've only been exposed to OOP, and you don't have the bandwidth for learning an unrelated language, then start using a functional library like Underscore. Just use it everywhere, even if you think it's ridiculous. Don't use for-loops, use _.each. Try to think of every problem in terms of chaining map, reduce, zip, pluck, groupBy, etc. Do whatever you can to avoid side-effects.
Once you're comfortable with it, try reading "Functional JavaScript".
You'll quickly develop a taste for when OOP or functional is appropriate, but I think the best way to get to that point is to immerse yourself in functional programming first, which might mean writing some ridiculous functional stuff, but the long-term payoff will be worth it.
Indeed. Personally I'm used to think in functional ways: map, fold, function composition, immutability... I'd like to be good at Haskell but I'm always having lots of pain dealing with it, because I never see the end of the learning curve.
I've found JS to be a nice middle land where I can get productive functionally without too much hassle. It's like a good friend who understands my way of thinking without being in the way too much. Underscore.js hits the sweet spot for me: _.chain(...).map(...).filter(...).value() is verbose but surprinsingly readable. I'm not a fan of Python map() syntactically, and I absolutely hate C++11's std::transform.
If you want to make that even less verbose, try myArray.map(...).filter(...) (those methods don't have to come from underscore, they exist on the Array prototype as of ES5).
Interesting, thanks for this perspective. As someone who started with C/C++ (and a hint of Python) but has recently started working in Clojure, I'm now very encouraged to re-try JS.
If you're already a decent enough developer and just need to get your grips on JavaScript, I'd say that most books listed aren't that useful. A decent enough online reference will get you going and after that you'll have to consider that JS is a pretty large dung heap by now where you probably won't get a lot of mileage out of inhaling dust from the crusty parts. Unless you're an enterprise developer tasked with maintaining your company's Dojo application.
If you're a new developer coming into JS from a more tabula rasa situation (possibly these days), I'd still say that most of those books are wasted, and you'd probably get a better mileage out ouf SICP or the GoF book than most Ninja/21days/Dummies tomes.
The core of JS is small enough, and the rest is highly dependent on your task, scope and framework. No jQuery book will help you with your intranet extjs app or your state of the art fluxified React SPA. You'll have to wade through code to get there, preferably as much of your own as possible.
And the most important thing: Pick something and stick with it. No mid-project framework/build tool/library changes. Even "obsolete" tech still works better than falling into the Duke Nukem hole. So don't get nervous about still using "grunt" when all the cool kids are using "gapoodle".
For the decent developers picking up Javascript, http://learnxinyminutes.com/docs/javascript/ is hard to beat. All the basic syntax and language features in one page without trying to explain to you what a while loop does.
// Statements can be terminated by ;
doStuff();
// ... but they don't have to be, as semicolons are automatically inserted
// wherever there's a newline, except in certain cases.
doStuff()
// Because those cases can cause unexpected results, we'll keep on using
// semicolons in this guide.
I haven't gotten much into Javascript yet, but is there any reason I would not terminate with semicolons? Without understanding which "certain cases" won't have them inserted automatically, relying on that feels like asking for trouble.
As a general case I recommend always terminating each statement with a semi-colon. Then it is explicit to the interpreter and other coders (and "other coders" includes "you six months later when you've forgotten most of what you did today") that you intended this to be the end of the statement and the next line to be the start of a new one.
Only ever leave the semi-colon out at the end of a line when you are explicitly using a multi-line statement to make your code more readable.
This makes your intent unambiguous in both cases; to the interpreter/compiler, to other tools, and to other humans.
My understanding is that the original decision was to make life easier for the programmer: if you forget, we'll put one in there for you. Myself, I'd rather be told that I made a mistake, then have it ignored, because how does the compiler know what I really wanted?
Instead of being told there's some problem with the code, it inserts a semi-colon into an arguably ludicrous location, and then gives you a differen error.
Would probably make compiler writers' jobs easier if they just spit out errors.
The actual reason that third function compiles, and the fourth does not, is that
{
x: 0
}
is a block statement with a label x. Try it in your console, it returns 0. The last one is an object literal outside an expression, which is a syntax error.
In addition to that, the return statement is 'restricted production' where the line break itself is a terminator, this has nothing to do with semi-colons or ASI.
Coming from a mostly C, Java and Perl background, I've got no personal issues with semi-colons, and often find myself adding them in languages where they're completely unnecessary, especially when switching back and forth.
Having said that, your argument could also apply to operator precedence and parentheses. Yet most languages implement this, and most users don't add them unless they're in doubt (more often with e.g. logical operators than arithmetic ones).
The rules aren't that complicated and the corner cases are (IMHO) a bit overrated. The way I see it, the more pressing reason would be the accepted JavaScript style, just like the positioning of braces.
Ah, the "minify" bug: forcing people to put statement separators into a line oriented language.
Think of semicolons in JS like colons in BASIC: they let you stack multiple statements on a line. Then, go learn what the language REALLY thinks is the end of a statement, which is not "I put in a semicolon".
Too bad JS doesn't use (an explicit) backslash for line continuation, rather than guessing when a line/statement was done :-(
Missing semicolons have more pitfalls than just minifiers being naughty.
return
someExpression
will parse out as:
return;
someExpression;
and you have assumption of function call in
x = y
(z).whatever()
which parses out as
x = y(z).whatever()
Nothing hint or lint wouldn't catch though. IMHO, you really need to be special to avoid explicitly writing out semicolons, but to each his own. I can maybe give it a point for unique style. :)
Wow, I got schooled. Did not realize rule 4 about lines starting with array subscript brackets or function argument parens. (regardless of the line's intent of perhaps being an array literal or simply starting with an expression to be evaluated early)
The sad reality, taking the second link to its satirical conclusion, is that all JS should be written on one line, with semicolons between statements. No guessing about the effects of line breaks if there aren't any. "I say we take off and nuke the entire site from orbit - it's the only way to be sure." :-)
How would semicolons have prevented the first of those misunderstandings?
-- Don't get me wrong, those are good cases to know what is going to happen. But I think you are making the case that semicolons provide a false security blanket, since the language can complete a line you meant to wrap, or, alas, merge 2 lines you meant to have separate.
I think shell (and a few other languages) actually got it right: 1 line = 1 statement, unless there is an explicit continuation.
You might be right in that it technically is the best approach, but pedagogically the value of starting with a more specific jQuery, or Rails book is that it's just more fun to build something that immediately does something that you can see and play around with, especially if you can do so right within the browser.
Of course, it's not a good thing to stop there, but in my experience it often acts as a gateway for beginners to start actually learning 'proper' programming.
My brother, for example, has been working through the Rails tutorial, and already he's starting to read more general ruby books, doing javascript tutorials, and thinking about building a game for the browser using Rails as a backend. Plus, he'll be able to make money much sooner this way, which is a great incentive for him to keep at it.
I disagree with the last point. If you can make sure that the change is worth it, that you understand the new technology very well, and if you make a commitment to follow through and do all the necessary work, you wont fall into the "Duke Nukem" hole.
(The problem of course is that often times we don't take the time to make the necessary evaluation and want to make a change just for the sake of learning the new shiny)
I'm talking about the beginning JS programmer. So it's quite likely that they don't understand the technology they're currently working on and thus have bigger problems evaluting the new one, as there's no good point of comparison.
Also, I hope that the first project a JS newbie does isn't a 100'000 line app, but something more bite-sized, and thus you really don't have to wait months to get to use the new stack or tool. Quite often this kind of decision making happens when the project is 80% done and you have to face a few things that aren't that easy or your code has become a bit too complicated. And yes, the new tool could solve that and you might even end up re-implementing bits and pieces of that. This might not be the most effective use of your time, but it's a good learning experience.
Missing advice: learn to program well in a few well designed programming language. JavaScript was designed in 10 days and the main reason it still exists today is incredibly strong path dependence. There's nothing wrong with wanting to become a great JavaScript developer, but one needs to become a great developer first, and JavaScript just isn't conducive to that.
I personally am so over this argument. Sure, that is roughly a fact about the time in which it was designed... but that was 20 years ago. Since then there has been a team of some of the best programmers in the world maintaining and advancing the language.
That's irrelevant; advancing the language isn't an exercise in programming language design, it's an exercise in getting everyone to support the extension and in avoiding breaking legacy code. It has almost nothing to do with the maintainer's talent as programmers or PL experts.
If you doubt this argument, consider the fact that the horrible scoping, the weak typing, the insane casting rules are still here to this day; empirically you're wrong.
Well, a lot of the little issues are being slowly fixed (see let and scoping in ES6). This goes back to the point of the person you are responding to.
This is a thought more than a full-fledged argument, but perhaps little issues with the language actually can and do make people better developers when they are aware of them. My friend started driving a scooter. Dallas isn't particularly conducive to that. My friend says he has since become a better driver because he knows one little screw up by him or someone else can end his life. Similarly, you'd better be aware of weak typing and casting and code accordingly or you might get hurt. Of course, you shouldn't have to...but that doesn't make people worse developers.
But the truth is, JS has a lot of features which make it great for becoming a good developer. It's less class-based than Ruby and has better lambdas than Python which I would argue make it better for functional programming than either.
Yes, "let" will finally fix the horrible scoping - 20 years after the creation of JavaScript. In the meantime you'll still be stuck using lovely constructs like === and !==
And yes, JS support for lambda expression is surprisingly nice, but that is basically the only nice surprise.
Since then there has been a team of some of the best programmers in the world maintaining and advancing the language.
JavaScript engines have seen a lot of effort from some of the best compiler and JIT experts in the industry, including former Self VM architects, yes.
The language itself? I honestly can't say that. Lua is a way better ECMAScript than ECMAScript itself, and the focus should have been on trimming it down to a smaller but easily extensible core, as opposed to the feature piling that's going on.
"Since then there has been a team of some of the best programmers in the world maintaining and advancing the language."
If you build a church from chewing gum and then get Gustaf Eiffel to design a few towers to it from steel with furbishments by Antonio Gaudi the fact still remains there is a heap of melting gum at the bottom.
Stuff that needs to be designed up front cannot be fixed after the fact regardless of the amount of ducktape and personell applied.
This is a good collection of resources that I have found are very educational and useful. That said, for me personally it was extremely important to dig into some problems concretely rather than by reading. "OK I've read about how I should do this in the ideal - now go actually set up an Angular app with a full test suite pointing at a REST API." Or perhaps - "I've got a great idea for some code art - let's try it out."
Without the follow-through I found that I could keep up in a conversation but still had doubts and issues when it came to implementation. Doing it in anger, delivering a product, as many times as possible helps a good deal in moving toward greatness.
I'd like to know how to learn to "accept" JS, coming from other languages.
No really.
How do I become a JS developer that doesn't whine all day long about all the little idiosyncracies of the language, or the tediousness of writing tests for things my compiler should work out? Obviously people enjoy writing JavaScript, and at least some fraction of these have to have been the kind of person that whined about the type systems in Java or C# being too weak.
If you were one of those developers, how did you let that go (did you?) when becoming a javascript developer?
It took me a while. My background was Java, Python, ActionScript and a few other languages sprinkled in. After about a year working JS, its now my preferred dev environment.
The turning points for me:
- modularity - npm has really changed the way I program, for the better
- Node.js tooling (including a Browserify, Babel, Webpack) will greatly improve your experience with the language
- live reloading, zero compile time, instant visual feedback
- the breadth of Browser/Node/npm APIs can make it a ridiculously productive language to work in
- IDE plugins and linters can catch a lot of errors as you type
- above all else; it has an amazing community of enthusiastic developers, tinkerers, scientists, artists, etc.
Books are a waste of time. Most of them are garbage to begin with, and most of them are practically obsolete by the time they are published. Few have any lasting staying power.
Besides, nobody ordained the author to be an authority on the subject. He was just a guy who wrote a book. It's zero indication of the quality of the content.
Writing code without guidance is probably the slowest way you can learn something. A good book or class will save you countless hours living with the consequences of your naive mistakes. Good writers and trainers forewarn people about pitfalls by providing fair warning about common mistakes. Better writers and trainers instill good mental models that timeless help the reader solve problems.
I'll agree that there are plenty of bad books that give bad advice. The solution isn't to say books are a waste of time. The solution is to recommend better books.
If one has knowledge others can benefit from, one doesn't need to be "ordained ... an authority" to write about it.
If one cannot find a mentor to tell you this is good Javascript and this is bad Javascript, then books can fill that void.
Writing code without any guidance can only get a developer so far. He needs examples of good solid idiomatic code to progress. A good book, often by "just a guy", can provide that.
Because there is no objective way to evaluate the quality of a book before reading it, and because any useful information in most of the few good technical books is of limited lifespan, books are a waste of time. It's not just that books can be bad. It's that most books are bad, and having to wade through them is what makes them a waste of time.
No, books are way better than reading blogs and forums. They keep a context and enforces the same style through the whole book which I find very useful
Totally agree. Best way to learn is to write, and if you want good examples to model after, check out the popular projects on Github. People are actually using those libraries and frameworks in production, unlike the toy examples in books.
One exception is more abstract thinking -- algorithms, general design principles, etc. I think a book can be handy there sometimes.
If a book on software is truly obsolete anytime shortly after publication, then the tech itself isn't truly stable.
Read "The C Programming Language", by Kernighan and and Ritchie. Written decades ago, still accurate and relevant today. "The Mythical Man-Month", "The Pragmatic Programmer", "Design Patterns"... books like this will always be relevant.
Maybe a good rule is to stick to CS books that have been in continuous print for at least ten years.
I 100% indorse "read libraries". There really is a lot of wisdom buried in them. I read through MooTools back in the day and I would go as far as to call the experience formative. Read frameworks you don't like and consider WHY they work like they do.
Become great in language X seems the wrong goal to me. An enormous amount of things and at the same time the most important things that make you a great software developer are completely language agnostic. And I would argue they are harder to learn through the lens of a single language and software stack. You then still have to become a productive software developer knowing your libraries and tools and their quirks but this seems secondary to me and easily compensated by your favorite search engine. Or by example - knowing when to use a set as opposed to a list is more important than knowing in which namespace you can find the implementations for language X.
What prompted me to develop as a JavaScript developer was being put in charge of a major project that was mostly JS code. Up till then, I had done some JS work, using jQuery to add animations and interactions to a UI and some ajax. Doing this JS project exposed me to pretty much everything you can do with JS, and I learned it all pretty quickly so I could start contributing to the project.
I only got this project too because the dev previously in charge of the project left the company and I asked about it. It's another lesson to new developers: never let an opportunity pass you by.
Tastes in books varies wildly between developers: there are many on there that I wouldn't say helped me as much as others, but to each their own!
With that in mind, I'd put a plug in for David Herman's _Effective JavaScript_. It goes beyond simply stating the mechanics of JavaScript into what pitfalls can be had, and uncommon but critical factors to consider when writing your code. The point about UTF-16 code points in strings alone makes it a valuable resource.
I think it totally depends on the problem domain you are working with. There are so many different ways to use javascript it is overwhelming. There are also lots of ways to structure it. I feel like a very good understanding of a widely used OOP language such as Java is a good place to start before jumping into the wild west of javascript programming.
I think that setting up a test environment is one of the bigger hurdles (it seemd more confusing for JS than for most other languages I used before). Starting with installing node and "node myfile.js" is pretty good to get going (writing hellow world, fizzbuzz etc.). I struggled quite a bit sifting through all the options after that (e.g. npm+Grunt+Browserify to be able to require stuff etc.). Maybe I'm imagining things but the simple "getting started" was quite complex for JS. Or in other words...the first steps are pretty hard imo.
The inclusion of Backbone seems a bit odd. Isn't that also frontend-ish (like the pick one of Ember,React,Angular). I'd rather substitute it for Express.
Maybe it's person-dependent, but I've learn most JS from MDN (https://developer.mozilla.org/en-US/docs/Web/JavaScript) _and_ collaborating with others (plus a lot of blog posts, code snippents, and in general: reading code by good developers (side note: it's why I hate minification - I habitually read code on webpages)).
For books the main problem is that they are getting obsolete quickly (JS is a rapidly-changing technology) and, except for very basics, somewhat opinionated and task-dependent.
To be good at something, you do not need to know things outside of the area. It might however be helpful if you need to go "outside the box". But to be an expert at the things in the box, you only have to know about the box ...
That said, before I started with Node.JS and understood it's "patterns" JavaScript was just some evil necessary to get things to work. But after learning the module patterns of Node.JS, JavaScript started to get fun!! And the more ppl that understands "modules", the more fun it gets! So go learn about modules and even try making your own!
I guess Node.JS is now part of the JavaScript box.
"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."
— Robert Heinlein, Time Enough for Love
I have a hard time thinking of "web programmer" as "polymath" and worrying that it's not specialized enough.
I just want to point out that 'JavaScript the Good Parts' is not a good first book for beginners. David Flanagan's book is a much better book to start off with or Zakas book `Professional JavaScript for Web Developers` is the one I would suggest, then Crockford's book. Nothing trumps practice though,just keep coding and breaking things just to fix them, that, imo is the way to learn anything.
I don't think there's any other way than working with talented people. It shows you what they're better at than you are, and (maybe) what you're better at than they are. I did all this stuff and I thought I was pretty hot shit, until I joined the team I'm on now.
You have to find out what you don't know that you don't know, and it's really hard to do that on your own.
I mentioned this elsewhere, but I thought it would make a nice "top level" comment: Learn to use (and use) JSDoc in your JS code. Having comments that generate a standardized index of your code, as well as being used by an IDE, greatly helps the comprehension of the code when you come back to it a day or two later.
tldr: ( my own, not the authors in the article itself )
- Read books
- Learn libraries ( author seems to like node.js and recommends libraries associated with that )
- Do exercises
- Learn how classes work in JS ( Note this is amusing to me since JS does not have classes in the typical sense [ they are implemented via libraries with prototypes and closures ] )
- Learn what Es5, Es6, ES7 are ( There are good things here, but be aware that most of these features are not implemented in most browsers and will requires shims and/or translators to even function. Be careful as they may work in your browser but not others. Test! )
- Read JS blogs and watch JS educational videos
- Practice
It's an okay article. If you are clueless how to start learning seriously this should help. Some decent books and websites are mentioned by name.
I think the "every JS developer needs to learn XYZ" is a bit off though. This is one man's perspective.
> Learn how classes work in JS ( Note this is amusing to me since JS does not have classes and everything about the way they are done is just craziness compared to a real OO language )
This kind of derision is typical of people who try to force prototypal inheritance to work in the same way as classical inheritance. I suggest learning the details of the prototype chain and how it works - you'll discover it is about as powerful as classical inheritance, but in different ways.
- Learn how classes work in JS ( Note this is amusing to me since JS does not have classes and everything about the way they are done is just craziness compared to a real OO language )
Are you kidding here? In ES6 classes provide nothing more additional than the closures already in use via a bit of extra utility code. Doubters should click the link here provided by Luke. It is filled with "To Be Determined" for all details of anything useful.
Do you know what classes actually do in a real OO language, or are you just a fanboy of JS?
Also, using shims or translators proves nothing. I can write in C++ and use translators to convert that to JS. What is the point here exactly?
Adding extra confusing junk onto a weak language does not make the language "better", especially when the standards you are recommending people to learn aren't even finalized.
Where is the Acid test for ES5, ES6, and ES7 features? Hell where is the Acid test for HTML5?
Oh that's right; all of this is just a pile of nonstandard junk that people are begging for and isn't really implemented.
> In ES6 classes provide nothing more additional than the closures already in use via a bit of extra utility code.
ES6 classes are sugar over prototypes, not closures. Insisting that ES6 classes aren't classes requires at the very least a basic understanding of how they are implemented.
> Do you know what classes actually do in a real OO language
JavaScript is a real OO language. Do you mean class-based?
> are you just a fanboy of JS?
Surprising vitriol here and makes you lose all credibility. Why does stating a couple of facts imply that you are a fanboy of JS?
> Also, using shims or translators proves nothing. I can write in C++ and use translators to convert that to JS. What is the point here exactly?
The point is that you stated that ES6 and ES7 code don't work cross-browser. Using Babel means that they do.
> Adding extra confusing junk onto a weak language does not make the language "better", especially when the standards you are recommending people to learn aren't even finalized.
Have you looked at the implementations of classes in jQuery, Prototype, Mootools, Dojo, etc? I have. I've used thousands of lines of codes from these libraries and fixed numerous bugs in them.
( Note I'm referring to the 'bind' function specifically in the case of jQuery as it doesn't even provide an equivalent to Class.create(). That said, John Resig himself wrote an article about this and ported out the core of Prototype [ same as I have done ] http://ejohn.org/blog/simple-javascript-inheritance/ )
Using the prototype may be the way that things get copied from the base definition to an instance, but generally closures are what allow things to have the proper scope. Arguably the scope is far more important for using something like a class than the copying. Additionally, without closures there is no way to pass of anonymous function pointers calling back into the class.
If you think you are demonstrating that I have a lack of knowledge of how this shit works, you are mistaken. But by all means, continue disregarding my points and nitpicking details instead.
You will note that here on hacker news I don't really give a shit about my credibility; I care about providing the most accurate information I can to the benefit of others.
You haven't invalidated my statement about translators at all. ES5, ES6, etc are not cross-browser compatible. Using a translator to "make it work" doesn't count. If you wish to say that C++ is cross browser compatible too then fine, but it is obscuring the root issue that those features do not exist in all the browsers, nor even the whole set of them in any one browser. This is misinformation and will mislead developers.
My last paragraph is in reference to the fact that JS/Ecmascript have never truly been "fixed". It is just a constant hodgepodge of whatever vendors decides to add on to the language.
> Have you looked at the implementations of classes in jQuery, Prototype, Mootools, Dojo, etc?
Yes, and jQuery doesn't implement classes.
> I care about providing the most accurate information I can to the benefit of others.
By calling other people fanboys after they provided a link?
> ES5, ES6, etc are not cross-browser compatible.
I guess it depends on your definition of cross-browser compatible, but ES5 is what, 5 years old now? I guess it doesn't work on IE8, but by that definition ES3 isn't cross-browser compatible because it doesn't work on IE1.
As for ES6, it's cross-browser compatible in the same way that CoffeeScript is, with the added benefit that it'll work natively in most browsers in a few years.
> My last paragraph is in reference to the fact that JS/Ecmascript have never truly been "fixed". It is just a constant hodgepodge of whatever vendors decides to add on to the language.
jQuery provides bind. That and related code is what I am referring to in that case, hence my insistence on the importance of closures. I have revised my comment to mention this as well as the fact the John Resig himself reccomends the Prototype way of doing Class.create(). By the way, Class.create() itself is implemented as a closure.
Are you claiming that CoffeeScript is cross browser compatible? If so you are just going further down the rabbit hole. To my knowledge there is not a single browser than itself is capable of parsing CoffeeScript without a helper library that doesn't come installed by default. ( Firebug comes to mind, and if I recall correctly there is a helper tool for that. I'm also aware of source mapping for debugging things such as JS in both Firebug and Chrome )
I'm using ES6 classes (and even parts of ES7) extensively in production today, and it's not nonstandard junk, and it's definitely made the language better.
I definitely do not consider myself great JavaScript developer. Not even mediocre. Code by some people that now do JavaScript lectures, I've refactored and made at least order of magnitude faster, so there's that.
There's one important thing I've already learned though and I'll do you a solid - be a total nazi to your code.[1]
At the start, it's easy to get impression that it's all loosey-goosey-everything-works kinda thing, and it actually is...at small scale! When you get to medium-sized thing, all hell starts to break loose, and I'm not talking just callback hell. You can avoid all that with modest amount of discipline.
I'm aware many people have qualms with JSLint, some even with JSHint. But it doesn't matter what you use as long as you keep consistency. Those two tools help you with that. If you can be disciplined without it, sure, go for it. Just reading on possible configuration options for JSHint already made me consider many potential pitfalls I wouldn't have even thought of otherwise..
As far as learning goes, I'm definitely recommending learning as-you-go. To hell with academics - this is JavaScript, language made in few weeks[2]. You can develop amazingly accurate feel for the language in spite of not knowing rigorous abstracts. You're not sure what new actually does, and you're on deadline? Make a note - "figure out new" - and move along. When you manage to scrounge few hours of your busy week, run through those questions of yours across plethora of amazing resources online, head over to #Node.js or ##javascript on freenode, ask and ye shall receive.
In JavaScript, there's about a million ways one can make something work, an immense solution space. Are you sure your attack vector is good enough? Refactor aggresively!
[1] I wanted to go with "anal" instead of "nazi". But you get the idea.
My breakthrough moment with JavaScript was reading Mark Jason Dominus' ''Higher Order Perl'', and realizing everything described there could be applied to JavaScript.
Force yourself to lint your code. Having clean code is like having good handwriting, it makes content of your projects easier to understand and drastically improves how you think about what you're building.
This is sort of like asking should you learn Swift or Objective-C, albeit much less difference between syntaxes. You can certainly get the job done on ES6, and the future is certainly in that direction, but all browsers still run ES5, so if you want to get paid for your work, you'd need to still know that syntax.
Babel is a great tool to let you use some of ES6's features now, but it will still help in debugging to know ES5 syntax since Babel transforms it at runtime.
If you been doing a lot of JS for web stuff, and used SO etc to check things but don't have a thorough understanding of the language I would recommend the book "JavaScript the good parts"
JavaScript the Good Parts shouldn't be the recommended book anymore (and I think even Crockford himself said something along that line in one of his newer videos, couldn't find it though... it's been a while)
This is awful and wrong. Always Be Coding. That's how you become a great JS developer. Or great anything. Practice makes perfect. It's said for a reason.
Thanks for this link. I will be reading it for sure. I also stumbled on the annotated source of Underscore.js a few days ago (http://underscorejs.org/docs/underscore.html). Would love any more stuff like this that anyone knows of.
Why oh why are those not comments within the source file? It would help me so much to have comments like those in software...
Generally I think that a linear step-by-step description is often not the best way though, often you would have to explain concepts or the bigger picture first.
Read a book or six top to bottom, mix it with video and blog posts focusing on concepts that are deemed complex or critical in that subject.
Build general purpose libraries, plugins, micro-framework or personal projects. Follow-up by validating your work with your community or sample audience. I have been taking the later route.
When it's done. Read some more and build some more. Put it on a repeat loop. Look for some variation as it brings different perspectives.
As minimalistic as your comment is, I think it points to the single most important truth about JS: It's practically impossible for human beings to write “good” JS code. The only hope you have is using a sane language with sane concepts that can be compiled down to the JavaScript of the week (ES6, ASM.js, the works...).
I would argue that JS should be handled analogously to Assembler: Good for you if you understand it, but only highly trained field specialists in protective suits dare to write production code in it. Go and get a decent compiler if you can't avoid using that technology.
... I'll never, for the life of me, understand comparing a high-level scripting language to almost the lowest of low-level assembly languages, as if JS doesn't give you abstractions at all.
If you can't write good code in JS, it's because you're a bad programmer.
As a veteran C++ developer, I actually quite enjoy Javascript. Once I understood that Prototypes are linked lists and that *this is a pointer that changes according to 2 simple rules, Javascript became quite easy.
I mean they even give you a GUI debugger. It's hard to get stuck for long, even though it's not not a Visual Studio.
Like you said, you have already all the abstractions you need with this language. You can do complex things and for me, if I have composition, I'm pretty much already good to go.
IDK, I've been writing JS since it was invented, so 20 years now. It was one of the first languages I learned and even then I thought it was easy. Certainly easier than C, which I was also teaching myself because it was clear at the time that nobody took JS seriously. And that was at a time when there were ZERO libraries. It took almost 10 years before anyone started serious work on libraries for JS. Up to that point, you just copy-pasta'd snippets.
I remember thinking it was easy like VB but was easier to show to other people. I still think of it in similar terms: easy to write like Python but a hell of a lot easier to deploy and show off.
It's so easy to write code and have something running. It's a whole other affair with regards to a 'structured' project involving a team of devs. If you look at the myriad of libraries and frameworks for JS, just so the dev workflow stays at a sane level without ending up with masses of balls of muds. Including a .js within a .js has to be done outside of the language ... and that is just the tip of the iceberg last time I checked.
Lol, nice. I was going to say "Learn Haskell", but I figured I'd be downvoted into oblivion. In all seriousness I am actually using that strategy and so far it seems to be working well.
Well I mentionned Dart because it is a very small step up to learn when you know Javascript. Not sure the same can be said of JS -> Haskell ... don't get me wrong I started looking into Haskell and I find it fascinating!
By all means - it's not actually mine though. It's a derivative of "God can draw a straight line with a crooked stick." It's generally attributed to Martin Luther, though I didn't really know until I looked it up just now :)
How to become great at Sports: - Read books about sports. - Watch other people play sports. - Read in-depth analysis of past sports games.
How to become great at Playing Violin: - Read books about playing violin. - Real sheet music by the great masters. - Listen to many concerts.
It's inherently obvious that the above approaches are totally and completely wrong. How do you become good at anything? You practice it. You do it. You have a coach or teacher or mentor who can give you pointers, but lets you make mistakes. You have someone who lets you get things wrong the first time, so that you can see the consequences.
There is a time and place for theory, for reading, for analysis, and this is too part of the learning process, but this is not at all the most important tool for becoming great at something.
Theory, analysis, critique, history, and context all matter when learning any skill, but first, you must build the fundamentals. First, you must do the thing and once you reach a level where you really understand the thing, then and only then can you begin the more introspective task of theory and analysis. Even without these steps, the best way of becoming great is to DO.