Whoa! You’re going to finish all seven (six?) of those books over the next month? Just on nights and weekends? How are you so productive? How do you not burn out, given that (I assume) you do software during the day? Honest question, from someone who is often down on themselves for being a slow coder, slow reader, and easily burned out.

For React, why not just read the docs? You don't really need anything else.

I guess (online) books speed up the learning, but I've learned all those techs by practice over a few months, official docs (mdn, nodejs docs, react docs, googling, github issues & stackoverflow) and IRC

Thanks for posting these. I need to do some refreshing as well.

I'm convinced that prototype object systems represent a poor set of requirements.

Those requirements are chosen because they lead to ease of implementation: prototype objects are the quickest and dirtiest way to enhance an interpreter such that programs can be written in it that are discernibly OOP-ish.

They don't represent a set of requirements that amount to a good OOP system.

I am not a full blown Javascript developer (backend developer here), but had been using JS and other frameworks for about 10 years now. I subscribed to Dan Abramav's "Just Javascript" [1] email. It is really good to read/follow and has one concept and idea explained well.

[1]: https://justjavascript.com/

I think the sentiment of "you dont know what you dont know" is especially cumbersome with JS, since its usability is so much defined by its extensions (WebAPIs, runtimes etc.)

Reading into specs (ECMAScript[0], W3C[1]), some more approachable explanations[2] of them and some implementations[3, 4] of embedded engines seem to be my approach.

[0]: https://tc39.es/ecma262/2020/ [1]: https://github.com/w3c [2]: http://dmitrysoshnikov.com/ecmascript/javascript-the-core-2n... [3]: https://bellard.org/quickjs/ [4]: https://v8.dev/docs/embed

In addition to the already mentioned 2ality blog and YDKJS books, read Javascript Allonge [1].

[1] https://leanpub.com/javascriptallongesix/read

I've been using JavaScript professionally for about 12 years.

You're going to have to look for talks and really technical posts. Consider whitepapers and source code for JavaScript engines at this point. You'll probably want to start reading up on the things attached to JavaScript, rather than the language itself. Browser rendering, event loop, V8 things, garbage collection, etc.

I'm sure you've seen it, but things like this: https://www.youtube.com/watch?v=8aGhZQkoFbQ, and this: https://www.youtube.com/watch?v=SmE4OwHztCc

It might be time for you to start writing what you know about JavaScript.

Have you ever read through this annotated ES5 spec? Even annotated it's still pretty dense, but it's a nice way to both dive deeper into the language and as a 'minimap' to guide you through the parts you have yet to totally master. It definitely helped me level up more.

https://es5.github.io/

I would recommend watching Andreas Kling's youtube series where he builds a javascript engine from scratch.

https://www.youtube.com/watch?v=byNwCHc_IIM

if you can't find something you didn't already know in the free book series "you don't know javascript" then I'd imagine you might not have any gaps in your knowledge. (at least for 99% of it)

(you can buy a hard copy of it if you want but it's open source)

https://github.com/getify/You-Dont-Know-JS/blob/1st-ed/READM...

Are you familiar with various tc39 proposals? Do you understand how JS VMs work?

Knowing the internals of the engine really informs you on performance and resource utilization characteristics of various ways of writing code.

Some of the TC39 proposals might be worth looking at. The ES spec too.

If you really want to go all out, you could write a simple JS interpreter. Probably don't want to go full spec compliant but you could implement a decent subset. Especially if you skip the parsing step with Acorn https://github.com/acornjs/acorn

I would maybe recommend Typescript if you want to harness the type level power of "proving" correctness for certain aspects of your code.

read "you don't know JS" series of books, also second edition https://github.com/getify/You-Dont-Know-JS I find the workshops very helpful as well, which I've watched through my oreilly membership don't know if you can find them elsewhere, I would suggest combine this with reading the specs.

on edit: one reason the specs are not enough is generally specs will tell you what needs to be implemented but a good book, like these ones, will tell you how it has been implemented or what the spec implies for implementation and what all that will mean for you as a user of the language.

try to implement a ES2020 interpreter from scratch (like fabrice bellard's quickjs)

when you're done, you'd have learnt enough on the way and know what you don't know

> But I'm always worried about those situations where you dont know what you dont know. This might sound strange, but would anyone recommend any reading material or blogs for someone at my level?

It's not very clear what you are asking, neither what's your background. In your situation I wouldn't spend more time learning stuff about JavaScript, I would just improve my skills in software engineering (design patterns, code quality, refactoring, etc) and diversify my knowledge (learn other languages (python, go, or some FP language to learn something really different); databases and SQL; web servers and REST; etc).

Not sure how it holds up, but Secrets of the Javascript Ninja was the book I read when I felt like that, and it significantly helped me understand a few concepts I had struggled with. By John Resig (created jQuery). But it's a few years old now, so likely won't cover much if any ES6+ stuff. But I'd bet the concept stuff is still very valid.

Also the You Don't Know JS series. And Elliot's Programming Javascript Applications.

I don't know you, so I don't know if this applies or not, but be careful not to fall into the "expert beginner" trap (i.e. Dunning Kruger). Your first sentence starts to feel that way, but the fact you're asking for more resources and aware there are things you don't know are good signs. Always keep learning, the rabbit hole goes ever deeper.

At one point, there will be only sourcecode to read. Read what the best programmers actually do use.

humble opinion: N years of using any language won't make you an expert.

There's knowledge about how to express certain patterns in a given language, more like an application design expertise. There's knowledge and familiarity with the APIs. And then there's the deep language knowledge, the one that pretty much only someone implementing a language VM, parser, compiler and other tools may acquire with time. Also, there are a lot of specifics about every particular JS implementation.

Also, Dunning–Kruger :-)

On the internals of VMs, https://mrale.ph/ has a lot of blog posts on internals/optimizations on V8. https://www.wingolog.org/tags/javascript also has deep JS articles very freqently.

From amazon

> This much anticipated and thoroughly revised third edition of Eloquent JavaScript dives deep into the JavaScript language to show you how to write beautiful, effective code. It has been updated to reflect the current state of Java¬Script and web browsers and includes brand-new material on features like class notation, arrow functions, iterators, async functions, template strings, and block scope. A host of new exercises have also been added to test your skills and keep you on track.

I learned JS with this book back when it was ES5 - looks like the new edition is updated for ES6

Typescript is relatively new, and I think a lot of those companies are still trying new things and experimenting with what works. I expect that we will see more refined content and books about TS-at-scale in the near future though.

However, for those looking for a great way to learn Typescript from a beginner's perspective I can fully recommend Execute Program[1].

[1]: https://www.executeprogram.com/

> patterns for large-scale project design and code structure

I would be particularly interested in this. The OP has a chapter on "Program Structure" but it seems like more a toolbox of language constructs.

It would be nice to see a book that went through a few archetypes of common JavaScript programs (command-line script, daemon, enhanced webpage, single-page app) and gave a basic blueprint for what parts are needed and how they interact.

Not quite what you're asking for, but I really liked this book since it was beyond introductory material and had concrete examples of what and why to do things:

https://effectivetypescript.com

A project in TypeScript is not much different from one in JavaScript structure wise. The biggest difference might be the explicit work on types and modeling your problem to make good use of composite types. In the source code you'll have some type definitions where implementation and usage sit close to each other (to enforce a local implementation), and others where a type is more like a serializable DTO (data transfer object) between different domains and seen more global throughout your application. You'll get a feeling when mapped types should alter a type or when a local type definition might be better (TS is structurally typed for a reason).

Domain modeling can feel close to "type driven modeling" here. A good book in that regard is "Domain Modeling Made Functional"[0]. I see types and a functional paradigm closely related, but keep in mind that this is just one approach in your toolbox... there might be the case where a GoF OOP pattern works good as well[1]. I think it's also important not to try to trick the TS compiler into something, but rather to work with it. Keep in mind that the TS dev team is giving you a lot of freedom by not striving for a provable correct type system[2].

To really take advantage of TypeScript I think it's good to know where a type system is coming from, what it is that it's trying to solve and how it is doing that. I think it's helpful to have a look into other languages with a "strong" type system (Haskell[3], OCaml, rust) and see how they are doing it. Then you may get to see how Haskells phantom types will conflict with TypeScripts type inference, and OCamls type inference seems to work in fascinating ways compared to TypeScript. After working through the advanced types[4] in TypeScript it's good to understand what a "good abstraction" in case of a type system is and what isn't... this is when you discover the similarities to other languages through the common language of abstract mathematics (and abstract data types). In every program you'll encounter effects and monads are quite helpful to work with them, this is were a sound type system can really shine.

I feel with every JS/TS project you will build a lot of the projects toolchain yourself and you kind of need to discover what fits best. It's good to be able to catch possible bugs early with the TS compiler, quicktype[5] can help you in building some typed contracts to other projects.

A separation into packages with lerna[6] should encourage a good separation into packages and is seen in a lot of open source projects. Speaking of, reading into good open source packages will be a mandatory way to go in order to learn more.

[0] https://fsharpforfunandprofit.com/books/ [1] http://loredanacirstea.github.io/es6-design-patterns/ [2] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi... [3] http://learnyouahaskell.com/ (a bit dated though) [4] https://www.typescriptlang.org/docs/handbook/advanced-types.... [5] https://quicktype.io/ [6] https://lerna.js.org/

I have avoided yield() and generators like the plague because they're hard to read and I've never seen them used except in examples explaining how they work. Yield feels like recursion - a neat trick for some corner cases but generally unnecessary.

So generators are used here because of the natural way of calling “next” and yielding a result.

How would this work for say, an XMLHttpRequest? Since you have to next into callbacks there I don’t think yield travels the function boundary...so you abuse next instead?

  function fetchUrl(url,done){

    var xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function() {
      if (xhr.readyState == XMLHttpRequest.DONE) {
        if (xhr.status === 0 || (xhr.status >= 200 && xhr.status < 400)) {
          done(null,xhr.responseText);
        }else{
          done(new Error("something went wrong"))
        }
      }
    }
    xhr.open('GET', url, true);
    xhr.send(null);
  }

  let response=yield fetchUrl('http://example.com',next);

  var someFunction =casync(function*(url,next){

    var xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function() {
      if (xhr.readyState == XMLHttpRequest.DONE) {
        if (xhr.status === 0 || (xhr.status >= 200 && xhr.status < 400)) {
          next(null,xhr.responseText);
        }else{
          next(new Error("something went wrong"))
        }
      }
    }
    xhr.open('GET', url, true);
    var response = yield xhr.send(null);
    ...

  });