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
Objects have function-valued properties called methods. So Objects can't do without functions.
Functions can return either a) atomic values like strings and numbers OR b) Objects. Note that in JavaScript Functions are Objects too.
So I hope no-one is seriously suggesting that FP can do without Objects, by saying that functions should only return atomic values.
Note that you can have methods which do not depend on mutable state. In ES6 you can FREEZE objects, which you could do in the constructor. Freeze the object after having set its "instance variables". Now all methods of that object are "pure functions". So you can choose. Choose to create pure functions or impure.
Creating a new immutable instance really is equivalent to creating a set of immutable ('pure' if you like) functions.
A couple key realizations made this much less of a "choice" for me (warning, my opinion):
1. Classes et al, are just a high level pattern which happens to be builtin... functions are far far more rudimentary.
2. If you use a high level pattern "just because you can" without considering the subjective cost vs benefit, it will be a poor fit on average.
What does this mean?
#1 Functions are not the opposites of classes, they are simpler, lower level abstractions which are more generalized - It should be thought of as the default.
#2 Like any pattern, OOP has a cognitive cost - When they don't fit a problem well, they merely obscure relationships between state and function; when they do fit a problem, they will minimize that cost and provide benefits that simplify other code.
If you don't immediately know that classes or prototypes fit the piece of code you are writing... just stick to functions, if later on you find that a collection of functions emerge with a common signature and persistent state being passed back and forth - you might have something that would benefit from a class, but you can simply change them into a class when it emerges. However if you do it preemptively you will probably be wrong and also make poor decisions about what the internal encapsulated state should be (which you want to minimize since you are obscuring it). It's ok to discover that something should be a class, attempting to make the choice up front is usually going to go wrong unless it's very obvious.
I think it's unfortunately a pretty natural path to start out not having an opinion of OOP and then potentially developing a distaste for it later on - not because it's inherently bad (it's probably the most generalized pattern and very useful); but because of it's integration into so many languages... I see it get abused by people all the time who just make a class by default for no apparent reason, which inevitably ends up as a bag of loosely associated state and arbitrary functions mutating one or more of those states. In such cases the class is of no benefit, and worse, it's obscuring all of the unrelated state mutations making it difficult to read and reason about.
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.
Also Typescript is well worth learning.
(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...
Knowing the internals of the engine really informs you on performance and resource utilization characteristics of various ways of writing code.
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
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.
when you're done, you'd have learnt enough on the way and know what you don't know
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).
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.
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.