I'm currently reading "JavaScript: The Definitive Guide" and it's a mighty long book because it basically covers EVERYTHING related to JavaScript. This has got me wondering: Am I wasting my time by learning the granular parts of the JavaScript language?
For example, JavaScript has this concept of a positive zero (0) and a negative zero (-0). Both values are equal in JavaScript, except when used with a divisor:
var positiveZero = 0;
var negativeZero = -0;
positiveZero === negativeZero; // => true
1/postiveZero === 1/negativeZero; // => false
Let's be real, what are the odds of me remember such odd behaviour and what are the odds of that ever being useful while working with JavaScript?
What do people think? It's it worth spending time learning such obscure parts of the language. If not, is it worth reading books that go into the real deep parts of a language?
Top comments (33)
So the hard answer is: it depends.
It depends on where you are with your current knowledge of JavaScript. It depends on where your interests are. It depends on how much you see yourself developing in JavaScript versus other languages. It depends on how much time and energy you can afford. It depends on your motivation - are you trying to get up to speed on JavaScript orare you looking to get a deeper understanding having worked with it for a while?
What you'll find is having deeper knowledge of the language gives you the ability to quickly dig in to understanding problems that others without that knowledge can only attack on a surface level without spending time doing their own research. Even if you don't remember all of the details that you read, you'll often remember the general structure enough that it will pay off down the line if you find yourself working with JavaScript heavily.
You will also often find along the way that you learn little things that are helpful as you develop - things that you might not have been aware that you could do.
I will say that I've been programming for a very long time and I never have regretted learning stuff like this even if I don't use it. Learning is a crucial skill in and of itself and one that you will need to make use of throughout your programming career, and keeping that skill practiced keeps you sharp and able to pick up new material. So, even if you may never use some of the things you learned, your work in reading this book will pay off, helping keep you sharp and ready to pick up the next thing you learn.
Amazing response! I work React everyday at my job and I find myself not truly understanding what’s going on in the code around certain things like classes, promises, observables, etc. This makes things quite difficult to work with at times, so that is my motivation for trying to learn the core parts of the language for myself.
Thanks for your reply, it’s given me confidence that I’ve likely taken the right approach.
I'm in a similar boat, trying to eat up as much JS as a I can because I love working with front end, but often find myself floundering because I don't understand what's going on in the background. I'm learning from the beginning, but I've already been able to solve a lot of problems that I was stumped by before.
Hi all, in learning a new programing language I generally follow these steps:
It is good to have an understanding of how the language works. This includes the features of a language and their use cases and a decent understanding of the internals of the language so that your code can be efficient. I am not sure it is really important to know the far corner case oddities of a language. In ~4 years of using javascript I have never once encountered a situation where an oddity like the one you present or the famous .1 * .2 bug had any impact in my code or anyone I have worked with.
Well put!
I'd argue that it's important to be aware of them. Or learn these details as you encounter them (and don't forget them). I remember I had a chart at work that wasn't displaying correctly. Turns out there was a divide by 0 returning
Infinity. Easy fix, right? Until you find out that it's still broken because -0 results in-Infinity. One of those "oh right!" moments that you don't forget.Haha, love the example of a problem you've faced with one of these rarely encountered parts of the JS language.
Absolute waste of time. Theoretical knowledge that 99,9995% sure will no be translated into real working code is pure philosophy. One can load his car with all the necessary to survive a month in the desert "just in case", or be pragmatic and just carry some water, a blanket and a cell phone. Is not about covering 100% (impossible amount of time), it's about covering 90% and knowing how to proceed if the 10% happens.
I was an expert at VB6 back in the late 90's before .NET arrived. I knew almost all of the nuances of that language. What good does that do me now? Well, some, since I have to work with legacy code from time to time but I wouldn't want to have a job where that's all I do (and I've been offered some like that).
The problem is that technology changes and it is changing even quicker today. It makes it impractical to learn everything because you will find yourself falling behind the curve. Core language elements and well known nuances and quirks should be your focus. Language trivia is usually only good for job interviews.
What is important is knowing how to find the answer to an obscure language question. Usually you can find an answer on Stack Overflow or GitHub and, if those fail, there are a lot of other sites to look at.
Obviously probably you are in this field even before I was born, so the experience might be telling you something else.
Do you learn/read a book, learn a language that will help you 28 years later using same rules? You don't.
Surely the knowledge you picked up helped you in lot of cases when the new syntax arrived, people asked you to help them rebuild the old stuff using the new shiny system.
One good example would be Crypto bubble, it was short lived, few developers actually got inside of it. However who had deep knowledge in other languages like (C, C++ or even JS) had easiest time absorbing solidity. Whoever didn't spend much time on it had a harder time.
I think the target matters, if one spends time on one specific language and studies bits and part of that to the core, then he will have such knowledge that will help learn new things faster or do unique stuff even better.
I know JS to certain extent, however because I did not study it deeply, I don't even know how to make a crypto miner in JavaScript, or understand completely how he made such a 3D game in 96Kb in C++ (its called .kkrieger, made by .theprodukkt, and they have the code open sourced).
Here's what I've seen, people getting caught up in learning the "flavor of the week" language and becoming really good at it. But, then, it goes out of favor and they're stuck with a lot of outdated knowledge. It can be difficult to get away from those languages when looking for a job as well since potential employers think that's all you know and won't consider you and those who will hire you need you to maintain an ailing legacy system.
I do think having a strong foundation in a C based language (C++, Java, C#, etc.) is something that will hold up over time vs. more proprietary languages and frameworks. One of the best decisions I made early on in my career was learning C. I doubt I would still be programming today if I had chosen a different language to learn.
If you want to be an expert in the language yes, you should be able to explain any piece of code, and how does behave at runtime or compiled to.
But most devs do not want to be experts so .. theres that.
IMO, most people likely don't want to be experts because there is a point of diminishing returns after you've acquired a certain proficiency with a language.
An excellent well-wrapped point. Ground your skillset proficiencies based on the truth that software adapts and will always adapt.
That is one reason, there many and all good ones, I did not implied that they should strive to become an expert.
We should have experts to push the boundries further, but just a few is enough
The value of knowledge is extremely subjective, especially in the software field. When spending time on the development of technical competence the question is always whether to go broad or deep. The answer depends on what you have to do and what you plan to do. If you are a JavaScript specialist and you spend 80% or more of your time working with JavaScript, it's probably good to know the obscure parts. If you do work on a framework like react or angular, then knowledge of the languages nuances and quirks is essential. But if you primary work in another language and only use JavaScript for front end work, or you are an entrepreneur and you also must do your marketing, customer support and product development then knowing this sort of information is only a distraction from your goals. Think about where you want to be vs where you are and it will be much easier to decide the value of that knowledge.
I think the question is will the time spent reading this book increase my productivity (or perceived productivity, if that is what you're after) more than the time it took to read the book. There are definitely books that will make you more productive. I believe this because I've read hooks which have helped me a lot. A lot can be learned from Stack overflow but sometimes a book is needed to explain a topic in depth. I think this was the case for me with learning about how to write thread safe code, where Java Concurrency in Practice helped. I do not know many JavaScript books but I'm sure they exist. On the other hand some books you may not learn much from or will take longer to read than you'll get back in productivity.
TL;DR: Try a couple of books in parallel, focusing on different levels of detail/practicality. Or, something like Javascript Patterns by Stoyan Stefano might give you a better mix of detail and practical examples to begin with than the definitive guide. It's shorter, too! :)
I don't think there is a right or wrong answer here, but generally a deep understanding of a language is a good goal. What I aim for when learning something technical is to maximise the number of "aha" moments per hour. But how you do this will depend on your personal learning style.
Some people like to delve into detailed documentation to understand a language's specification. If you have a strong background in computer science, or if you have learned many languages previously, this is probably ok, but not necessarily the quickest way (but could be for you).
Others prefer to start with high-level examples and working apps that give you a flavour of what you will be doing to get the job done. After that, going deeper, with more detailed explanations until finally you get to a point where you're learning the reasons why you need to do things a certain way.
Personally, I like to mix it up a little, alternating between levels and having two books on the go at once. I find it useful to have the different point of view on hand and it just keeps my interest up.
Ultimately the best thing you can do is experiment and see what suits you.