Seconding the Make-A-Lisp and Crafting Interpreters recommendations. TFA is also pretty good, it contains a hard written parser that you may learn from. Lisp grammar is regarded as simple enough that full parser generators need not be used.
There are also the Lis.py articles which are incredibly good:
You mentioned you want to write your lisp in javascript so you'll be getting quite a lot of functionality for free: memory allocation and garbage collection. That alone solves an enormous amount of problems. Just in case anyone reading is going to write in C, here's an excellent introduction to the topic:
I’m not really sure how you would be able to write an interpreter without a parser, since you need to know what the user is trying to do. For a more complete tutorial there is Make-A-Lisp (mal) [0] that has steps for making a lisp in various (including JavaScript) and has a process guide [1] to get started.
I can second Make-A-Lisp. I worked through it in C# initially, and I'm now halfway through a Rust implementation. The MAL process guide is a good set of instructions but doesn't go as far as actually presenting pseudocode, so you do have to think, and sometimes 'cheat' by looking at one of the reference implementations. In terms of tokenising and parsing, the MAL guide does include a monster regex statement that recognises the relevant tokens, and the parsing is quite easy due to Lisp's relatively simple syntax. If you choose the right implementation language, it will do some of the heavy lifting for you (notably memory management).
[Edit] Just wanted to reiterate that lexing/parsing Lisp is easy as per the MAL instructions. IIRC the things that I found hardest (in C#, as a C# newby) were understanding how to implement the closures required to support function definition, and then implementing Lisp's macro expansion.
I have not heard of tagless final style interpreter before and that seems really neat. However, based on the link it seems that tagless final interpreter uses a strong type language like Haskell or ML so I don’t know how well it would translate to Javascript, which is what the GP comment said they were using.
The style of the construction is what matters most. If you're using JS then you're already giving up types, but the higher order abstract syntax is what lets you embed and play with language semantics.
I think I may have misunderstood what your original comment was referring to. Were you saying that one doesn’t need a parser to make a working interpreter? I want to make sure that I understand the context of your comments because looking at the post you linked where you did this in C# you show you are using a recursive descent parser. It was when I saw the parser that I realized I could be way off base on what I was thinking you were talking about.
Yes, it doesn't need a parser. I didn't link to one post, it's a tag that links a series of posts discussing tagless interpreters. You can use the interpreter in the first post directly without the parser as well, it's a separate component. IQueryLanguage<T> is the interpreter definition.
I should note that the other posts go into more of the theory and background of final tagless encodings, including links to Oleg's site who has done a lot of work on them. They are a very flexible for implementing embedded languages.
Many are based on the SICP metacircular evaluator. Write that in your language of choice then you can bootstrap into scheme from there. Also see the 1986 MIT lecture videos by the authors, to get the spirit of the thing.
I liked Norvig's a little better. It starts with a simple interpreter and adds improvements step-by-step, winding up with an optimizing compiler that targets a bytecode VM.
That approach makes a lot of implementation details manifest in a way that is easy to grasp. For example, I think I understood continuations much better after seeing Norvig's account of how to implement them.
I'm looking to write a really basic one in javascript except using plain arrays. No parsing or tokenizing for me.