Can anyone recomand a “JavaScript for profesional programmers”?
I.e. something that introduces JavaScript assuming you know a lot more about programming than your average JS developer and explains the JS pitfalls in common terms and not js “ecosystem” inventions?
I can second this recommendation. JS is an odd bugbeast in that it took some design shortcuts early in it's life that aren't really visible without this kind of "here are your primitives" review. It also works like any other language primer in that it doesn't go into needlessly specific domain bound examples. That kind of stuff should be in a stdlib-eqsue doc.
A good read for even for some one like me, who slings JS almost daily.
I know JS is mocked for the horrible type coercion, but on a day-to-day basis I don't find myself needing to know how it works in detail. All you really need to know is that you should avoid it. Use triple equals and don't try to add or subtract non-matching types.
It specifically gives you an example of how "==" clearly sucks and shows you how "===" fixes it. I don't see why a "guide for professional programmers that know more than the average JS programmer" (as per the request) would need to belabor that any further.
Sorry, I'm looking for a comprehensive manual, not a series of random blog posts. I knew about type coercion because everyone laughs at it, but what about the things I don't know to ask about because I don't know they exist?
Maybe a bit too slow if you already know other languages, but you can at least trust it not to give bad advice. There are an absolute mountain of inexperienced JS developers out there giving a lot of bad advice. Take every StackOverflow answer with a fist full of salt. MDN is reliable though.
Yeah, that’s the whole point. I don’t want to be told how a loop works in kindergarten terms. I want to know the memory and event model and be told in one line why JS has three equality operators. I want a concise list of types and automatic conversions. I want to know how Node’s multitasking differs from Windows 3.1, because my impression now is it doesn’t. Stuff like that, you get the idea.
As a primarily frontend developer, I've had a couple of good experiences helping some experienced backend developers work through You Don't Know JS[0].
Having read many programming books, I find at a professional level, you just want to get straight to the juicy stuff with real life examples. For that, Goal kicker is hands down my go to for that. While you're at it, also download the NodeJS ebook from there too. They're free.
There's a new edition of the O'Reilly doorstop "Javascript: The Definitive Guide". I've learned a lot from it and started to use modules, promises and dropped all my horrible old 90s habits.
It reads really well, explains the modern bits as the right way of programming, but also puts the crusty, abandoned bits into the right perspective (if you're looking at old code I guess).
It's not at all a book for new programmers, but for someone who knows Ruby well, it's a great, concise read.
It predates ES5, and a revision is imo long overdue. It was an excellent resource in its day, but there are a lot of good parts too new for it to have covered.
Books that fit that description, and that I've heard good things about are JavaScript: The Good Parts (but maybe not quite up to date anymore?) and Eloquent JavaScript.
I have good experiences with Javascript Allongè, I know the author is on here as well. It builds up your understanding of the language from the basics, focusing on JS specific things like function scope and higher-order functions and `this`, without insulting your intelligence.
I recommend JavaScript: The Good Parts. It's pretty dated by now but still is a quick introduction to JavaScript for professionals. You can then read MDN for new features not covered by the book.
The Good Parts by Crockford will always be on my list. It's dated in terms of language expansions, but it really will lay the foundation for many of the patterns that are now commonly used.
Kyle Simpson's volumes are excellent.
Eloquent Javascript
The author's earlier ES6 book is great.
Most of the above books have a few chapters you'll end up skimming or skipping.
Don't know about "Professional" However, if you want to go the LISP route in the tradition of The Little Schemer, then check out:
The Little JavaScripter:
Also in general even if programer don't end up using LISP type of language they get better by just learning it. And Javascript is decent stand in for LISP, as Crockford points out.
I'm enjoying Manning Book's "The Joy of JavaScript", in early access but available. I'm currently reading about how mixins are done using JavaScript's unique features, and I'm looking forward to the function programming and algebraic data types.
I'd recommend doing an online course where you learn something useful like React and the ES6 syntax will come for free as you go along. I found Udemy to be quite useful.
Otherwise, from a programmer's perspective, JS is like nothing else I've seen and it's not something you want to be using without an abstraction over it, i.e. some framework that makes life less miserable when building something more complex than a form.
I feel like being a 'JS professional', unlike other languages, mostly involves in-depth knowledge of the right tools and not the language itself. Unless, you are interested in building frameworks yourself, which I personally find no need to ever do given the available options.
This advice is so strange. Do you imply, that learning pure JS is not useful?
I dread this attitude. Also, you cannot have "in depth" knowledge of any higher end abstraction whithout knowing the language. By definition it will always be just a superficial knowledge.
Pure JS obviously has its uses but I am assuming every professional values productivity which one can't often obtain just by knowing JS itself. JS sometimes feels like assembly, you just don't want to touch it, that's why things like TypeScript exist, for example.
Also, saying an abstraction is useless without knowing the language is similar to saying you can't drive a car without knowing how the timing belt or crankshaft works - most people do fine without either. I'm not dismissing the value of JS fluency, just suggesting that it might be unnecessary and a more practical approach can be taken.
I don't even get it. You write Javascript basically 1:1 the same as Python or Ruby. And I would argue it's even nicer in various cases, from destructuring to lambdas to async/await and first-class Promises.
I wonder if the people say they avoid JS at all costs because it's "like assembly" have been doing that so effectively since 2003 that they never even tried modern JS
I read a blog of a fresh grad describing ‘this’ keyword in JS. The conclusion he/she had by the end of the article was ‘don’t use “this” keyword unless you are JS expert’.
I always see a pattern with these things. Usually if you don’t learn the language well enough, you probably are also not spending enough time learning the frameworks well enough, and you probably are not learning the DOM/Browser well enough, and you probably have not learned CSS well enough. You will have no choice but to hide behind the frameworks.
The people that just learn React or the latest ES6 think they know good enough JS, but when I see their code I see clear patterns of poor abstractions, separation of concerns, the kind of code that makes you want to take a shower after touching it.
React is a particularly bad way to learn pragmatic Javascript because it's idioms are quite different from how people program in any other scenario but UI dev. It's a UI library and you won't learn much about Javascript programming from it. You will just know React.
You should absolutely learn React if you want to be employed writing with JS, but people should understand where React lies in the context of javascript. It isn't an abstraction of JS, it's a UI library written in JS.
> You should absolutely learn React if you want to be employed writing with JS
I know that this probably isn't how you meant it, but I think what you said is a bit misleading to someone who wants to learn JS for a job.
Having skills in React are an almost guaranteed way to get a job writing JS. It's definitely not the only viable way to get employed writing JS. Contrary to popular belief, there are many jobs out there asking for Node.js skills but not necessarily React or any heavy frontend knowledge. You can also make a living doing Vue or Angular, and Svelte is an up and coming framework that will be good to learn and I believe will create lots of jobs. I've been writing mostly Ember.js code for years now, yet I'm employed.
I just want to make sure that learners don't think that it's all React or nothing. Nothing against React, by any means. If someone learns React but it doesn't interest them, their career in JS isn't over.
A little learning is a dangerous thing ; Drink deep, or taste not the Pierian spring : There shallow draughts intoxicate the brain, And drinking largely sobers us again.
I don't (think I) have much of a problem with JS syntax, generally speaking, but I'm often baffled by the surrounding ecosystem of build tools and "helpers". There are a million tutorials, all doing things slightly differently without really explaining why, and stuff breaks so often...
Any recommendation for something covering that sort of thing (npm, yarn, webpack...) in a more structured and in-depth way than "here's how to make a todo list in 10 minutes with some magical command that may or may not still work 3 months later"?
I agree. Even just finding out what the tools are is ridiculously hard. Here's a list:
* NPM: Package / dependency manager. Also has some basic support for running scripts.
* Yarn: Very similar alternative to NPM.
* Babel: Transpiles modern Javascript to "old" Javascript, in case you need to support IE9 but want to use async/await or whatever. If you only support modern browsers you don't need this.
* Webpack: Originally it was for "bundling" Javascript files. You don't want to write all your code in a single file, but you often want to deliver it that way. Webpack reads the 'import' statements of all your files, and them converts them into a single file with emulated modules. Also helps when you are targeting a browser that doesn't support modules natively. However Webpack also comes with a load of "loaders" that can transform input files in various ways, e.g. allowing importing CSS files from Javascript, compiling Typescript, etc. So now it is kind of a big ugly build system.
* Node: The Javascript engine extracted from Chrome, plus a load of native APIs that let you do stuff you can't do in the browser because of security (write files, make TCP connections, etc).
* Electron: Basically Chrome plus Node. You can set it up so that your web pages can access the Node APIs inside Chrome, but you can also have them talk to an actual Node process via IPC.
Although you should probably prefer yarn these days (concepts should mostly transfer over).
As for tranformations/transpiling/minifying... You could use webpack - it is popular, but quite complex. I've found this a decent introduction to understand how it works:
The good part about going that route, is that is quite explicit... You might get away with throwing out explicit in favour of convention - by using parcel instead:
NPM is a pretty awful build tool really. In the only NPM project I work on we write a Python script as the build system, and the NPM scripts call that.
Don't really disagree with that. On the other hand, npm/yarn is generally a dependency you can't get away from - so if your needs aren't complex, I'd say in general, you're better off with a simple npm/yarn config, than pulling in another dependency.
Of course pulling in python in a python project is free, if python is tightly coupled to the js stuff anyway.
Often eg: the front end will be just js/ts - and reusable/useful without any python.
Yeah to be honest we don't use Python for anything other than the build system, but it is available on all our systems so it is easy to use, and I couldn't find anything better. I would have liked to be able to use Typescript, but there's no really good simple way to say "Node: compile and execute this typescript file, please don't save the output on disk anywhere, or try to read tsconfig.json or package.json or whatever".
> there's no really good simple way to say "Node: compile and execute this typescript file, please don't save the output on disk anywhere, or try to read tsconfig.json or package.json or whatever".
I guess there's no native typescript support for nodejs (so npx is out). Maybe deno can help?
Thats clearly a sort of "now you have two problems" type solution - but if there's a desire to stick with ts as a language - it might be helpful? (to drop the python dependency).
I sympathize with this. I wanted to use, and slightly modify, a small web app I found on GitHub.
Despite it being client-side only, it used node. An older version, with older versions of webpack, Babel, and so on. And tons of now deprecated npm packages. It was only a couple of years old.
The only way I could make it work, after days of trying, was a docker container of an older Linux distro. I did try just upgrading packages, but the avalanche of dependency hell made that literally impossible.
I have not had this experience with any other language.
Edit: Noting I have had to update/upgrade older Perl, Python, etc, projects. And they weren't all easy. But they were at least possible. Dozens of things to chase down. Not hundreds.
I've had the opposite experience trying to get python and/or ruby not to trash my global environment and various things wanting the system to be setup for their versions and libraries. I like that NPM by default makes all dependencies local and npm lets you include your dev dependencies local to that project.
Note: I know their are magic incantations for python and ruby to get them to make everything project local but they aren't what python and ruby do by default.
As a backend developer getting his foot into frontend I feel you. Configuring TSLint with Prettier and all the plugins was tiresome only to learn few months later it's getting deprecated and you should move to ESlint. This article helped me bit, it explains "what is what" in modern JS ecosystem https://medium.com/the-node-js-collection/modern-javascript-...
My honest opinion is that you should read the npm-cli docs[0], the babel docs[1] and the webpack docs[2]. I think that most tutorials want to skip to the "getting stuff done" bit, and learning these tools with a bit of granularity is well worth it for any serious Javascript project.
These three tools form the backbone of most modern Javascript projects. Understanding what they are, why they do what they do, and how to extend them is vital to being able to work with modern JS.
The docs, particularly the introductions are written for a fairly inexperienced audience and I find them easy to work with.
I'd recommend the Webpack tutorial by Andrew Mead, interestingly enough. It goes through all these tools and why they're needed, and you build out a simple config with Webpack and understand exactly what it does and why.
I really like it, actually. I finally had a free hour this afternoon to start getting into it. I'm only on video 6 so far but I've already learned quite a few things that I had missed and/or misunderstood previously. I've also sent it out to my team so that they can check it out next week, after the holidays, (and during work hours) to fill in some of the gaps they may have, as well. Thanks again for mentioning it and linking it!
Yeah, I'm in the same boat, I'm still struggling to figure out how to write a library in typescript and then use it as a browser library. I have a feeling that I just need a better understanding of the core concepts (modules, bundlers, etc..)
It's good to understand modules well. Understanding bundlers is less important and can be postponed. Just use let parcel do the transpiling and bundling for browsers.
It's quite simple actually. With native modules support you don't really need any of these helpers.
However, if you're concerned about users on older browsers, you can use Babel to "transpile" your code to equivalent code that older browsers can understand, often at the expense of size.
npm and yarn are simply 2 competing implementation for package management. Start with npm and you'll know it when you want yarn.
Webpack and other module bundlers are just tools to automate things like transpiling, code-transformation, bundle-splitting, minification which are not all that essential actually.
The point is all of these are extras. Think of them as enhancements/optimizations. If you have a solid understanding of JS you can write JS in a way that doesn't require any of this. I blame the tutorials out there that say you need this and that without many justifications that make it seem more complicated than it is.
> Webpack and other module bundlers are just tools to automate things like transpiling, code-transformation, bundle-splitting, minification which are not all that essential actually.
I wish this were true. My experience to illustrate the point:
I have a Javascript library[1] for working with the HTML5 <canvas> element. It's a nice library (in my opinion) but it is a bit on the large side. Also, I developed it as something that can be added to a website in the old-fashioned way, using a <script> tag.
However, most non-personal websites these days are built with toolchains which include code bundlers like Webpack (many React sites), Rollup (Svelte sites), Packet etc. Developers working on those sites don't want to add a <script> tag to their HTML file; they want all their Javascript npm-included or yarn-added so it can be shaken and bundled and tied up in ribbons and bows for delivery to the user's browser or device.
So I did the work of turning my library into an NPM package and tried building a toy project with a toolchain. The failure was embarrassing. It turns out that I was using a JS feature in my library code which isn't supported by any of the main bundlers (`import.meta`, for the curious[2]. I raised a ticket with one of the bundlers to see if they could add support in a future release[3] but it seems the feature is too obscure to care about.)
I sorted the problem by rewriting my library (in a very unsatisfactory, ugly way) to get bundlers to bundle the code. Now people can add my library to their React/Svelte/whatever project. But the whole learning episode left a bad taste in my mouth: Being tripped up by Vanilla JS is one thing; having your work trashed by the bundlers in the toolchain is just nasty!
I would not suggest this book. While it does begin with simple, concise examples, it leaves out many important details.
For example:
- The first variable using `const` is called ”immutable”, which is misleading, since only the _assignment_ is immutable. Later on the same page, a const object property is assigned to without any clarification as to why it works.
- Only single- and double-quoted strings are introduced at first, even though template strings are arguably the cleanest for building strings.
- Arrow functions are introduced as just another syntax - neither implicit `this` binding nor implicit return of last block statement are mentioned.
In general, I occasionally have to initially leave out some details so that the book can be read linearly. But those details are then filled in later in the book.
Thank you for your books and websites! After reading 1,000 sites explaining that async/await is just "syntactic sugar" [hint, it's not], you're the only one who explains it correctly.
You should define and describe the concept of "binding", if you don't already. Telling me a const declaration is an immutable binding does nothing for me if I don't already know, or immediately find out, that binding is the general case of assignment, an association of a value with a name. Given that and an understanding of the differences between value and reference types, there are few surprises left for me in how Javascript handles names and values.
I sometimes find myself informally teaching devs less experienced with the language, and I've learned to cover this part of it very early. It's not made terribly obvious in a lot of resources people have mentioned using, and I've yet to encounter a case where developing that understanding failed to help someone better understand the code they were writing, and thus write better code. (Usually I'm also reviewing a lot of their PRs, and that makes the change pretty easy to see.)
I've been looking a long time for a good "Javascript in a Box" that I can give to mentees as a tool for extended learning beyond what we can cover directly. Your book and its associated materials look as if they might be just the thing, and I'm evaluating them as such.
Is there an email list or something I can use to be notified when the revisions you describe have landed? I have someone already in mind to be a "beta learner", but I'd rather wait a little for the updated version, and it would help to get some kind of push when it's available.
Ping me at dr_axel AT icloud.com and I’ll notify you. Two universities in Switzerland are using my book to teach JavaScript and seem happy with it, so far.
> an understanding of the differences between value and reference types
It's a common misconception among JavaScript programmers, especially experienced ones, that such a difference exists. It doesn't.
The usual explanation is that there are value types such as number or string, and reference types such as array or object, and these are treated differently both by the assignment operator and when passing an argument into a function: the value is copied for a value type, but a reference is copied for a reference type.
This is often illustrated with an example like this:
function a( str ) {
str = 'moo';
}
let s = 'bar';
console.log( s ); // 'bar'
a( s );
console.log( s ); // still 'bar', because a string is a value type
function b( obj ) {
obj.foo = 'moo';
}
let thing = { foo: 'bar' };
console.log( thing.foo ); // 'bar'
b( thing );
console.log( thing.foo ); // now 'moo', because an object is a reference type
This code does work as the comments describe: 'thing.foo' changes but 'n' doesn't. But this is not because of any distinction between "value types" and "reference types".
It's because the code in the a() and b() functions is different!
The code in a() reassigns the function parameter (which is a local variable) to a new value. The code in b() doesn't do this, it sets a property of its parameter.
The difference in behavior is solely due to this difference in code.
Every example that purports to illustrate how "value types" and "reference types" are handled differently in assignment or parameter passing makes this same mistake.
To illustrate further, strings are commonly described as a "value type", as in the example above, and most of these discussions say that when you assign or pass a value type, the entire value is copied. But no JavaScript engine worth its salt does this. If you have code like this:
let str = 'one billion characters here';
let copy = str; // Does it *copy* the billion characters? Of course not.
Now for a short fixed-length value such as a number, a JavaScript engine may well store and copy the actual value. But this is an internal optimization, not part of the JavaScript language. It is fundamentally unknowable from JavaScript code whether the engine stores the value inside its internal Value object or stores a reference.
The real difference between so-called value and reference types is that the latter may have mutable properties and the former don't.
One last illustration: if you have an object and then call Object.freeze() on it, the object now has no mutable properties (and none can be added). Does that convert this "reference" type into a "value" type where future assignments will copy the value instead of copying a reference? No. It's just been made immutable.
I will be happy to discuss further if anyone has questions or disagrees.
This is a splendid example of the kind of thing I let mentees discover on their own, when it actually starts to matter in what they're doing, rather than burden them with right up front. If binding is an uncommonly encountered concept, interning is a practically unheard-of one, and it would be a severe disservice to explain it, and copy-on-write, at the same time as everything else I'm asking someone new to the language, and often new to programming entirely, to follow.
You're right that the description I gave is fundamentally a false one. But it is a harmless, and an extremely useful, lie.
(In any case, you're underplaying your hand here. If you're going to get deep into the weeds on how Javascript values really work, why leave out implicit autoboxing?)
JavaScript has both reference types and (what are treated in the abstract if not in implementation as) value types. It also implements (solely) a call by value evaluation strategy, which is orthogonal to the previous statement.
Consider that this may simply be a knowledge gap on your end. I think most programmers understand the concept of value vs reference types and would not assume an object to be a value type. Obviously the reference is immutable, as is any other value type you assign to the const.
> nor the implicit return of last block statement are mentioned
Probably not mentioned because it doesn’t exist. There is no implicit return of the last block statement. That statement is misleading in at least two ways: there cannot be multiple top-level block statements as the body of a function, nor does the singular block statement body of an arrow function implicitly return the last expression. It actually requires an explicit return statement. On the other hand, an arrow function with an expression body -does- implicitly return.
>Consider that this may simply be a knowledge gap on your end.
My experience says this is very far from the truth. JavaScript's implementation of const is confusing for almost everyone the first time they come across it, especially the area you're talking about - changing collections. Junior engineers and non JavaScript senior engineers alike don't seem to understand what const actually means until they dig in to get deeper context, which I would point as a pretty big failure of language design.
I think it's a failure of education, specifically around the concept of binding as the general case of assignment.
I came late to that myself, not encountering it as a discrete concept until I got interested in Lisp, and found it clarified a great deal for me that had previously been obscure.
With that concept available, const is trivially explained as an immutable binding, as indeed the author of the book under discussion explains it elsewhere in this comment thread.
Without it, yeah, const feels full of special cases, just like everything else involving non-primitive types. It's something I've learned to cover early in teaching the language, because a little early effort there goes a long way toward clearing up a lot of confusion later.
Good point. However, most web developers starting with JS tend to come from PHP with its &$variable reference-passing magic.
I seem to have chosen my wording badly, since I did not mean (labeled) blocks, but indeed the expression body (which may have been referenced in the book as a ”block”, too lazy to check).
Maybe they meant implicit return after the last block statement (ie the implicit return void)? But that's not exclusive to arrow functions, so probably not.
Suggestion: If you are impatient, do not become a programmer.
Programming is a craft. It needs patience. You need time to learn the ropes.
Some people look for shortcuts, learn the tricks of the trade instead of the trade. Please do not be one of those people.
Imagine what would happen if someone with that mindset built bridges or skyscrapers. Or roads. Anything, really.
In fact, be prepared to try things and then throw them away, because only after you failed once have you gained an understanding of your environment and what you are actually trying to achieve in it.
Almost every very good programmer I know is very impatient. Due to their impatience they go faster, and going faster all the time leads to making more stuff, which leads to a compounding effect on all the work you do and the knowledge you acquire, which leads to better software.
Getting to a better or equal solution faster is always better, and you need to be impatient to go that way.
The hacking philosophy and its child UNIX are built around people and processes like that.
On a more general note, I think any gatekeeping like this is harmful, do not listen to people telling you to not become $SOMETHING (programmer, engineer, artist...) because you are $SOMETHING (impatient, disabled, a woman...) and do what you want with your life.
Larry Wall, granted he made Perl, says these are the three virtues of programming.
> Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it.
> Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to.
> Hubris: The quality that makes you write (and maintain) programs that other people won't want to say bad things about.
I think in the end the best way to describe a good programmer is "detail-oriented" and "results-based" that cuts out the bullshit and can ship. The better programmers that are product developers see programming as a tool to make products, not a tool to bike shed and yak shave all day.
Thank you, this is just what I needed! I started reading Eloquent Javascript recently, but since I already know Java and Python it was too slow paced for me (I don't need to read 5 pages on if/else statement)
I skipped some sections, but I feel like that book does a really good job of introducing lesser-known aspects of the language (like how async/await is kind of just generator functions + promises, or how Symbol.iterator works), and then it gives good historical context for idiosyncrasies (like the difference between esmodules and commonjs).
While a PhD is short for a Doctor of Philosophy, at universities such as Princeton or Stanford the title "Dr." is reserved for medical doctors. At less secure schools one sees the title imposed by administrators. It's a wonderful poker tell; you'd think people would be aware what they're signalling? Or they know, but we're not their intended audience.
In Germany, "Herr Professor Doktor" is often in jest, as one usually restricts to the highest ranking title. And titles are fading, a form of class-consciousness. To use "Doktor" unnecessarily reveals one is not a Professor.
So I don't understand the cultural context for this author's use of "Dr." It's welded to his web site dr-axel.de; perhaps this is a stage name like "Dr. Ruth".
I always just read it as "this person is proud they put the work in to get that title" and leave it at that. Life is too short to worry about the the other stuff ;)
Granted like you I noticed it too, it is something that I think I've seen less commonly used too ;)
> at universities such as Princeton or Stanford the title "Dr." is reserved for medical doctors.
At Stanford at least, this (admirable) attitude is more common in the med school and biological sciences where the ambiguity is common than In other departments, especially where you might not know the person.
Everything you’ve mentioned plays a role. It has also worked well marketing-wise: In Germany, people take you more seriously; in the US it doesn’t matter, but a title is still more memorable.
I.e. something that introduces JavaScript assuming you know a lot more about programming than your average JS developer and explains the JS pitfalls in common terms and not js “ecosystem” inventions?