JavaScript for Impatient Programmers
exploringjs.com
exploringjs.com
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?
Though I also think I took a liking to the guy when I decided he looked like Neal Stephenson.
https://developer.mozilla.org/en-US/docs/Learn/JavaScript
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.
1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re...
A good read for even for some one like me, who slings JS almost daily.
In most languages that I know this is documented. They don't tell you "this sucks don't use it".
Sorry for trying to help I guess, good luck.
This is the question that you asked and that I answered.
If you're looking for the language specification, it's here (first result for "Javascript specification"): https://www.ecma-international.org/ecma-262/11.0/index.html#...
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.
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.
Every time I see this statement, I wonder what the Venn diagram of people who say so and people who have ever written a line of asm looks like.
It's not even their fault, it's all they know from those online courses or boot camps.
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 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.
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.
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.
Many of those idioms borrow from ideas (functional programming, reactive programming) outside UI development, and outside JavaScript.
I would think that an experienced programmer starting with JavaScript would appreciate React.
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.
https://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfo...
It may be a perfect time for a revision.
https://www.amazon.com/gp/aw/d/1949815005/ref=dbs_a_w_dp_194...
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.
> ('b'+'a'+ +'a'+'a').toLowerCase()
>'banana'
alert(Array(16).join("wat" - 1) + " Batman!");
"No prior knowledge of JavaScript is required, but you should know how to program."
https://books.goalkicker.com/JavaScriptBook/ and https://books.goalkicker.com/NodeJSBook/
https://eloquentjavascript.net/
It may be a bit more introductory than you're looking for, but trust me in that you'll want to read it from front to back as it builds on itself.
It's not short and quick, but it's comprehensive, good, and even fun!
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"?
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.
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!
[1] - https://scrawl-v8.rikweb.org.uk/
[2] - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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.
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.
Looks like I misremembered, it's actually by Colt Steele.
* 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.
https://www.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...
https://github.com/keithamus/npm-scripts-example
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:
https://www.freecodecamp.org/news/creating-a-production-read...
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:
https://github.com/parcel-bundler/parcel
(looks like gh readme is currently best entry point for 2.0 docs).
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.
I guess there's no native typescript support for nodejs (so npx is out). Maybe deno can help?
> Supports TypeScript out of the box.
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).
Ed: hm, there's apparently ts-node : https://github.com/TypeStrong/ts-node
npx ts-node script.ts
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.
[0] https://docs.npmjs.com/cli/npm [1] https://babeljs.io/docs/en/ [2] https://webpack.js.org/concepts/
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.
[1]https://github.com/getify/You-Dont-Know-JS [2]https://eloquentjavascript.net/
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.
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 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.
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).
That’s a first look at the syntax. The details are explained here: https://exploringjs.com/impatient-js/ch_variables-assignment...
But I should clarify that “immutable” here means “immutable binding”.
> Only single- and double-quoted strings are introduced at first
I had to start somewhere. Template literals and tagged templates are a more complex topic that benefits from strings already having been introduced.
> Arrow functions are introduced as just another syntax
Arrow functions are introduced in detail here: https://exploringjs.com/impatient-js/ch_callables.html
---
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.
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.
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
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.
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.
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?)
- reference/value _data types_ - call by reference/value/value result/etc _evaluation strategies_ - (im)mutability
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.
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.
> 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.
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".
Granted like you I noticed it too, it is something that I think I've seen less commonly used too ;)
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.
In the scheme of things this is not a big deal.
e.g.: sometimes you can do Object.create(obj) instead of Object.clone(obj) if you just want to have a one-off object.
What kind of letters is this? 🇬🇧 (copied) / GB / gb - same font, different letters. Why?