My "real" advice for impatient programmers: just start programming, and every time you encounter a problem google it.
Don't know how to setup node.js? Google should lead you to `npm init` or a starter. Getting some weird syntax error? Google it. Once you learn the basics, want to do X? Google it and determine a) how to do X, or b) if X can't be done / is bad practice.
Just by diving head-first into whatever you're trying to accomplish (or a toy project if you just want to learn), eventually you'll start to get the hand of syntax, libraries, and general programming style. But read articles every once in a while on best practices so you aren't learning the "wrong" way to do things.
The big drawback is that there are a lot of Google results that are outdated, novice, or flat-out wrong. You have to really learn how to do research on the internet. But this is a skill you should learn because you can apply it to anything. My general advice: consult official docs whenever possible; Stack Overflow is reliable but check the answer's comments to see if it's outdated; use Reddit to compare X vs. Y; try to avoid long wordy articles on bloated sites, generally the better the writer = the better the article and more likely it's accurate.
You cannot just google your way through it. There are times when you don't even know what to google. I remember as an early beginner being stuck with something that had to do with closures. I had no idea what was going on and didn't know what to google and when I asked questions on stackoverflow and reddit please started saying things about decorators and whatnot!!! It is only when I sat down and went through some kinds of structured tutorials that I knew what had stomped me. Sometimes, you ight just have to be aware of some problems even if you'd don't understand them properly but you are aware of their existence and what they are called.
I’m the complete opposite; I’ve yet to encounter a problem I couldn’t Google or bug someone in IRC about (and that’s the key).
Sometimes you have to engage with someone else to solve a problem, but there are hundreds of people willing to do just that at literally any given time of day.
Yes, as a last resort, googling simply the error or part of error gets one on the way to solution. Very rarely I had to face a search term which doesn't point or advance me towards solution.
For context, I use javascript & basic html css to make simple apps for my own use. apps.bydav.in
Usually I just take a quick glance at, and/or try of the main features of a language in some REPL or toy program, _then_ will jump straight to developing something to it and Google/DDG my way through. I do agree that just Googling your way through without having a basic grasp of the general philosophy and main tools a language puts at your disposal can be counterproductive.
If you're new to programming, yeah. If you're an experienced programmer, and you've used multiple languages, you're more likely to just write something that's not idiomatic than to get totally lost like that.
One "patience" problem I have is that problems are usually much more complex than they appear. Node is giving you some random dependency error? It's because you need to install X. But to install X you need to install Y. But to install Y you need to install Z. But Z requires some specific node version. But that specific node version will break A, and to not break A you need to install B which requires you to disable your Mac's SIP so that it can work with X. If I sniff that I problem will lead me to a hole like this I get so annoyed that I start avoiding that specific platform as much as I can.
Software is so fragmented nowadays that even setting up something simple requires you to handle tons of difference pieces for no good reason. Monopoly aside, this is one reason I like Apple having full control of iOS development.
Yes, node.js and JavaScript transpile issues in particular are super annoying. But idk if any book would help you with this either.
I recently discovered Vite (with pnpm) and so far I haven't had any annoying JS/npm/engine issues, so that would be my recommendation. Generally to setup something I either a) run `<build-tool> init`, b) "create new project" in IntelliJ, or c) clone a medium-sized project on GitHub, then remove the code and leave the configuration files.
I spent the last week doing exactly this after going over a decade without making a web page and having never done anything java related. The key thing for me was finding an existing website i liked that was hosted on github pages and used that as a template/example to see how things fit together. The learning curve at the very beginning was brutal, but once you get a few toeholds and can iterate things quickly start falling into place. The problem with the textbook approach is you don't know what you can skip until you already know it.
Most stuff getting slung around, as the parent mentions, is rooted in the kind of development that relies on NPM-adjacent tooling. The two things you mention (Java and modern Web development, especially something modelled after another thing found on GitHub Pages) tend to be miles apart in this decade. Where does Java come in to it?
He may mean JavaScript not Java. I get a lot of we newbies asking referring to Java when they mean JavaScript. Especially when in the context of web development.
For the parent: Java is completely different to JavaScript - the similarity is an accident of marketing and an original vision of the Web (in which most code was written in Java not JavaScript.)
The problem with this is that sometimes a good tutorial gives you insight on how they do things in the language/framework way.
If I pick up something new and just try to piece things together using a sample project or whatever, I tend to think in ways from the most familiar language I work in.
Also without familiarity, you can’t judge if the sample you picked is super opinionated or does things in a weird way.
I always found this way too clumsy, because you learn X but accidentally miss Y, and X becomes your tool of choice at places where it doesn’t really fits best or at all.
Javascript traditionally had NO good language guides, and this one looks pretty like the one you should read in advance. Other resources are either more library reference-like, very situative or for unclear standard, not exhaustive, or just stupid and wrong. I’ve read a language guide A to Z for every PL I used in my life (a bunch), and can say by skimming through few rough/key topics that it is definitely a good one. No offense, but my advice is to not apply your advice when there is a good guide. You’ll save both your own time and the one’s who will come after.
yes, there are a lot of half baked guides and blog posts out there about JS. there are a couple which are really good:
https://javascript.info/ - explains good ES6 practices
https://github.com/getify/You-Dont-Know-JS which goes in depth in the messy core of the language.
nowadays I usually refer to MDN docs and one of the guides like above when guidance is needed.
For beginners, this is the last book to start with. I'm a big fan of Doug Crockford, but this book is opinionated and the examples are often not well explained.
> "My "real" advice for impatient programmers: just start programming, and every time you encounter a problem google it."
In my experience, this is a terrible advice. However, many of my students follow this advice over my protests and only a handful of them actually learn anything at the end of a long masters program.
I agree. But over the years I've come to understand there are two kinds of learners;
a) "I learn what I need to accomplish this task". This is observed as question/answer and only the simplest version of the answer is needed. So something like "how do I create a variable x and assign 10 into it. All he's looking for is
x = 10
b) The second kind wants to understand the nuance of what's happening, so they can apply that nuance to future code. They are looking for an answer, but the are interested in the working that leads to the answer. So in the above example they want
x = 10
var x = 10
let x = 10
options{x:10}
and so on. They digest when to use one and when to use another, and they delight in using the correct form in the correct place.
In my experience (a) programmers will get through tasks quickly, but with shallow understanding. They will eventually have all the tools, but lack the ability to see the big picture. They struggle to read other people's code.
On the other hand (b) programmers learn much more slowly, they take a lot of time to accomplish tasks because they are being distracted by their curiosity. But after that investment they easily outstrip their peers in productivity, and more importantly can do things that an (a) type programmer can never do.
What I've come to accept though is that giving a (b) answer to an (a) questioner just leaves them confused. They asked about assignment, and a discussion of scope just leaves them befuddled (since they don't know what scope is anyway). Which can be frustrating to the answerer who is a type (b).
Type (a) should not be doing a Masters program in the first place, so I feel your pain in that regard. Google is great when you're out in the world, but it's a terrible way to "big picture" learn.
Great explanation! I wish I could influence the student intake but as a faculty I find it difficult to negotiate with the administrators whose objective function is to maximize the program enrollment! So I have accepted the status quo. Nonetheless I show them how I would solve a specific problem without going to Google at all.
Alas most post-graduate programs are under subscribed, and it is important for reasons of prestige etc to maximize enrollment. There is no point in trying to convince others to reduce numbers - those are the very metrics _they_ are judged by.
I've [1] adopted the approach of meeting the student where they are answering their question, then trying to take them one step further. I try to encourage good habits, and at the same time ceasely mock bad habits (in a gentle, running-joke, kind of way.)
That said I also demonstrate the use of Google in answering a bunch of questions, for which the internet is overflowing with answers. Google is a fantastic resource and there's a lot of great stuff out there.
[1] I am not an academic, and my "students" are not in school. They are typically professionals, trained in another discipline, who were around when computers started, and there was no software so they had to write their own. They have 40 odd years of programming experience, but usually with zero formal training. Seeing individuals in this age-group make breakthroughs though is immensely rewarding.
Which is better than thinking you know what you don't know.
The most important thing impatient programmers need to learn is TO NOT BE IMPATIENT, not how to learn a programming language in X minutes.
Learning patience will help you in all aspects of life.
Do you really want to share the road with somebody who learned to drive in 5 minutes, and doesn't have the patience not to speed, tailgate, run stop signs, red lights, and pass you on the right by driving on the sidewalk?
More "real" advice: Read LOTS of other people's code.
Need to use a library? Then first read the documentation, then read the source code, so you actually understand what it can do, how it does it, that it's not magic, what its limitations are, how to use it, and if you actually need it.
I've been working on learning and reading the D3 data visualization library for several years, bit by bit. It's a wonderful library, there's a whole lot to it, the code is brilliant and expertly written, and I've learned a LOT about JavaScript programming in general by reading different parts of it again and again.
>In honor of D3 1.0’s tin anniversary, I thought I’d reflect on lessons learned. This isn’t intended to be too comprehensive or serious — just a handful of observations as I look ahead to the next ten years. But I hope a nugget or two will interest you, too.
> Need to use a library? Then first read the documentation, then read the source code, so you actually understand what it can do, how it does it, that it's not magic, what its limitations are, how to use it, and if you actually need it.
That's the opposite of thread OP's advice. If you need to use a library and you're impatient, find the closest example to what you want to do and then hack away at it until it does what you want.
It's an elaboration of his advice, not the opposite. Please be patient enough to read all of the OP's advice:
>But read articles every once in a while on best practices so you aren't learning the "wrong" way to do things.
>The big drawback is that there are a lot of Google results that are outdated, novice, or flat-out wrong.
>My general advice: consult official docs whenever possible
After you read the official docs, and decide you actually want to use a library for something that's not trivial, one-off, or throw-away, it will benefit you to actually read the source code itself, which is by definition not out-of-date and incomplete, like so many of the articles about the library you can find by googling and reading stack overflow.
In my book, hacking away at using a library until it does what you want involves reading the source code in the developer tools by setting breakpoints and browsing the call stack, function definitions, local variables, and data structures, while the code is alive and running.
Once you've done that, it's a lot more interesting and easier to then read the entire source code on github front to back, to learn the library well, because you will have a lot more context about how it's actually used and fits together, its dynamic runtime behavior, and the shape and texture of its objects and data structures.
Agreed, this is how you end up with people hard-coding hundreds of iterations because they don't know what arrays or loops are. I think it's better to learn top-down and bottom-up simultaneously, by building your own projects as well as taking a more structured fundamentals course.
And the most important advice, in my opinion, is to expect to write a LOT of garbage code that you replace almost immediately. It’s not like pouring concrete. You’re not wasting your time or code. It’s a learning process and once you’ve written it, you’ve absorbed all the good and bad lessons from it.
I struggled a lot with paralysis where I refused to even begin a project until I could see the “right way” to get to the finish line. But now I just do a tiny little bit of design (for toys and personal projects) and then dive in.
There’s no better way to deeply understand why a certain concept is important than doing it wrong and suffering the consequences.
I think this strategy works for just about every language but Javascript. Last week I was trying to learn JS with this method and it sucked, almost exclusively because there is so much content to sift through that it's difficult to separate the wheat from the chaff. Reading the documentation, while not particularly glorious, is the most time-efficient method of learning a language in my experience.
How much time would you say is fast enough to build a full front end and back end login/authentication system in nodeJS with any db ?
I mean including throttling, pwd reset, forgot email/pwd, 2fa, confirmation email etc?
Most of the tutorials are notoriously outdated and won't work bc dependencies, but I have build one such app.
It depends on what exactly your app is because you might be able to use existing solutions.
But my recommendation is Firebase or Supabase. These tools were basically designed for this type of webapp. I know a team of junior devs who created a production-app in a few weeks with Firebase. Firebase handles authentication, the database REST endpoint, and various other common webapp functionality, so that stuff is seriously achievable in hours. In Supabase "signup", "login", "login with provider", "send reset email" are all single JS functions.
I'm the type that likes to learn from some real, existing codebase. This is frustrating in the JS space, as you would have to have the right version of a bunch of stuff to do that, and how to use it. Libraries, packers, packagers, frameworks, minifiers, and so on.
Other languages have some of that sprawl, but none quite to the same level, and none with the same pace of change.
If you learn like me, my advice would be to have a list of potential candidate projects to learn from and move on to the next one when the tool and dependency hell proves too much.
Was not my experience. The system npm was either too new or too old for the codebase I picked (can't remember). So uninstalled, installed a different one, then some unfixable issue with something called fsevents, other issues regarding "peer dependencies", etc. Similar issues with the second one I tried.
The third project I went with went much better, though it was still difficult to learn things (even if they are working) as every project seems to choose different build/deploy tools.
Sometimes I forget about npm v7-8 (the latest versions). They're "backwards compatible" if you consider "breaks everything" a form of backwards compatibility.
So maybe you're right. Perhaps everything is terrible everywhere.
I like Google, or better Stack overflow, when you’re at your desk writing code. Books (preferably paper books), to browse in free moments when not working.
I used to keep a paper copy of “JavaScript pocket reference” on me, and pull it out on the train, or just sitting around at night, to help get the concepts.
I'd also add my own 2 cents: if you're Googling stuff related to syntax then make MDN your first stop; or you might consider one of MDN's many entry points to learning JS. Also check out prominent Discords/Slacks/etc because it's nice to have human help when you're blocked, and sometimes you need opinions rather than facts.
Googling how to install nodejs you'll end up with a bunch of nonsense from how to manually set it up to how to do it using some OS specific thing that won't work right when you need to upgrade and everything in between when the best practice is installing 'n' which is a node version manager and does everything for you.
When I onboard new hires I tell them to install it using n and all the instructions give you version numbers because our mobile app, unit tests, and webpack among other things have minimums so the pain is readily apparent but I make it a non issue with clear and concise install docs.
I will say I’ve read this book all the way through one and a half times, at which point I decided it wasn’t a good book. I’m an experienced programmer new to JavaScript, so the target market for this book. It is terrible for reading from start to end, and has lot of details and obsolete language features I just didn’t care about.
I looked around a bit and found the perfect book for me: Modern JavaScript for the Impatient by Cay S Horstmann. A terrific way to learn JavaScript.
Thanks for Your extensive review on Amazon `This is an exceptionally good book. If you know how to program in some other language, and want to pick up JavaScript, then this is your book. It did an excellent job of explaining everything in a logical order, telling a good story. Read through the 300 or so pages from start to finish and you'll be set to move on the JS web framework of your choice. (The recently updated JavaScript: the Definitive Guide seems the other alternative, but it is 665 pages to wade through.)
I especially liked how the author came up with 5 golden rules to follow right up front, such as "avoid automatic type conversion". JavaScript has so many crufty historical flaws, and by following these rules, he doesn't have to explain all the weird historical stuff. That cut out a lot of laborious explanation of things you shouldn't do anyway.
The examples were very well chosen. They focused on the important stuff, yet still explained the key gotcha's inherent in the language. Every paragraph seemed to have an important point.
It is a shame this is only the 85th most popular JavaScript book (as of now). It deserves to be better known. It is a classic, and perhaps the best computer book I've read since "The Go Programming Language".
Highly recommended.`. Will add this to my read-list after I complete WatchAndCode
I really don't understand why people hate JS so much. I myself a primarily a JS dev, and now a TS dev. TS made the experience so much so much better. JS is like pretty much a programming language for average software engineer like me. Sure, JS build system is a pain. I am the go to build system guy for almost every company I've been with, I worked with Grunt, Gulp, Webpack 1,2,3,4 and etc and yes I hate it, but other than that it works really well. If you don't touch frontend you can pretty much forget build system entirely. npm init is so easy.
Async is easy as well. I really don't understand the hate, what am I missing? Maybe I'm too dumb for other programming languages. I did try various languages from Java, Elixir, Haskell, Rust, Go, Ruby, Python and JS is simply the best in productivity, expressiveness, ease of use and performance balance.
As long as you don't code in a clusterfuck way, it is so easy to write JS and compose JS functions. Just use functions everywhere, no need class. JS is very readable.
Like, seriously, Python has Python2 vs Python3 package and build/deployment problem. Haskell is difficult and the tooling is abysmal. Rust is difficult and too much choices to just write this and that. Ruby has no tpe system and slower than JS. Python is also slower, no good async, and its type system is not expressive as TS. Go's type system isn't expressive enough. Java type system is too much and JVM is complicated. Scala is complicated.
JS/TS is:
- simple/easy to use
- pays the bills (you can go anywhere and find jobs as JS/TS dev in almost every company in the world)
- everywhere, like from IoT to robotics to game development to server to frontend to regular scripts
- easy programming language to do Leetcode style interview as well
- if you wanna do Option/Maybe style error handling like Haskell/Rust/Go you can do that with TS, just wrap try catch and return the error with neverthrow library. This makes TS programming bliss!!! I freaking love it
If you don't want to care about setting up NodeJS + TS, now you have Deno, who's pretty much out of the box everything just works.
JS/TS is such a super boring language it feels like cheating your way out of software engineering. It is a language made for dumb people like me, maybe that's why it has no appeal for hardcore programmers.
I owe to JS/TS on changing my life and giving me a good living.
I believe the JS criticism is more about the culture and ecosystem than the language itself. In short: Most if not all JS devs are more interested in playing with specific tools and APIs rather than dealing with and/or implementing programming patterns and principles. In the last decade "small modules" skyrocketed the popularity of NPM and a lot of people pushed the idea of "don't reinvent the wheel just 'npm install' everything" and sadly it stuck. Basically all JS-related discourse reduces down to "use X instead of Y!". It started with packages, then libraries, then frameworks, and now meta-frameworks – hell even meta-meta-frameworks if you count the people raving about Blitz. It's like that period when young devs couldn't tell the difference between jQuery and JS but way worse. So yes, in a way you are in fact cheating your way out of software engineering by installing neverthrow or whatever. I mean the language is already pretty damn high-level already.
I think a lot of JS haters haven’t spent much time with modern JS. That’s how it was for me, at least. I would laugh at JS wat-isms and think back to the old days of jQuery spaghetti. Python was my favorite language.
Now I’m a full time JS/TS developer and I love the language. It’s a dream to use. The syntax is concise and logical, the ecosystem is vibrant, and the barrier to entry is low. I wish there was more JS in the scientific, CV, and ML spaces — Python is still superior here, imo — but otherwise JS is my go to. It’s no wonder we see the rise of Electron apps - the developer experience is just so much better.
Right, you need some historical context to understand the situation. 10 years ago JS was a shitty language with a far worse ecosystem. It deserved the hate it got. Then ES6 came along 6 years ago or so and added tons of super valuable language features. Suddenly you don't have to deal with the hoisting semantics of var or worrying about what 'this' is all the time. It was so nice that people started using Babel to use the new features ASAP. Then a couple years later, once everyone has a transpiler in their build process without a second thought (this used to be controversial!), TypeScript comes along and provides another huge leap in how pleasant the language is to use.
Now it's a pretty nice ecosystem, but it used to be pretty bad. Not everyone's biases have caught up yet.
I don’t like JS and try to avoid it wherever possible. I have written some, but I’m not an expert by any means.
My problems with JS/TS:
Simple to start, but hard to program robustly and defensively. Due to the lack of typing, a lot of the codebases I’ve seen end up with extensive input validation code, which often uses fancy tricks that are hard to parse (unless you already know them). Typescript helps with this, but it is not the same as a proper type system because it is optional. Usually I run into runtime problems due to type errors with library code which doesn’t have types (or has the wrong ones).
The core language is filled with weird edge cases in coercion. jsfuck.com and https://www.destroyallsoftware.com/talks/wat are examples. This doesn’t affect my day-to-day code, but it’s equivalent to C undefined behaviour for me. A bunch of hidden rules that I don’t really want to extensively learn and understand, but which will bite me when writing anything moderately complex. ‘===‘ is good, but I think it’s really easy to miss the extra equals, especially if you write code in other languages a lot.
Lack of standard library (in Nodejs). For quick things, I find Python a lot better. The scant JS standard library has been widely criticised. This is a contributing factor to the absolute explosion in the dependency graph whenever you start pulling in a lot of the common dependencies. IMO, Go and Rust both do a better job despite having comparably easy package mangers.
Although some JS code is easy to read, I’ve seen lots of examples of overuse of functional indirection. Maybe it’s something I will start recognising the patterns once I’ve come across them more, I end up ragequitting JS codebases much more often than other languages. Despite its flaws, Go in a good editor is an absolute joy to understand new codebases.
I’ve found a combination of Python, Go and Rust to be the ideal combination. Each has its flaws, but for any specific use case, I can pick one I’d rather use than JS.
Like most languages, JavaScript has some landmines in it. The problem with JS as compared to other languages is that these landmines are plentiful in basic, frequently used operations, so it's easy to encounter all kinds of mysterious errors. If you know how to avoid them, you can mostly use it like a sane language and have a good experience. Hence "JavaScript: The Good Parts". Other languages don't really have a book like that.
A few of them are really hard to avoid, though, like the fact that JS has both "null" and "undefined", and these two values are sometimes treated as the same and sometimes treated as different.
Yeah I’ve seen really bad functional closures over the course of my career as well. But this just shows more of the developers’ skill than the language.
Btw it sounds like you might like Deno. Have you given it a try?
I guess that’s part of it. I don’t think the technique is necessarily a problem by itself, because it is often very easily traceable. However, it is annoying if the things being composed are not standard well-known functions, but user-defined ones.
Somewhere this file defines an exported function called `icon`, but it took me way too long to find where and even longer to see what it was actually doing.
This might not be idiomatic JS code, but I’ve definitely seen other popular packages have similar code (especially internally).
I have done JS for several years and TS more recently. I think TS really fixes a lot of the issues that arise while building large systems in NodejS. But I think people are right to hate on the dependency nightmare that is npm. I could complain about several other things but really they apply to most popular dynamic languages...
It's a great question. JS is single threaded (modulo web workers), which eliminates an entire class of race conditions: data races. That means mutices kan be skipped and channels can be replaced with a reqular fifo queue.
Async doesn't change any of this, and is mostly syntax sugar for callbacks. However, there are of course logical race conditions so when you use async you must be aware that the entire world can have changed after an await.
I like async. It's is easy to reason about. In what paradigm are race conditions avoided completely? I know Rust avoids "Data Races" but not race conditions as far as I'm aware.
Interestingly Ruby was my first programming language but it was JS who made programming clicked for me. I think it is the curly braces. It helped my mind compartmentalize stuffs.
That's a great resource, but not a miracle cure for ignorance or magic pill for knowledge and skill.
If you're actually serious about learning to program, then it's going to take more than a few minutes of your life to learn.
But if you can't stomach investing more than a few minutes in learning to program in JavaScript or any other programming language, then you should really find something else do to with your extremely limited time.
Teach Yourself Programming in Ten Years, by Peter Norvig:
The last time I posted a link to this important essay, impatient people who weren't very serious about investing any time in learning or reading simply and immediately responded to the title, but didn't bother to actually follow the link or read and respond to any of Peter Norvig's brilliant essay (and probably didn't even know who he was), so here is an excerpt.
>Researchers (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, telegraph operation, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music. In another genre, the Beatles seemed to burst onto the scene with a string of #1 hits and an appearance on the Ed Sullivan show in 1964. But they had been playing small clubs in Liverpool and Hamburg since 1957, and while they had mass appeal early on, their first great critical success, Sgt. Peppers, was released in 1967.
This essay is a classic that's been discussed on HN numerous times:
This essay, which has helped fixing my initial mindset a lot, is directed for complete beginners.
The website OP mentions is for someone who already knows how to program well in one or more language and want to take a quick look at another language syntax.
Titles like "Learn X in Y minutes" fool impatient people who don't take the time to follow links or read more than titles into believing the incorrect notion that it's possible to do what the title promises. They never get around to reading the actual articles or disclaimers that it actually takes a long time and a lot of practice to become proficient or even competent in a programming language.
Then they think they can learn programming languages by reading Twitter instead of writing code, and claim on their resumes they know languages they've only read a few blog posts about.
Those are the same people who complain that they hate Lisp by parroting tweets that it has "too many parenthesis", even though other languages have much more complex syntax, much less powerful and more limited and difficult to use macros and meta-programming facilities (like C macros and C++ templates), that force you to use an ugly mish-mash of even more inconsistent punctuation line noise like brackets, braces, escapes, quotes, backquotes, obscure operator precedence and ad-hoc parsing rules, and a myriad of other hard-to-learn punctuation that makes the code much less readable than Lisp, without realizing that there is actually a point to Lisp's clean simple parenthetical syntax.
There's also a long sad history of impatient people not wanting to bother learning JavaScript, but believing that they can simply learn JQuery or React or some other popular "silver bullet" library instead:
Can you get away with learning jQuery only instead of JavaScript?
My biggest hurdle with JavaScript was getting things to happen in order. Functions can be unexpectedly colorful[0] and contortions and boilerplate is needed to deal with that. What was unintuitive to me was a lot of interactions with the DOM are asynchronous without being explicit about it. So you've got to chain a bunch of asynchronous calls together to make sure a sequence of events occur. Most other languages make this sort of asynchronous callback hell explicit.
Once you understand this aspect of the language it's an annoying (to me) idiosyncrasy but manageable. Before you understand it there's a lot of pouring over poorly written tutorials that gloss over it like it should be obvious.
After a year or so writing "async" code it has become natural. I now think of the real world as async. For example during Christmas I do not "poll" the door every 10 minute to see Santa clause. I simply wait until he knocks on the door and then I run the knockOnDoor callback function.
So in my mind functions did not have colors. They where "first class functions" that you could pass into another function that later called it.
Now however we do have normal functions (before ES6-7), as well as async/await promise returning functions, and *function yealding generator functions.
Creating a new element on the DOM, especially when it is creating a new script element. It takes non-zero time to load and parse but returns control to JavaScript immediately. So you need to wait on the element with like onLoad before calling a function in that script. There's some more instances I've forgotten.
The situation is better now with promises but it was a pain in the ass just a few years ago.
Well, yeah, some DOM elements have async side effect, but they are still added to the DOM synchronously. Creating the element and loading it's content are two completely separate things.
That's non-obvious to people from other languages, at least it was to me. The asynchronous nature of DOM manipulation also comes up when the DOM gets large and you naively try updating elements querying by tag or class.
It's idiosyncrasies aren't deal breakers but they're non-obvious. They also crop up once you're into medium complexity code. At the level of simple/trivial code machines and JavaScript engines are fast enough to paper over naively written code. But you get to a certain level of complexity and you get bit by some colored function issue or something.
It's annoying bringing something up where JavaScript is not the primary focus of the project. This is all anecdotal, there's plenty of people that might never have issues. But it was all stuff that tripped me up around 2009-10 having to write some JS after not having touched it since before you could make XHRs or manipulate the DOM directly.
Very nice and comprehensive resource. I don't consider myself impatient but appreciate the high information density and the ability to quickly skip past the parts that I already know and actually learned a few new things.
Agreed. This looks like something I will be coming back to. Rules of thumb, recommendations, and reasons for their recommendations -- I'm in heaven. Too few resources hit the sweet spot between introduction and arcana.
HN: Is today's hectic javascript making you tense and impatient?
Me: Shut up and get to the point!
Yeah, it's a futurama quote
On topic: This is quite a list so I just clicked a random link and voila:
> 7.1.1.3 Assertions
> An assertion describes what the result of a computation is expected to look like and throws an exception if those expectations aren’t correct. For example, the following assertion states that the result of the computation 7 plus 1 must be 8:
> ...
> assert.equal(7 + 1, 8);
> There is also assert.deepEqual() that compares objects deeply.
What? Am I going crazy? Have my years of wild hedonism finally caught up with me? I don't see jest mentioned but fired up my browser's console and sure enough, there is no "assert" in my window. What am I missing here?
I got my start in programming in the early 2000s with Perl and, shortly after, PHP. I went through school mainly with C++ and Java and got a job as a .NET developer after.
I say all this because I fucking hated JavaScript with a passion. From the time of my initial foray into programming until my later years, I hated it. It was always a joke of a language that, honestly, caused me to develop such a bias that I nearly refused to use it, for a very long time.
Several months ago I decided to put my prejudices aside and began playing around with Nodejs and React. The main motivation was trying to learn more about front end development and guess what? I really enjoy JavaScript.
JavaScript is a very enjoyable language to play with. It has come such a long way despite, literally, all odds. The ecosystem is scattered. The build system is the most hacky monstrosity you’ve ever encountered. But, that’s one of the reasons I love it. It feels like the essence of what I feel when I imagine hacking.
And not only that, it uses a unique (at least to the paradigms I’m used to) execution model that is very performant.
These are just a lot of words for me to say I love JavaScript.
I dunno… I started around the same time as you, also with PHP. I posted this comment[0] the other day where I tried to put into words how much I hate JavaScript and, judging from the reactions I got, it seems the community is pretty split on this one.
my background is similar to yours. I still hate JavaScript somewhat. But I can tolerate it a bit more than I could 10 years ago. Possibly because of advancements in development environments and tools.
What I like about JS is I can write nearly everything with const.
Functions are const, data is const, and I rarely use classes. It removes a lot of overhead, avoids this questions, and makes everything consistent and so makes spotting similarities and differences easier.
I can do
const myFunc = () => 2;
const res = myFunc();
It helps with the mindset of treating functions as data that can be acted upon similar to how data can be.
Yes, but it’s with the caveat that (like C++) const does not mean that the whole value is constant. It doesn’t even really mean any part of the value is constant necessarily, just that the symbol cannot be reassigned.
I don’t know that it eliminates that many questions, but it does eliminate one question, which is whether that variable will be reassigned. Arguably that doesn’t tell you very much.
In regards to global references, this guide suggests not to use the window prefix but doesn't really explain why except to note that it's unnecessary. I am guessing this is because window is not available if the js is running outside the browser. But if the code is intended to be run in the browser and won't work elsewhere I prefer adding the prefix to signal that.
For people who have taken the time to read it, or taken enough time to evaluate it: is there really anything in this book that would appeal to "impatient programmers"? From what I've looked at, it seems to be a fairly typical programming book, and I fear the title might be deceptive.
From what I gather it has a good table of contents from which you can jump to the section you’re intetested and ignore the rest. That’s good for an inpatient dev who needs to learn what they need at the moment of the inquiry.
Don't know how to setup node.js? Google should lead you to `npm init` or a starter. Getting some weird syntax error? Google it. Once you learn the basics, want to do X? Google it and determine a) how to do X, or b) if X can't be done / is bad practice.
Just by diving head-first into whatever you're trying to accomplish (or a toy project if you just want to learn), eventually you'll start to get the hand of syntax, libraries, and general programming style. But read articles every once in a while on best practices so you aren't learning the "wrong" way to do things.
The big drawback is that there are a lot of Google results that are outdated, novice, or flat-out wrong. You have to really learn how to do research on the internet. But this is a skill you should learn because you can apply it to anything. My general advice: consult official docs whenever possible; Stack Overflow is reliable but check the answer's comments to see if it's outdated; use Reddit to compare X vs. Y; try to avoid long wordy articles on bloated sites, generally the better the writer = the better the article and more likely it's accurate.