JavaScript is two languages: 1) JavaScript, the original assembly language of the internet, does not need new language features. 2) JavaScript, the front-end web development language is a fractal of infinitely many sub-languages that transpile back to ES5. The proposal, as I read it, is: Let's stop adding front-end web features to the assembly language; it doesn't get easier, better or faster if we change the underly…
This isn’t really true on a practical level any more. ES6 support is very widespread (97% of all web users according to caniuse.) That even includes module import syntax! There are still some new language features that need to be transpiled, but most projects do not need to worry about transpiling cost/let/arrow functions/etc. I mean even newer features like nullish coalescing and optional chaining are at 93-94% supp…
Should JavaScript be split into two languages?
161–170 of 324 posts
Re: Should JavaScript be split into two languages?
#162Earlier quoted context omitted.
From the new official WASM proposal: https://github.com/WebAssembly/js-string-builtins/blob/main/... "the overhead of importing glue code is prohibitive for primitives such as String, ArrayBuffer, RegExp, Map, and BigInt where the desired overhead of operations is a tight sequence of inline instructions, not an indirect function call" I guess the more elegant and universal stringref proposal is DEAD now !? https://gi…
Quote from https://wingolog.org/archives/2023/10/19/requiem-for-a-strin... We don’t yet have consensus on this proposal in the Wasm standardization group, and we may never reach there, although I think it’s still possible. As I understand them, the objections are two-fold: WebAssembly is an instruction set, like AArch64 or x86. Strings are too high-level, and should be built on top, for example with (array i8). The r…
And dealing with strings isn't fun in many other languages or runtimes or OSes.
e.g.1. C# "Strings in .NET are stored using UTF-16 encoding. UTF-8 is the standard for Web protocols and other important libraries. Beginning in C# 11, you can add the u8 suffix to a string literal to specify UTF-8 encoding. UTF-8 literals are stored as ReadOnlySpan objects" - https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
e.g.2. Erlang/BEAM/Elixir: "The Erlang string type is implemented as a single-linked-list of unicode code points. That is, if we write “Hello” in the language, this is represented as [$H, $e, $l, $l, $o]". The overhead of this representation is massive. Each Cons-cell use 8 bytes for the code point and 8 bytes for the pointer to the next value. This means that the 5-byte ASCII-representation of “Hello” is 5*16 = 80 bytes in the Erlang representation." - https://medium.com/@jlouis666/erlang-string-handling-7588daa...
Re: Should JavaScript be split into two languages?
#163Earlier quoted context omitted.
Quote from https://wingolog.org/archives/2023/10/19/requiem-for-a-strin... We don’t yet have consensus on this proposal in the Wasm standardization group, and we may never reach there, although I think it’s still possible. As I understand them, the objections are two-fold: WebAssembly is an instruction set, like AArch64 or x86. Strings are too high-level, and should be built on top, for example with (array i8). The r…
> Dealing with strings is not fun right now. And dealing with strings isn't fun in many other languages or runtimes or OSes. e.g.1. C# "Strings in .NET are stored using UTF-16 encoding. UTF-8 is the standard for Web protocols and other important libraries. Beginning in C# 11, you can add the u8 suffix to a string literal to specify UTF-8 encoding. UTF-8 literals are stored as ReadOnlySpan objects" - https://learn.mic…
Re: Should JavaScript be split into two languages?
#164> Regarding BigInt, the presentation states that “use cases never materialized.” Yet every language has either that or BigDecimal. Even if Google's frontend devs haven't found a use, there also exist JS devs outside of Google who certainly have found uses (though possibly more of them on the backend). Similarly, not every developer has a compilation step in their JS work. And there are places where you can't have one…
That part caught my attention too. It reminds me of the discussion to remove complex numbers from Go. Funny enough, compiler writers can't even imagine why you would want BigInt or Complex, because those aren't useful for writing compilers.
Re: Should JavaScript be split into two languages?
#165Re: Should JavaScript be split into two languages?
#166That said I also see the rationale for that. JS is already getting heavy and we should limit feature creep.
Re: Should JavaScript be split into two languages?
#167Re: Should JavaScript be split into two languages?
#168Earlier quoted context omitted.
That's nice. The implementation of a numerical tower is common in Lisps: https://en.wikipedia.org/wiki/Numerical_tower
Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be represented as integers, and integers which can't be represented as floats. This is where you say something about "exact" vs "inexact" as though that will hand wave it away.
btw, i just checked, typeof() no longer shows the difference between int and bigint. it did in the past if i remember correctly
Re: Should JavaScript be split into two languages?
#169Earlier quoted context omitted.
this is going beyond my level of experience, but i thought there can't be any such example because javascript is the only way. the difference is between code written in javascript which is fast of course and accessing js functions from WASM, which is slower. how much slower, i don't know. i also don't know how old that discussion is where i learned about this. so maybe it improved since. that would be good news. did…
> i thought there can't be any such example because javascript is the only way. the difference is between code written in javascript which is fast of course and accessing js functions from WASM That doesn't have to be true. Eventually WASM will get direct access to the full browser API, without going through JavaScript. The browser exposes a browser API to the JavaScript VM it hosts, so things like the DOM are availa…
Eventually WASM will get direct access to the full browser API, without going through JavaScript.
well, that is what i am waiting for. my point is that it's not the case yet, while the gp seemed to suggest that it's not needed because access through the host is available
Re: Should JavaScript be split into two languages?
#170Earlier quoted context omitted.
this is going beyond my level of experience, but i thought there can't be any such example because javascript is the only way. the difference is between code written in javascript which is fast of course and accessing js functions from WASM, which is slower. how much slower, i don't know. i also don't know how old that discussion is where i learned about this. so maybe it improved since. that would be good news. did…
Previously you said: > [...] go through the javascript host, which is slow And now you admit: > this is going beyond my level of experience [...] > how much slower, i don't know I guess people just repeat what they hear without questioning or understanding it, and then it becomes dogma. > did you mean there are snappy webapplications running in WASM? No. I meant that all existing web apps go through the "javascript h…
i am only talking about webapps running inside WASM. are there any WASM based webapps that are as fast as pure js webapps?