[1971genocide]

As a mere mortal - How hard would it be for a day programmer to built something cool like an JavaScript engine ?

I sometimes have crazy thoughts about the world ending.

How hard would it be to built your own javascript engine from scratch ?

[chrisseaton]

These programs aren't magic. They use the same kind of constructs you use every day to write your programs. They use some different algorithms, but you can look those up in books and in existing engines. People who work on these engines started where you started and there's no reason you can't pick up all the skills over a few years.

[AYBABTME]

This is an excellent attitude.

[whatever_dude]

The problem with JS engines nowadays isn't as much about the language itself (or its core library), it's more about the absurd amount of optimization it should have to perform well in a varied number of possible setups, and all while the browser is busy doing DOM compositing, loading yet more JS code, etc. Things like JIT are not exactly necessary if you just want your language to "run", but an important part of an optimized system.

To me it seems the past ~5 years of JS engine development have been focused on what kind of optimizations to implement, rather than parsing or implement core library features.

[jacquesm]

Building a javascript engine is super simple. But to build one that has performance on par with the current crop will take you - as a single person - a lifetime and by then the state of the art will have moved on.

[Locke1689]

The performance is hard, but the bug-for-bug compatibility is what will kill you.

[bzbarsky]

Actually, for JS engines this is a much smaller problem than for other parts of the web platform. There are two nasty warts I'm aware of: the "function inside if" mess, and the fact that the spec says enumeration order is undefined but actual web pages depend on some things about enumeration order that all browsers implement; chances are this will make it into the spec at some point. But by and large JS engines agree with each other and with the spec. Much more so than, say, DOM or CSS implementations.

[WorldMaker]

Enumeration order was indeed (finally) added to the ES2015 spec. Here's a link to the release candidate spec for the [[OwnPropertyKeys]] algorithm:

https://people.mozilla.org/~jorendorff/es6-draft.html#sec-or...

[bzbarsky]

[[OwnPropertyKeys]] is not invoked by a for-in loop. [[Enumerate]] is instead, and while it defines that the set of iterated names is the same as that returned by [[OwnPropertyKeys]] it explicitly says that order is not defined.

[jacquesm]

You could just leave them out ;)

[jameshart]

In a world-ending scenario, 'having a working javascript engine' is likely to be surprisingly far down the list of priorities. I think we might actually need a new level on Maslow's hierarchy of needs, just above 'self actualization', for 'lightweight scripting.'

[Klathmon]

It's not as impossible as it sounds.

There are many JS engines which are extremely small compared to the big guys used in browsers. Most of them tend to grab a subset of the language and implement that.

For example, the creators of nginx created their own specialized engine called nginScript that runs JS for their stuff https://www.nginx.com/resources/wiki/nginScript/

There is even a javascript interpreter written in javascript which can be a good starting point to learn a bit how it works https://github.com/jterrace/js.js/

[jix]

BeRo did build a javascript engine from scratch on his own: https://github.com/BeRo1985/besen

From the copyright headers he worked on it starting in 2009 and had the first public release in 2014 (actually 2010, see comment below). He certainly worked on other stuff in between too. This is also not a toy implementation. While I have no idea how it compares to state of the art engines, it does feature a whole bunch of optimizations and a JIT compiler.

[aurelian15]

Well, the first public release of BESEN was in 2010:

https://delphigl.com/forum/viewtopic.php?f=13&t=9140

[d0m]

A toy javascript interpreter is quite easy. But a high-performance, production-ready engine is a totally different story.

[dubroff]

Anyone have a recommendation for a good place to begin, if I was interested in writing a toy javascript interpreter?

[d0m]

Friends of mine used "Create Your Own Programming Language" to get started learning about interpreters: http://createyourproglang.com

I personally learned with SICP (But reading this book isn't just about interpreter, it will make you a better programmer and blow your mind in so many different ways. I wouldn't say it's for experts only, but this isn't the kind of book that beginners would get excited about. However, if someone is serious about improving as a developer, I can't think of a better book): http://www.amazon.com/Structure-Interpretation-Computer-Prog...

Finally, (How to Write a (Lisp) Interpreter (in Python)) by norvig is a great read if you're getting started with interpreter: http://norvig.com/lispy.html

* The reason the two last links are lisp related is because writing interpreter in Lisp is really straightforward (Since the code is the AST). Similarly, if you wanted to learn about memory management, a language like assembler or C might be more suited than say Python.

[pmontra]

You can check this code https://github.com/espruino/Espruino/blob/master/README.md

I quote

"Espruino is a JavaScript interpreter for microcontrollers. It is designed to fit into devices with as little as 128kB Flash and 8kB RAM."

It could be a good example of a small js interpreter. I remember the author said to be 95% compatible with real js. That was a couple of years ago.

[WalterBright]

You can start with https://github.com/DigitalMars/DMDScript which is an open source (Boost licensed) JavaScript engine written in D.

[facepalm]

While at university I attended a "learn Scheme" summer course and it was taught by implementing your own Scheme interpreter (in Scheme). It is not that hard to implement a programming language, but making it perform well might be a completely different ballpark.