Axel Rauschmayer writes about JavaScript and ECMAScript features, proposals, and internals, and also authors free online books on the language.
HN commenters praise it as an excellent, long-running JavaScript blog that digs into language internals, and recommend his free books too.
In "traditional" recursion, each recursive call is pushed onto the function call stack. This means that your recursive solution will eventually run out of memory when the number of recursive calls is more than what the function call stack can handle.
e.g., consider the following recursive solution for calculating the sum of all positive integers up to a given `n`:
fn sum(n):
if n == 0:
return 0
else:
return n + sum(n - 1) // A
When n = 1000, your function call stack will have to hold ~1000 calls (fn(1000), fn(999), fn(998), fn(997), and so on...), before it's able to compute the sum. This is because the return statement in line A above, needs to keep track of the variable `n` from the calling function in order to be able to compute the return value. If only there was some way to eliminate that variable `n`...
That's where tail-recursion or tail-call optimization comes in:
fn sum_tail(n, pre_sum):
if n == 0:
return pre_sum
return sum_tail(n - 1, pre_sum + n) // B
fn sum(n):
return sum_tail(n, 0)
In this solution, the return statement at line B does not depend on any variable from the calling function (it simply passes that value on to next function call), and so the calling function can immediately be popped off the stack, saving stack space and making your solution more memory-efficient.
It's useful to know that whether any stack space can actually be saved, depends on whether your language of choice implements…
Take a look at ECMAScript quasi-literals -- they are solving the same problem that you're trying to address:
http://wiki.ecmascript.org/doku.php?id=harmony:quasis
http://www.2ality.com/2011/09/quasi-literals.html
I think they are going further because they can do auto-escaping. From what I see of your language, you still have to do html:"$var". What happens if you mis-type the prefix? Do you get incorrect escaping and a security hole? Some web devs won't even know what language they're writing in.
FWIW I don't think it's worth building an entire language around this concept. It's a feature, not a language. I think using Python plus a template language with good escaping basically solves the problem.
Also, it would be weird if html: and sql: are built in to the language -- that should be a layer on top of a smaller language (just like quasi-literals).
Also, a server-side language with special escaping support doesn't seem compelling, because these days you would want special escaping support on the client too. I'm not sure of the status of quasi-literals, but if they make it into V8 then Node.JS will have this feature on the server.
Having conducted over 100 interviews for JS positions, here is my advice.
- You have to start with ECMA5. 95% of new features in later versions can be transpiled back to it, and examining resulting code is usually the easiest way to comprehend them. Oh, how many candidates I've seen that talk about 'modern classes' with a flare and then can't explain prototypical inheritance at all. So, the best start is "JavaScript: The Definitive Guide, 6th Edition".
- Be very careful about what you read online. Blog platforms are full of script kiddies trying to feed you their misconceptions without a second thought. I generally only 'trust' two sources - Mozilla Developer Network and http://2ality.com/ by Axel Rauschmayer (I believe his books are mentioned in other answers too).
- Whenever you are faced with a particular library/technology - look from books/posts from their creators or someone associated with them.
As a programming teacher I think this is quite a fundamental thing to learn for new programmers. Even though lots of tutorials and books don't mention this explicitly people usually get an intuition for the difference after a while.
But in the beginning it's hard for people to grok an expression with a couple of nested expressions in it. Especially if there's some functions calls in there as well.
Axel Rauschmayer has a good page (1) on this topic as well. Quite dry, so less beginner friendly.
So what I like about Josh W Comeau's article is that it's easy to read with lots of examples and even an interactive widget.
Oh and about interactive visualization of expression evaluation: Thonny (2) does this real nicely for Python code. Excellent for beginners imo.
[1] https://2ality.com/2012/09/expressions-vs-statements.html
[2] https://thonny.org/
> Is CSS an "art" thing?
Certainly![0]
> Is it common for other developers to have issues with it?
Boy howdy it is! Like eight years of discussion[1] on vertically centering text in a div. It's all siegeworks-engineering[2] anyway, so no surprise that we ended up here.
I think at one point in time, poor Doug Crockford suggested actual versioning for things like javascript and CSS. The children shivered as though they had been visited by a ghost! And after brushing the chill aside, returned to our great undertaking of cramming as many different languages into a .js file as humanly possible.
[0] https://www.widewalls.ch/andy-warhol-piss-paintings/
[1] https://stackoverflow.com/questions/2939914/how-do-i-vertically-align-text-in-a-div
[2] http://2ality.com/2011/03/javascript-how-it-all-began.html
I love how simple and effective this is.
I'm also building a web-based literate programming environment called Starboard[1] that's probably a hundred times the amount of code (but then it has additional features such as top-level await, plugin, and Python support).
Consider supporting lit-html[2] literals instead of strings for HTML output, it works really well in notebook environments.
One more thing you can consider: a esm tagged literal that uses import(<data url of the code>), you can then use ES Module imports to dynamically load code. Here's a blog post about that approach [3]
[1]: https://starboard.gg
[2]: https://lit-html.polymer-project.org/
[3]: https://2ality.com/2019/10/eval-via-import.html