[HN Gopher] Roll your own JavaScript runtime, pt. 3
___________________________________________________________________
Roll your own JavaScript runtime, pt. 3
Author : danielskogly
Score : 66 points
Date : 2023-05-04 18:28 UTC (4 hours ago)
(HTM) web link (deno.com)
(TXT) w3m dump (deno.com)
| obpe wrote:
| JS has improved a lot over the years but I am not sure I would
| want it as the default scripting language for applications. JS is
| really only useful because it's the language you access the
| browser's API with. If you are creating a different kind of
| application and therefore don't need the DOM or other browser
| things then why JS at all? Having worked with Lua for some game
| mods, it seems like a better choice for an integrated language.
| Maybe a Rust inspired language would make a better fit for a
| modern DSL... insert XKCD comic about standards proliferation.
| giraffe_lady wrote:
| Lua is a better integrated language simply because that path is
| intended by its developers and directly documented, and its
| runtime is designed to be easy to couple to C. But nothing
| about its semantics make it better for that task than
| javascript. They are extremely similar except lua doesn't have
| stuff you would almost always want like basic string
| manipulation tools, regex, any array operations more
| sophisticated than loop.
|
| You can argue you don't _need_ those things, but their lack isn
| 't a feature either. If you're not coupling to C's memory model
| or if for some reason someone has already done the work of
| building and debugging the integration... you gain nothing by
| using lua over js.
|
| I've done professional work in lua and it's highly overrated
| imo. For integrated languages Tcl or janet is a better choice,
| unless your use case is extremely extremely simple and then
| forth is a better choice. The only time I would choose lua is
| if I'm integrating with C, the integration language tasks are
| very simple but _also_ requires coroutines. Lua 's coroutines
| are genuinely good.
| paulddraper wrote:
| Because Worse is Better [1]
|
| Lua is technically superior, but JavaScript is practically
| superior due to its ubiquitous platform the web browser.
|
| Similar but different to C "beating" Lisp.
|
| [1] https://en.wikipedia.org/wiki/Worse_is_better
| tmountain wrote:
| I strongly disagree. Lua somehow maintains a positive
| reputation, but it's extremely quirky and weird in many ways.
| It has some Perl-esque rough edges (#array for length), and
| some "let's be different" design decisions that are
| counterintuitive and unnecessary (arrays starting at the 1
| index instead of 0).
|
| JavaScript as it is today is a vastly more ergonomic and
| fluid experience, and I am saying this as someone that has
| written tons of both.
|
| The embedding experience with Lua is likely much more form
| fit than JavaScript (sandboxing, etc). I'm strictly speaking
| about syntax and language features.
| skybrian wrote:
| I think you might be underestimating browser compatibility.
|
| There are a lot of browser API's. They're portable, designed
| with security in mind (at least somewhat), usually well
| documented, reasonably easy to understand, and people already
| know them. So, even if it's not a browser, you may prefer
| JavaScript so you don't reinvent the relevant API's and there's
| less to learn.
|
| Deno itself is a good example of this.
| slmjkdbtl wrote:
| I love Lua but tbh I accept JS as the default scripting
| language, simply because it's ubiquitous, most runtimes are
| faster than or on par with Lua, and not harder to embed than
| Lua with stuff like quickjs. Also I don't think from language
| design perspective there's fundamental difference beyond
| syntax, metatable is pretty similar to prototype chain, JS has
| much more stuff you can argue it's bloated compare to Lua but
| you don't really pay for what you don't use.
| keb_ wrote:
| Speaking of Lua, does anyone know of a Lua implementation with
| filesystem access that is smaller than (or as small as) QuickJS
| (~800KB)?
| FascistDonut wrote:
| When/why would you want to do this? I went to pt. 1 but it didn't
| seem clear.
| NTARelix wrote:
| The content of the series describes creating something like the
| beginnings of a Deno alternative, upon which the reader could
| fully recreate Deno or Node.js. It seems to me that the core
| idea presented is "a JavaScript/TypeScript interface to Rust".
| The thing that most interests me about something like this is
| not making yet another alternative to Deno or Node.js, but the
| potential for adding a scripting language to an application or
| framework written in Rust. I'm thinking like Python scripting
| of Blender, Lua as a scripting/modding layer for a game engine,
| scripting of Tiled with JS, an Electron alternative using GTK,
| your own browser.
| TechBro8615 wrote:
| When you want to add a sandboxed scripting language to any
| system, you might implement something like this. For example, a
| multi-tenant web proxy that lets users script functions for
| transforming requests, or a game that lets users script the
| user interface elements, would be two valid use cases.
| emmanueloga_ wrote:
| sounds useful for sandboxing
| olliej wrote:
| This is not any kind of "rolling your own JS runtime". This is
| "use our framework to use v8 from rust". What an obnoxious title.
|
| v8 is a JS runtime. JSC is a JS runtime. SpiderMonkey is a JS
| runtime.
|
| All of these are embeddable and have usable APIs. If all you are
| doing, is linking to a JS runtime, and then using it, you aren't
| "rolling your own runtime".
|
| If you want to roll your own JS runtime go look at how the LibJS
| folk in serenity did it - they did it without corporate backing
| and despite that I believe LibJS is fairly complete even with the
| new draft language features, albeit lacking a decade or so of
| performance optimizations.
| jchw wrote:
| Yeah unfortunately as pessimistic as it seems I must agree,
| this title is disappointing to me. I'd love to see a series
| discussing the ins and outs of even just tiny segments of
| implementing ECMA262, as there's quite a lot of interesting
| nuance that has come up over the years.
|
| I guess the difference is runtime vs perhaps interpreter, but
| it's definitely ambiguous.
| [deleted]
| lucacasonato wrote:
| JS runtime != JS engine
|
| Runtime: - Chrome - Deno - Node - Bun
|
| Engine: - V8 - JSC - SpiderMonkey - LibJS
| paulddraper wrote:
| Yes, this is more like "Roll your own JavaScript environment"
| intelVISA wrote:
| I expected some interesting content and left with a "import v8:
| Cargo edition" 'tutorial' is this really a good look for the
| ailing Deno?
| rickbutton wrote:
| roll your own runtime does not imply to me `import runtime from
| "runtime";` but this seems to just be "include deno and use
| deno"?
| notamy wrote:
| This is using Deno as the glue between Rust and V8; it leaves
| many things to the end-user, such as stdlib implementation.
| This isn't quite the same as building it from scratch, but it's
| still building a good chunk of the runtime I think.
| [deleted]
___________________________________________________________________
(page generated 2023-05-04 23:00 UTC)