[HN Gopher] Should JavaScript be split into two languages?
___________________________________________________________________
Should JavaScript be split into two languages?
Author : em-bee
Score : 96 points
Date : 2024-10-26 15:27 UTC (7 hours ago)
(HTM) web link (devclass.com)
(TXT) w3m dump (devclass.com)
| tgv wrote:
| Fuck, no. Everyone's free to make better tooling, but don't
| standardize it. There's no point. It'll only lead to further
| fragmentation. Libraries and frameworks will be split between
| plain JS and whatever this new version will be called. Just
| freeze the language and be done.
| austin-cheney wrote:
| The problem expressed is fundamentally correct, but the proposed
| solution is a band-aid, which is worse than not solving the
| problem at all. The fix provides a long term change with short
| term benefits. Reliance on tooling will continue to make code
| instances are the progressively larger and slower until we arrive
| at this problem again. At some point JavaScript must become a
| professional language written by adults, people capable of self-
| organization and measurement, and not be the subject of fashion
| by people who aren't qualified to program in the first place.
|
| If performance and complexity really are the primary concerns
| then the language must stop pandering to children. We already
| know what high performance looks like. I wrote about it here:
| https://github.com/prettydiff/wisdom/blob/master/performance...
|
| If the goal really is higher performance and lower complexity the
| most desirable solution is to create a new language with forced
| simplicity directly in the image of JavaScript, where simple
| means less and not easy, and transition to that new language
| slowly over time. Yes, I understand Google went down this road in
| the past with Dart, but Dart solved for all the wrong problems
| and thus was dead on arrival. Instead the idea is to take
| something that works well and shave off all the bullshit reducing
| it down to the smallest possible thing.
|
| Forced simplicity means absolutely ignoring all vanity/stylistic
| concerns and instead only focusing on fewer ways of doing things.
| As an example consider a language that requires strong typing
| like TypeScript and thus thereby eliminates type coercion.
| Another example is operators that have a single purpose (not
| overloaded), single character, and no redundant operators.
|
| Will there be a lot of crying about vanity bullshit... yes,
| absolutely. Just ignore it because, you cannot reasonably expect
| to drive above 120mph on a child's tricycle. If people wish to
| offer their own stylistic considerations they should include
| performance metrics and explanations how their suggestions reduce
| quantity of operations without unnecessary abstraction.
| peutetre wrote:
| Better to focus on WebAssembly instead. Bring every language to
| the web.
|
| JavaScript for some scripting, any other language for bigger
| applications.
| em-bee wrote:
| good point. in a sense webassembly is that minimal very
| performant language. let javascript and typescript compile to
| webassembly, and you essentially got what is being proposed
| here
| sshine wrote:
| WebAssembly could replace JavaScript, the assembly language,
| once it has reached feature parity.
|
| But there's still far to go. Large parts of the browser API
| are still not directly available in WASM.
|
| I very much look forward to WASM reaching stability. It's
| very enjoyable to run Rust code in the browser.
| em-bee wrote:
| right, making those APIs accessible from WASM is something
| i am also waiting for.
| croes wrote:
| So you want more rights for code that's harder to read
| than obfuscated JS?
| xscott wrote:
| What parts are not available?
|
| WebAssembly can call arbitrary JavaScript through imports.
| You could literally provide an `eval` function if you were
| motivated to.
| em-bee wrote:
| direct access to the DOM for example without having to go
| through the javascript host, which is slow and makes DOM
| intensive applications impractical
| peutetre wrote:
| Or you can just draw to canvas to make the UI fast which
| is what Flutter does now:
|
| https://flutterweb-wasm.web.app/
|
| https://www.youtube.com/watch?v=Nkjc9r0WDNo
| prisenco wrote:
| Drawing to canvas means recreating the UI and all its
| wide-sweeping concerns, which is quite an undertaking.
| And even if it were accomplished in a central open source
| library like Flutter, that adds a considerable amount to
| the package size of any application. Acceptable (or even
| preferred) for certain applications but not for most.
|
| Providing access to an already proven DOM would be the
| better solution.
| xscott wrote:
| What would access to the DOM look like? WASM already has
| import and export (nearly) arbitrary functions. People
| keep saying it can't manipulate the DOM, but it clearly
| can. So, what's missing?
| kaba0 wrote:
| So throwing out literally 99% of what makes the web
| actually portable and useful?
|
| A random drawn rectangle is _not_ a UI, it's not
| accessible, not inspectable, not part of the de facto OS
| native toolkit.
|
| If all we wanted is a random cross-platform canvas
| element to draw onto from a vm, it could be solved in a
| weekend. There are million examples of that.
| xscott wrote:
| Can you give an example of anything anywhere that
| manipulates the DOM without using JavaScript? Because it
| seems to me that pretty much every web application is
| currently using the javascript host, and the well written
| ones are pretty snappy.
| em-bee wrote:
| 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 you mean there are snappy webapplications running in
| WASM? if you have any examples, i'd be curiuos to learn
| more.
| xscott wrote:
| 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 host", using JavaScript. So if any of them
| are fast enough, and some certainly are, the problem
| isn't the "javascript host".
| em-bee wrote:
| you are not answering my question. most existing webapps
| are not running inside WASM.
|
| i am only talking about webapps running inside WASM. are
| there any WASM based webapps that are as fast as pure js
| webapps?
| sshine wrote:
| > _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 available.
|
| Those things aren't available in other JavaScript VMs,
| like Node. (There's no DOM to interact with.)
|
| And they're not yet available in the WASM VM in the
| browser, either.
|
| The reason is that the WASM APIs/ABIs have not
| stabilised. It takes time to make right, but there is
| progress.
| em-bee wrote:
| _That doesn 't have to be true.
|
| 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
| davexunit wrote:
| All imports have to come from the host, which in the case
| of the web means they have to be expressed as JavaScript.
| Behind the scenes they could be optimized, though, and
| I've heard that JS/Wasm engines maybe already be doing
| this with well-known imports (think Math.sin).
| hn_throwaway_99 wrote:
| I commented this elsewhere, but the funny thing is that
| asm.js was the precursor to WebAssembly, and this proposal is
| essentially asking for asm.js back again.
| rafaelmn wrote:
| Did they solve GC and DOM access ? It's been years since it was
| "just about to happen" and I stopped paying attention in the
| meantime. But if it had that I agree - it would be ideal if JS
| was a legacy thing and a saner WASM first class language got to
| replace it.
|
| Keep the single threaded event loop approach but kill the JS
| semantics.
| peutetre wrote:
| Garbage collection is solved to the extent that host garbage
| collection is now available via WasmGC:
|
| https://developer.chrome.com/blog/wasmgc/
|
| https://v8.dev/blog/wasm-gc-porting
|
| But languages like C# want more features in WasmGC:
|
| https://github.com/dotnet/runtime/issues/94420
|
| No direct DOM access yet. You still have to use JavaScript
| glue code to get at the DOM.
| singularity2001 wrote:
| The problem is that they promised that the WasmGC would
| include the much desired access to JavaScript objects but
| now this crucial aspect is no longer part of it and
| postponed again.
| nikeee wrote:
| Actually I don't want DOM access and GC for wasm. At least
| not yet. It overcomplicates a lot and I simply cannot imagine
| that a GC can be one-size-fits-all languages.
|
| I want fixed-size buffer-backed structs for JS. Basically a
| DataView as a C struct. This would massively benefit interop
| and solve some shortcomings of DataView.
|
| There was a proposal for a binary AST for JS several years
| ago [1]. Why not just use that as JS0? It's separate and can
| offer new possibilities as well.
|
| [1]: https://github.com/tc39/proposal-binary-ast
| davexunit wrote:
| Wasm GC is shipped in stable releases of all major browsers
| except for Safari but that will be changing shortly if it
| hasn't already (my info is a few weeks old.) The important
| thing to note about Wasm is that all important functionality,
| such as access to I/O and the DOM, have to arrive in the form
| of host imports to a Wasm module. With this in mind, thanks
| to Wasm GC it is possible to do web UIs from Wasm by
| importing the relevant bits of the DOM API that the module
| needs. Projects like Hoot (Scheme) and Kotlin port are
| already demoing such things.
| sjrd wrote:
| > Projects like Hoot (Scheme) and Kotlin port are already
| demoing such things.
|
| And Scala.js has shipped it. [1] Although technically
| experimental, it has no known bugs and it has full support
| of things like manipulating DOM objects from Scala.js-on-
| Wasm code.
|
| [1] https://www.scala-js.org/news/2024/09/28/announcing-
| scalajs-...
| fny wrote:
| Assembly is not a language runtime. Even if you had WebAssembly
| as the core, you'd still need to compile JavaScript to
| WebAssembly, manage the GC, etc which all would still suffer
| from the performance implications mentioned in the article.
|
| Also... do you really think its wise to rewrite v8 to target
| WebAssembly?
| peutetre wrote:
| It already supports WebAssembly. All browsers do.
|
| Here's a demo of Dart and Flutter compiled to WebAssembly:
|
| https://flutterweb-wasm.web.app/
|
| WebAssembly enables you to use any language. And when you can
| use any language, why would you use JavaScript?
|
| Google has started migrating parts of Google Sheets to
| WebAssembly. They're compiling Java to WebAssembly and seeing
| a 100% performance increase:
|
| https://web.dev/case-studies/google-sheets-wasmgc
|
| Amazon has been migrating its Prime Video app from JavaScript
| to WebAssembly. They're compiling Rust to WebAssembly and
| they've seen increased performance and lower memory usage:
|
| https://www.amazon.science/blog/how-prime-video-updates-
| its-...
| wiseowise wrote:
| Still spreading your JS hate from thread to thread I see.
|
| > WebAssembly enables you to use any language. And when you
| can use any language, why would you use JavaScript?
|
| In which context? I'm doing Kotlin/Java/Rust/C++ for a day
| job and I'd rather die than use any of those instead of JS
| for my hobby/exploratory projects.
|
| The amount of bullshit I have to deal with in those
| languages from tooling to languages themselves is
| astonishing.
| RandomThoughts3 wrote:
| Then you add capability to hide the browser chrome and build
| close to native user experience and we will have truly looped
| the loop. Think about that: the browser as an intermediation
| ensuring resources are properly shared and each application is
| shielded from the others. Everything that's old is new again.
| /s
|
| On a serious note I don't see the point in turning browsers
| into an OS on top of the OS. I know it's some kind of Google
| wet dream so they can suck up even more data than they already
| do but still. If you want to ship applications, just do that.
| The sandboxing should be done at the OS level where it belongs.
| jokethrowaway wrote:
| Yes and no, there is a significant bundle size problem with
| wasm which is hard to fix.
|
| I'd rather we just move to native cross platform applications
| and stop using a document browser to build interactive
| applications.
|
| What's more likely is that all of this will probably be
| eclipsed by LLM and virtual assistants - which could be
| controlled by native apps with a dynamically generated GUI or
| voice.
|
| I think APIs exposing data and executing functions will
| fundamentally change what we think the web is.
| peutetre wrote:
| > _I 'd rather we just move to native cross platform
| applications and stop using a document browser to build
| interactive applications_
|
| Here you go. Do both native and wasm:
|
| https://avaloniaui.net/
|
| https://platform.uno/
|
| https://flutter.dev/
|
| Flutter example:
|
| https://flutterweb-wasm.web.app/
| ec109685 wrote:
| Not that please. The flutter example took 20 seconds to
| load and the scroll is super choppy.
|
| It's unfortunate there isn't a more native "app like" UI
| toolkit. Especially on mobile, web apps generally are bad
| and a lot of the reason is trying to shoehorn an app
| experience onto the dom.
| akira2501 wrote:
| > I'd rather we just move to native cross platform
| applications and stop using a document browser to build
| interactive applications.
|
| Go back to garbage "cross platform" UI toolkits and having to
| help users manage software dependencies on their machine? No
| thanks.
| wiseowise wrote:
| > I'd rather we just move to native cross platform
| applications and stop using a document browser to build
| interactive applications.
|
| Cool stuff, let's kill web for good.
| kaba0 wrote:
| Throwing out the baby with the bath water? There are millions
| of standardized APIs available in the browser that would be
| probably impossible to recreate in anything else due to
| failing consensus.
| sshine wrote:
| 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 underlying, slowly adopting and hard-
| to-optimize foundation.
|
| When you want a new language feature, add it to the fractal part
| that transpiles back to the part well-supported and highly
| optimized in existing runtimes. The only loss is that you need to
| transpile, so your build pipeline becomes non-trivial. But it's
| either "code assembly" or "get a modern build tool".
| anon7000 wrote:
| 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% support.
|
| At the end of the day, I would say tools like babel for
| transpiling are less and less important. Yes, you still use a
| bundler because the web has a lot of runtime constraints other
| native applications don't have (gotta ship a tiny bundle so the
| page loads fast), but it's better for the language features to
| be implemented in the VM and not just faked with more JS.
| sshine wrote:
| Interesting.
|
| I did assess the ES6 coverage of ~97% a month ago.
|
| I just evaluated that while it sounds high, 3% of people is a
| lot of people to cut off if your JavaScript is essential.
|
| E.g. Firefox sits at ~2.7% browser market share. (Not
| incidentally the part that doesn't support ES6, but it's a
| demography the size of my own.)
| Our_Benefactors wrote:
| > 3% of people is a lot of people to cut off if your
| JavaScript is essential
|
| These are probably the 3% that won't affect your business
| much. They're more likely to be on older hardware and also
| have less discretionary income. Or browsing on really weird
| hardware that is also unlikely to lead to a sale.
| silvestrov wrote:
| I really don't like it as it is difficult to debug code when the
| code that runs isn't the code I wrote.
| ratorx wrote:
| This is mostly a solved problem in regular compilers, and
| sourcemaps etc do currently exist for JS.
|
| I agree that the tooling/UI around this could be better, but by
| focusing on this approach, things like Typescript get better as
| well.
| wiseowise wrote:
| > sourcemaps etc do currently exist for JS.
|
| Are those being supplied with every website you use?
| ec109685 wrote:
| Are there debuggers that can single step over the transpiled
| bits so that it feels like the methods are implemented
| natively? Otherwise, it becomes a mess.
| sshine wrote:
| With the right debugging tools, transpiled alternatives to
| JavaScript are easier to debug than vanilla ES5.
|
| For example: TypeScript's sourceMap [1], Elm's time-travelling
| debugger [2], Vue.js DevTools [3], just to name a few I've
| tried. Especially well-typed languages tend to behave well at
| run-time once they pass type-checking. Or rather, I have not
| made enough front-end code to discover transpiler bugs.
|
| [1]: https://www.typescriptlang.org/tsconfig/#sourceMap [2]:
| https://elm-lang.org/news/time-travel-made-easy (2014 [3]:
| https://devtools.vuejs.org/
| normie3000 wrote:
| > With the right debugging tools, transpiled alternatives to
| JavaScript are easier to debug than vanilla ES5.
|
| So if I agree with GP then I just haven't found the right
| tooling yet?
| shermantanktop wrote:
| I started with your position (vanilla js 4ever!) and after
| being dragged into the world of transpilation via
| typescript/eslint/prettier/webpack/babel/etc I do agree
| that it's at least as easy. Not sure about "easier" but my
| debugging needs are not exotic. The painful part is
| initially setting up the toolchain.
| sshine wrote:
| If you're happy writing ES5, power to you.
| tredre3 wrote:
| > transpiled alternatives to JavaScript are easier to debug
| than vanilla ES5
|
| As easy, certainly. But how are they easier?
| sshine wrote:
| Because debugging better languages affords you more context
| and more tooling.
|
| Elm's debugger lets you step forwards and backwards in the
| application's state.
|
| TypeScript's type system lets you catch bugs before you run
| the code.
|
| Vue.js's DevTools extend the browser's with a component-
| based overview, so you can interactively see what's going
| on at a high level of abstraction. (I'm sure something
| similar exists for most frameworks similar to Vue.js, and
| possibly even frameworks made in vanilla ES5, I'm just
| picking one I've tried.)
|
| With vanilla ES5 you get interactive debugging.
| ninetyninenine wrote:
| No. Javascript should be split into 3 languages and html and css
| should be split into 20 languages.
|
| Seriously frontend is already the most fragmented and fast
| changing area of web there is. Don't split the language.
| ttoinou wrote:
| You wouldn't see much difference as a user of those tools. And
| if you're writing vanilla JS, you'd have less features creeping
| in over time. So it seems like you would benefit from this kind
| of change.
| ninetyninenine wrote:
| Yeah but if I change jobs or work on another project then I'd
| have to learn two standards.
| bitwarrior wrote:
| You didn't read the article.
| akira2501 wrote:
| > and fast changing area
|
| Who cares? If backwards compatability is maintained then this
| fails to have any impact on my experience as a developer. It
| sounds like the VM maintainers are busy making their own lives
| hell. Not my problem.
| wiseowise wrote:
| > Who cares?
|
| I do. Maybe if someone programs in one language it's okay for
| them to keep up with language changes, but if you have to
| constantly juggle multiple languages it becomes a real chore
| to stay up to date with every one of them.
| jas39 wrote:
| It's a good idea, but a better idea would be to make the browser
| a virtual machine running wasm. HTML, SVG and everything else
| could be implemented in wasm, and loaded from the cloud as
| needed.
| nephy wrote:
| WASM is slower than running JavaScript on V8 in almost all
| scenarios and will likely continue to be for a very long time.
| Also, many of us don't want a compile step.
| zb3 wrote:
| While I don't want any compile step either (js should stay),
| I'm actually confused by your statement.. are there any
| benchmarks? Are you saying that for example v86 would run
| faster without wasm?
| nephy wrote:
| I think that would probably fall outside the norm. My
| information might be outdated, but I was under the
| impression that JavaScript usually wins in most algorithm
| benchmarks because the JIT is so good.
| peutetre wrote:
| No, wasm has higher performance and lower memory usage. Here
| are two practical, real world examples:
|
| https://www.amazon.science/blog/how-prime-video-updates-
| its-...
|
| https://web.dev/case-studies/google-sheets-wasmgc
| jas39 wrote:
| That is a misconception; there is a cost of abstraction,
| although this cost may disappear if AI gets really smart.
| wiseowise wrote:
| > It's a good idea, but a better idea would be to make the
| browser a virtual machine running wasm. HTML, SVG and
| everything else could be implemented in wasm, and loaded from
| the cloud as needed.
|
| So now a huge swaths of use cases are going to be killed by
| this change. E.g. AdBlock, NewPipe and yt-dlp - how is that
| better? All of them (expect maybe AdBlock) rely on parsing
| incoming JS from YouTube which will be rendered obsolete by
| WebAssembly blob.
| righthand wrote:
| All this championing Javascript as a single language for front
| and back end work, now to be split for different use cases.
| Hopefully this is how Javascript dies if that is the route Google
| pushes it.
|
| There is already too much exhaustion around switching frameworks
| and paradigms in the JS world, but I guess everyone likes getting
| jerked around by corpos and evangelists these days.
| devjab wrote:
| We've run React for almost a decade now and the only major
| parts we've swapped have been react build with Vite. Angular
| has been even more stable since the switch to TS. As far as the
| frontend frameworks themselves changing massively, that's a
| different story, but it's not like C# didn't go from Windows
| .Net to Core/Framework to cross platform .Net, and so on for
| different language frameworks.
|
| On the Backend there are very few issues, outside of FFI only
| being in unstable for Deno I suppose, but you could frankly be
| running the same old Express API you did a decade ago and be
| perfectly fine.
|
| If you're burnt out on changes and keeping up with things I
| think the issue is mostly a "you" issue. You don't have to
| chase down the latest hypes or fads. In fact I think you almost
| never should.
| righthand wrote:
| I'm not chasing down hypes and fads, the new product person
| who wants to make a splash by rewriting the core app does.
|
| This is an incredibly disingenuous response. You maybe like
| the world this way. It doesn't mean there isn't room for
| change or improvement away from Javascript.
| nephy wrote:
| I'm really tired of this discourse. The JavaScript ecosystem is
| the lingua franca of the web. Furthermore, while a segment of
| the programming community has sat around complaining,
| JavaScript has gotten really good and continues to improve
| every passing year. Incremental progress is the key to making
| progress, not giant paradigm shifts.
| righthand wrote:
| Well drink a cup of java because it's not going away.
| wiseowise wrote:
| > There is already too much exhaustion around switching
| frameworks and paradigms in the JS world
|
| What's wrong with VanillaJS?
| nenadg wrote:
| > What's wrong with VanillaJS? Absolutely nothing, we all
| love it, and we also love things built upon that foundation,
| like TypeScript. But it's optional, and that's a good thing
| that some people miss to recognize. Therefore, they seek more
| standardization that 'should be enforced' by your Big Brand's
| top used product (ie. browser).
| wiseowise wrote:
| My point is that "framework fatigue" is a self-inflicted
| problem. Nobody forces you to use flavor of the week,
| VanillaJS and bog standard HTML/CSS are always there for
| you.
| righthand wrote:
| Work in a publicly traded company where people are moving
| things around for promotions sake. Then you'll see how
| forced you are to use the latest flavor of the week.
| People absolutely do force you.
|
| It's not just the flavor of the week frameworks, it's
| libraries and best practices. Want to work with dates? Do
| you use moment? Nope that's deprecated, what do you use?
| Which moment successor? How do you write react? Classes
| or functions? You can't use hooks with classes, so you
| better update to functions. On and on you run into a
| decision tree because of the shifting target of
| javascript. It causes a lot of churn to be migrating and
| updating to new systems, especially when the new hire
| can't help because they don't understand prototypal
| inheritance.
| bitwize wrote:
| JavaScript so wants to be Scheme. Can we just do Eich's original
| thing and put Scheme in the browser?
| peutetre wrote:
| WebAssembly enables that: https://www.spritely.institute/hoot/
| davexunit wrote:
| Heh thanks for dropping the link! The dream of the 90s is
| alive thanks to Wasm GC.
| hn_throwaway_99 wrote:
| I'd argue that other languages did this (or something similar) to
| great success, most notably Java.
|
| That is, the Hotspot VM was such a phenomenal engine that lots of
| other languages sprung up to take advantage of that: Closure,
| Scala, Kotlin, etc.:
| https://en.m.wikipedia.org/wiki/List_of_JVM_languages . Even with
| the Java language itself, syntactic changes happen much more
| frequently than VM-level bytecode changes.
|
| With an interpreted language like JavaScript, the dividing line
| is a little grayer, because the shippable code isn't bytecode,
| it's still just text. But it still seems to make sense to me to
| target a a "core", directly interpretable language, and then let
| all the syntactic sugar be precompiled down to that (especially
| since most JS devs have a compilation step now anyway). Heck, we
| basically _already did this_ with asm.js, the precursor to
| WebAssembly.
| supriyo-biswas wrote:
| It seems to me that wasm should just support the web/browser
| API instead of the current trampoline business; this way, JS
| build tooling can emit wasm files, which is similar to the
| example you use.
| hn_throwaway_99 wrote:
| What's old is new again :)
|
| asm.js came about because it was a very optimizable subset of
| JavaScript, then it was superseded by WebAssembly, then the
| proposal in TFA is basically asking for asm.js back, but
| perhaps the better answer is to make WebAssembly fully
| support all of what JS could originally do.
|
| This is perhaps why as I get older I sometimes feel like I
| want to get out of software development and become a goose
| farmer like that dude on LinkedIn - lots of times feels more
| like spiraling in circles than actually advancing.
| no_wizard wrote:
| I think it's much harder to make big leaps as a community
| with languages and other - relative to the technology stack
| as a whole - lower level concerns.
|
| Look at the stronghold grip of C/C++ and how long it's
| taken Rust to gain a meaningful foothold in those realms
| for example.
|
| Google wanted to flat replace JS once already, that was the
| entire origin of Dart. They only pivoted to the cross
| platform mobile framework as its primary target after it
| failed to gain traction as a standard
| pjmlp wrote:
| Actually in regards to Dart it is a more subtle.
|
| Dartium was cancelled and AdWords team, having just
| migrated from GWT to AngularDart, saved the Dart team.
|
| Eventually many left the team.
|
| Somewhere at Google, Flutter started and when they
| decided to replace JavaScript on their original design,
| they decided to reach out to the Dart team.
|
| So Dart got a new purpose in life, being Flutter's
| language.
|
| In this process it was rebooted from dynamic language,
| into a static type one, having JIT and AOT toolchains.
|
| How long Flutter, and by association Dart, remain
| relevant remains to be seen.
| pjmlp wrote:
| asm.js came about because Mozzilla refused to adopt PNaCL,
| which is kind of ironic given the existing Firefox market
| share a decade later.
| adjav wrote:
| PNaCL was essentially "let's shove LLVM into every
| browser and make it a mandatory part of the web", which
| somehow seems even worse than "let's shove the JVM into
| every browser and make it a mandatory part of web"
| pjmlp wrote:
| Given Google's power a decade later, with Safari left as
| the only non-Chrome clone with market relevance, it
| hardly makes a difference.
|
| Additionally we already have LLVM all over the place,
| alongside JVM and CLR, it is the most deployed compiler
| infrastructure with contributions at the same level as
| the Linux kernel.
| no_wizard wrote:
| They're already moving it that way, it's not like it isn't
| without complexities and such either. WASM isn't the silver
| bullet everyone seems to cling to.
|
| I feel like the WASM fervor has more to do with the fact
| people don't enjoy using Frontend tools or JavaScript etc. vs
| looking at the actual utility tradeoffs
| singularity2001 wrote:
| >> WASM isn't the silver bullet everyone seems to cling
| to.
|
| And it isn't the silver bullet exactly for the reason that
| it's horribly complicated to access normal JS objects
| including strings.
| xscott wrote:
| You're two library functions away from having it easy:
| Copy from JavaScript to WebAssembly: Use
| TextEncoder to convert a JS String to Uint8Array
| Copy the bytes from the Uint8Array to WemAssembly.Memory
| Copy from WebAssembly to JavaScript: Copy the
| bytes from WebAssembly.Memory into a Uint8Array
| Use TextDecoder to convert from Uint8Array to JS String
|
| JS Strings are pretty much always going to be "rope data
| structures". Trying to provide anything other than copy-
| in and copy-out is going to expose implementation details
| that are complicated as fuck and not portable between
| browsers.
| singularity2001 wrote:
| 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://github.com/WebAssembly/stringref/blob/main/propos
| als...
|
| I don't really mind, as it keeps the wasm bytecode
| cleaner.
| xscott wrote:
| Thank you for the links. To the extent I understood it
| from a quick reading, it all looks like stuff you could
| get with the existing import/export mechanisms. I would
| choose (modified) UTF-8, but I understand why UCS16 is
| always going to be around.
|
| I agree about keeping wasm bytecode cleaner. The core
| plus simd stuff is such a great generalization of the ARM
| and X86 CPUs we mostly use. The idea of gunking it all up
| with DOM related stuff is distasteful.
| davexunit wrote:
| 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 requirement to support fast WTF-16 code unit access
| will mean that we are effectively standardizing
| JavaScript strings.
|
| I really like stringref and hope the detractors can be
| convinced of its usefulness. Dealing with strings is _not
| fun_ right now.
| robocat wrote:
| > 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<byte>
| 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...
| davexunit wrote:
| Okay? Is this an argument in favor of doing nothing?
| xscott wrote:
| "trampoline business"?
|
| It supports nearly arbitrary imports of anything you want.
| How much more flexibility do you need? You could provide an
| `eval` function to run arbitrary code with a small amount of
| effort.
|
| Is the problem that Emscripten and/or Rust haven't laid it
| all out on a platter?
| dmart wrote:
| I've been hearing about access to DOM APIs from WASM for
| years now. Does anyone know why this is such a difficult
| problem?
| xscott wrote:
| Because it's already solved from day one and people keep
| repeating that it's a problem anyways.
|
| Anything you can do in JavaScript, including access to the
| DOM, can be put into a JavaScript function. You can import
| that function into a WebAssembly Module, and you can use
| WebAssembly Memory to transfer large or complicated data as
| an efficient side channel. It all works.
| hu3 wrote:
| Could you link an ergonomic example? I have cemented in
| my memory that DOM access in WebAssembly is not trivial
| and I suspect others too.
|
| This is what StackOverflow tells me (2020):
|
| > Unfortunately, the DOM can only be accessed within the
| browser's main JavaScript thread. Service Workers, Web
| Workers, and Web Assembly modules would not have DOM
| access. The closest manipulation you'll get from WASM is
| to manipulate state objects that are passed to and
| rendered by the main thread with state-based UI
| components like Preact/React.
|
| > JSON serialization is most often used to pass state
| with postMessage() or Broadcast Channels. Bitpacking or
| binary objects could be used with Transferrable
| ArrayBuffers for more performant messages that avoid the
| JSON serialization/deserialization overhead.
|
| This feels like "we can have DOM access at home" meme.
| Deukhoofd wrote:
| They wanted to implement a typing system first so they
| could transfer complex types with a strict contract first,
| as large parts of DOM management would benefit enormously
| from that, and it would be far better to design an API
| around. This system has been stuck in different iterations
| for years.
|
| The current active proposal for it is the Component Model:
| https://component-model.bytecodealliance.org/design/why-
| comp....
| halostatue wrote:
| The BEAM VM (Erlang, Elixir) does this with what's called "Core
| Erlang", used as lower-level targets before compiling to the
| BEAM primitives.
|
| https://blog.stenmans.org/theBeamBook/#_compiler_pass_core_e...
| thayne wrote:
| > because the shippable code isn't bytecode,
|
| But what if it was?
|
| What I would like to see is:
|
| - a bytecode "language" that roughly corresponds to Javascript
| semantics, and that is what the engines interpret (and JIT
| compile)
|
| - browsers still include a compiler to compile JS sourcecode to
| the bytecode. Possibly wasm could work, although it would need
| a lot more functionality, like native support for GC, and DOM
| access, etc.
|
| - browsers include a disassmbler/decompiler to improve
| debugging the bytecode
|
| Then simple sites, and development can use plain JS source, but
| for higher performance you can just deploy the pre-compiled
| bytecode.
| alpaca128 wrote:
| I am certain this would mainly add problems while not
| improving performance as websites would just add more stuff
| on top until it's again on a barely tolerable level, for both
| the user and the developer who know probably has to manage
| yet another super simple, blazingly fast tool to keep
| everything running.
| kmeisthax wrote:
| Wouldn't it make more sense for some of these features to be
| implemented as a desugaring step in the runtime itself? i.e. if
| implementing them directly as new language features doesn't make
| sense, then preprocess them away before executing the scripts.
| You could even do this for past features that made it into
| ECMAScript but haven't turned out to be useful, instead of
| ossifying a specific moment in time's tooling.
| wrs wrote:
| If there's still going to be a standard JSSugar, yes, seems
| like it should be desugared in the runtime. On the other hand,
| if we want to make it easier to fragment the high-level
| language into incompatible sugared versions, this seems like
| the way to go. (Hard to believe that would be the TC's goal.)
| gary_0 wrote:
| > Wouldn't it make more sense for some of these features to be
| implemented as a desugaring step in the runtime itself?
|
| I think if it was that simple, it would be done that way
| already (maybe it is, for some features). Two big arguments for
| doing the "desugaring" offline are the (1) speed, and (2)
| security of the browser. Those two things also conflict
| somewhat if addressed on the client, since faster but more
| complex compiler code increases the surface area for potential
| exploits.
|
| But if you do this compile step offline, you don't need to
| worry about compromising the performance or security of the
| browser.
| sshine wrote:
| > _features to be implemented as a desugaring step in the
| runtime itself_
|
| The problem is distributing the runtime(s). By having
| developers transpile to a small core, anyone can freely invent
| new language features without waiting for the rest of the
| internet to download support for them.
| 3np wrote:
| Why wouldn't you take the complexity and performance hit
| involved once at buildtime rather than offloading it to the
| client at runtime?
|
| If you read the original slides from the proposers, they're
| presenting a framing where there is an inherent tension between
| "serving the user" and "helping the developer". They argue that
| there is too much of the latter, and that a formalized
| splitting should push more to the former.
|
| From an end-user perspective, it definitely makes more sense
| that the js doesn't have to be transformed locally before it
| can interpreted. I think your suggestion is not compatible with
| the motivations of the proposal.
| singularity2001 wrote:
| This is a very good at important point:
|
| JS0 should be a subset of current JS
|
| JS1 should be current JS
|
| JsSugar should be current JS plus future features
| ec109685 wrote:
| If it's not implemented as a built-in feature of the browser,
| wouldn't half the internet break if features were removed that
| people were counting on?
| LudwigNagasena wrote:
| It should have been split into JS and Wasm. Instead they decided
| to make Wasm a second-class citizen without web API access.
| habosa wrote:
| If this happened then JavaScript would be split into 20+
| languages, one for each popular compiler. There would be nothing
| stopping a tool maker from adding their favorite language
| features even if no other compiler ever adopted them. That would
| be a disaster.
| jefftk wrote:
| Outside of browsers this is already how it works. Nothing is
| stopping LLVM versus GCC from adding their favorite language
| features, but it's not a disaster.
| wiseowise wrote:
| > Nothing is stopping LLVM versus GCC from adding their
| favorite language features, but it's not a disaster.
|
| It is a disaster the moment you try to run same code on
| different platforms.
| LatticeAnimal wrote:
| In many ways this has already started happening. TS has enums,
| Svelte has runes, React has jsx. None of these features exist
| in JS, they are all compile-time syntax sugar.
|
| While it is admittedly confusing to have all these different
| flavors of JS, I don't think this proposal is actually as
| radical as it seems.
| mircerlancerous wrote:
| Sounds like the presenters are assuming that everyone must be
| using JS in the same way they are. As someone who prefers to work
| in VanillaJS, I'm already frustrated by all the language changes
| being forced upon me. So maybe I agree with them that fewer
| changes should be made, but for completely different reasons. I'd
| rather them work on API improvements so that web apps get closer
| to parity with native apps. All this other talk is pointless
| while web apps remain second class IMO
| dudus wrote:
| I think the proposal is actually good for people like you.
|
| You can choose to just work with the core and maybe a minimal
| sugar library. Which will probably be faster and don't include
| "all the language features that were forced upon you".
| tightbookkeeper wrote:
| This is not what happened in C vs C++.
| anon7000 wrote:
| What do you mean forced upon you? There is no requirement for
| you to use new features. If you do, it's because you or your
| team thinks it's more convenient -- and it really is! map,
| filter, arrow functions, scope improvements with const/let,
| etc. are major language improvements. So is null coalescing and
| optional chaining. You don't have to use them, but they do make
| JS more straightforward to work with.
| ojosilva wrote:
| I think "forced upon" could also read as:
|
| - at work they expect me to write code with the latest
| features
|
| - my colleagues write code with the latest features and I
| have to review/extend/build upon using the same style
|
| - the community, books, copilots, LLMs, libraries, tooling
| are "forcing" all that new stuff upon me
|
| - etc.
| no_wizard wrote:
| One of the examples given makes sense, since Symbol.specie messes
| with prototypical inheritance and is likely hard to secure as a
| result because that touches so much of JS as a whole.
|
| BigInt failing to materialize I think has more to do with
| ergonomics around it, they're a bit unwieldy and there aren't
| able to be used with the built in Math object functions.
|
| They also have zero JSON support out of the box which is a huge
| miss.
|
| Honestly it should have been roadmapped to replace the built in
| Number type
| ossobuco wrote:
| Can't replace Number with BigInt as BigInt is orders of
| magnitude slower on certain operations. Try to do bitwise
| operations with BigInt, you'll see what I mean.
| no_wizard wrote:
| Hence roadmapped. You can't today, certainly, it also can't
| represent floating point numbers or be used with the Math
| object as noted.
|
| But the idea is that it should have been proposed with a
| roadmap of what it would look like to have it eventually
| supplant Number
| nephy wrote:
| The US government needs to fast track breaking up Google asap.
| Chrome needs to be torn from their festering lich hands, so that
| the web can be free of their self serving, and frankly bad,
| proposals.
| mdaniel wrote:
| Out of curiosity, which of the fragments of Google would you
| expect to take ownership over that codebase?
|
| I had always imagined that if the DoJ took any action it would
| be to cleave the ad business away from Google. Although if they
| went so far as to take action against GCP I bet Amazon, Amazon
| Marketplace, and AWS would start to get sweaty palms
| TheRealPomax wrote:
| "ECMA TC39", not "Emca TC39". Also, looks like a bad markup link
| for TC39. Also note that it's either "co-authored by Mozilla,
| Apple, Moddable and Sony" or "authored by Guo along with others
| from Mozilla, Apple, Moddable and Sony", but directly related to
| that statement, that makes this "not a Google proposal" but
| clearly an "industry proposal" if it has Mozilla and Apple buy-
| in.
|
| Also, "the proposed solution is not to backtrack on existing
| features" makes very little sense. If you're going to split
| something into core and "compiles down to core", then a LOT of
| features can be moved out of core because they're just
| (definitely worth keeping, but not necessary in _core_ if that
| split were made) convenience APIs.
| PeterWhittaker wrote:
| > ECMA not Ecma
|
| Incorrect: https://ecma-international.org/about-ecma/history/
| yakshaving_jgt wrote:
| > 1995 - Brendan Eich reads up on every mistake ever made in
| designing a programming language, invents a few more, and
| creates LiveScript. Later, in an effort to cash in on the
| popularity of Java the language is renamed JavaScript. Later
| still, in an effort to cash in on the popularity of skin
| diseases the language is renamed ECMAScript.
| mintplant wrote:
| Hell yes. I've been advocating for this for years. From an
| engine-implementer perspective, full-fledged JavaScript is just
| too hard to make both _fast_ and _secure_.
| dimal wrote:
| I think I understand the argument but this sounds like it would
| make things worse. The argument that new features almost always
| make the language worse doesn't hold true from my perspective as
| a developer. (I could imagine the perspective of a language
| implementor being very different.)
|
| I like that JavaScript now has modules/imports, destructuring,
| Proxies, async/await, etc. These were all new features at one
| point, But yeah, why did Symbol.species get in? Seems like it's
| to enable some odd subclassing pattern? I'm an anti-OOP zealot,
| so my hot take would be that maybe OOP subclassing is
| unnecessarily complex already, so stuff like that shouldn't make
| it in. We got the OOP syntactic sugar, which is enough. Stop
| there.
|
| How much of the extra complexity is from stuff like that that is
| rarely used? Maybe we just need to be a lot more conservative
| about what makes it in, but stopping changes and forcing
| everything into more tooling complexity is not the direction I'd
| like to go in. We need to reduce tooling, not increase it.
| zb3 wrote:
| Why JS0 and not wasm? Why is wasm so damn limited?
| singularity2001 wrote:
| Why is wasm so damn limited?
|
| After watching it evolve for many years my conclusion is either
| politics or it being run by the wrong people who think they
| literally need to invent the whole world (in component model)
| before they can give us basic string objects. No, wasm string
| objects were an independent feature in experimental Chrome for
| a while but they got removed again. Wasm structs are beautiful
| without the component model but useless because they can't be
| read or written in JS.
| Kwpolska wrote:
| > 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, e.g. in the
| browser console. Develop the language instead of tons of
| incompatible tools.
| nephy wrote:
| I literally use BigInt on the backend every single day at work
| lol.
| 3np wrote:
| This stood out to me as well. Proper decimal type would be my
| #1 missing language feature, seconded by a standardized runtime
| implementation of the same.
| xscott wrote:
| 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.
| Kwpolska wrote:
| The problem with Google compiler developers is that they will
| do a search of the google3 repository, find no uses (because
| Google doesn't do any advanced math, for example) and declare
| the language feature to be useless.
| Timwi wrote:
| Which is ironic because I use Google Sheets a lot and
| occasionally run into problems when it doesn't support
| BigInt calculations. Sheets is the best excuse Google has
| for keeping BigInt support in the language.
| Kwpolska wrote:
| Excel does not support BigInt either, so Google has no
| reason to implement it in their cheap imitation.
| em-bee wrote:
| one contributor to the pike programming language when asked
| why he took the effort to optimize syntactic sugar responded:
| so that pike users can write simple code and still have it
| run blazingly fast.
|
| in pike, bigint and int are integrated in such a way that the
| transition is automatic. there is no overflow but as long as
| the values fit in an int, that is used internally to keep the
| code fast.
| xscott wrote:
| I used LPC a long time ago on an LP Mud, so Pike has always
| had a fond spot in the back of my mind, even if I don't use
| it now.
|
| However, that works for int and bigint, but Number (double
| precision) can represent numbers that BigInt can not, and
| BigInt can represent numbers which Number can not. There
| isn't a graceful way to automatically promote/degrade one
| to the other in all cases, and a silent conversion will do
| the wrong thing in many cases.
| em-bee wrote:
| heh, yeah, that's where i started too. i don't know how
| or even if LPC did it, but in pike the transition really
| is seamless. give it a try. as a naive user i can't even
| tell the difference (you can see it though if you compare
| typeof(1) vs typeof(20000000000000000000) (i hope that
| number is big enough))
| the-smug-one wrote:
| That's nice. The implementation of a numerical tower is
| common in Lisps:
| https://en.wikipedia.org/wiki/Numerical_tower
| xscott wrote:
| 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.
| em-bee wrote:
| that's not what pike is doing though. int and float are
| still kept separate.
|
| btw, i just checked, typeof() no longer shows the
| difference between int and bigint. it did in the past if
| i remember correctly
| dboreham wrote:
| That's a general problem: languages end up having features
| that are only useful for writing compilers, and vice versa.
| SigmundA wrote:
| Would help if it worked with JSON by default.
| davexunit wrote:
| Yeah it was really concerning to hear someone from Google
| saying that BigInt doesn't have a use case. It is both used and
| important!
| belter wrote:
| https://news.ycombinator.com/item?id=41936300
| dang wrote:
| Thanks--that thread had two comments, which I've merged hither
| since the current thread is ongoing.
| dang wrote:
| The proposal was submitted here but didn't get much attention.
| Are there other threads?
|
| _Language Evolution: Problems, and What Can We Do About It?_ -
| https://news.ycombinator.com/item?id=41795190 - Oct 2024 (1
| comment)
| itsgabriel wrote:
| https://news.ycombinator.com/item?id=41764825
| hoppp wrote:
| I use bigint all the time. Not adopted? Its not true.
| jauntywundrkind wrote:
| This sounds like a crock of shit.
|
| No, it won't be faster, if you only optimize a lesser language.
| If you have higher level code running your optimizer can do more
| than if it only has a low level version.
|
| No, it won't be more secure. Js0 might be more secure, but if we
| sites all run any of dozens of different tools those tools are
| going to be creating the vulnerabilities. It's shifting where
| security issues occur, and creating more of them.
|
| I'm terrified this could happen. JS has gotten so much better
| over time. We are so close to being able to not need transpilers.
| This sounds like such an absurd cop out for browsers to say, meh,
| we just don't want to do the work to implement. Being so close &
| then saying, sorry, you must use big toolchains to develop for
| the web is a monstrously bad future.
| mirekrusin wrote:
| I don't understand the problem? If v8 wants to split into
| frontend (sugar, transpiled) and backend language (es5 + few
| things probably; runtime engine proper), they can just do it, no?
| chunkyguy wrote:
| > The tooling idea is particularly appropriate for JavaScript
| since many developers actually code in TypeScript and rely on
| compilers such as Babel, Webpack or the TypeScript compiler to
| output JavaScript.
|
| Hot take
| wiseowise wrote:
| Add structs/value types, pattern matching and we can freeze the
| language until end of days.
| allenap wrote:
| Split it into a thousand pieces and send each to separate,
| distant stars. Put three in a Phantom Zone.
| Timwi wrote:
| I would like to see an in-depth treatise explaining why existing
| bytecode VMs (LLVM, JavaVM and Ecma CLR) were never seriously
| considered for the world of browsers. These VMs already exist for
| numerous platforms, have been optimized to death, already have
| plethoras of languages that compile to them, and beside JavaVM
| are open source (Ecma CLR exists in the Mono project). I've
| looked at WebAssembly and I don't understand why it needed to be
| reinvented from scratch and why it needs to be so limited. We
| could already be writing web code in Rust, Java, C#, Python, and
| heck even Haskell, if we had just done that. I know that I'm
| skipping over the engineering effort required to make this happen
| but I get a sense that the engineering effort is not the
| stumbling block. I want to know the details of what is.
| kaba0 wrote:
| Java is as open-source as it gets (it's reference
| implementation, OpenJDK, has the same license as the linux
| kernel)
|
| And it was used by some browsers, there was just no consensus
| between different vendors due to politics. The problem largely
| solved itself by.. only one vendor remaining, chromium.
| simonw wrote:
| My guess is that none of those bytecode VMs were designed with
| the explicit goal of running untrusted code at global scale in
| a rock-solid sandbox.
|
| If anything, I expect those existing VMs to slowly be replaced
| by WebAssembly due to how crucial and complicated that very
| specific sandbox requirement is - and how useful that is once
| you have it working reliably.
|
| Personally I never want to run untrusted code on any of my
| computers outside of a robust sandbox. I look forward to a
| future where every application I might install runs in a
| sandbox that I can trust.
| koito17 wrote:
| "Secure Java" is something I recall hearing decades ago. No
| idea if it still exists.
|
| The more important thing to consider, however, is the fact
| that CLR, JVM, etc. provide _internal memory safety_ whereas
| Wasm runtimes don 't.
|
| e.g. a C program that goes sufficiently out of bounds on an
| array is guaranteed to segfault in the C runtime, but that
| runtime error does not necessarily occur on a wasm target.
| That is to say, the program in the sandbox can have totally
| strange runtime behavior -- still, defined behavior according
| to wasm -- although the program has undefined behavior in the
| source language. In the case of JVM languages, this can't
| really happen.
| mlinksva wrote:
| SecurityManager? Java's current direction (using the word
| "integrity" rather than "security", but seems relevant)
| looks interesting to me
| https://news.ycombinator.com/item?id=41520246
| neonsunset wrote:
| NIH and CIL is probably an ultra-overkill for browser-based
| scenarios. It implements a complex type system with all sorts
| of high-level features that significantly complicate the
| runtime/compiler. It makes it drastically easier to _target_
| but not to write an implementation.
|
| I'm not a huge fan of WASM but it's easy to see that the
| authors would clearly not want to leave control in the hands of
| Microsoft or Oracle (and as a result all of us are hostages to
| Google instead because of evil that is Chromium).
|
| https://ecma-international.org/publications-and-standards/st...
| dboreham wrote:
| They were. Lots of reasons why it turned out how it turned out.
| Basically a local minimum in the gradient descent. Computers
| were much slower is one reason. JVM wasn't open source at the
| time is another. NIH is another 100 reasons.
| koito17 wrote:
| What disqualifies "the JVM" (usually referring to HotSpot
| implementations) from being considered open source? Are you
| talking about OpenJ9 or something else?
| Izkata wrote:
| https://cybercultural.com/p/1995-the-birth-of-javascript/
|
| > As told in JavaScript: The First Twenty Years, Brenden Eich
| joined Netscape in April 1995.
|
| > [..]
|
| > However, Eich didn't think he'd have to write a new language
| from scratch. There were existing options available -- such as
| the research language, Scheme, or a Unix-based language like
| Perl or Python. So when he joined, Eich "was expecting to
| implement Scheme in the browser." But the increasingly
| fractious politics of the software companies of the day (it
| was, basically, everyone against Microsoft) soon saw the
| project take a more creative turn.
|
| > On 23 May 1995, Sun Microsystems launched a new programming
| language into the world: Java. As part of the launch, Netscape
| announced that it would license Java for use in the browser.
| This was all well and good, but Java didn't really fit the bill
| for the web. Java is a general-purpose programming language
| that promised Write Once, Run Anywhere (WORA) functionality,
| but it was too complicated for web designers and other non-
| programmers to use. So Netscape decided it needed a scripting
| language, which was a trendy term at the time for a smaller,
| easier to learn programming language.
|
| There's a whole lot more interesting stuff but I think that
| part directly answers most of what you're wondering.
| ameliaquining wrote:
| A core requirement of WebAssembly was that (ignoring I/O for
| the moment and considering only the computational core) you
| should be able to run arbitrary existing code on it, and the
| effort involved in getting it working should be comparable to
| porting to a new architecture, _not_ to a new programming
| language. What this particularly meant, in practice, was that
| it needed to be a good compilation target for C and C++, since
| most code is written either in those languages or in
| interpreted languages whose interpreters are written in those
| languages. (It also needs to support languages that 's not true
| of, like Go, Rust, and Swift, but once you've got C and C++,
| those languages don't pose major additional conceptual
| difficulties.)
|
| The JVM and CLR are poor compilation targets for C and C++,
| because those languages weren't designed to target those
| runtimes and those runtimes weren't designed to run those
| languages. (C++/CLI isn't C++.) It's possible to get something
| working, and a few people have tried, but you run into a lot of
| impedance mismatches and compatibility issues. I think you
| would see people run into a lot more problems trying to get
| their code running on the JVM or CLR than they in fact run into
| trying to get it running on WebAssembly. (Though I think the
| CLR is less bad about this than the JVM.)
|
| As for the idea of using LLVM bitcode as an interchange format,
| we don't have to guess how that would have gone, because it was
| actually tried! Google implemented this in Chrome and called it
| PNaCl, and some sites and extensions relied on it for a while.
| They ultimately withdrew it in favor of WebAssembly. I don't
| understand all the reasons why it failed, but I think part of
| the problem is that it ran into a bunch of "the spec is
| whatever LLVM happens to do" type issues that were real
| problems for would-be toolchain authors and made the other
| browser vendors (including Apple, LLVM's _de facto_ primary
| corporate sponsor) reluctant to support it. WebAssembly has a
| relatively short and simple standard that you can actually
| read; writing a WebAssembly interpreter is an undergraduate
| exercise, though of course writing a highly performant one is
| much more work.
|
| Also, as far as I can tell, LLVM hasn't at all been optimized
| to death for the use case of runtime code generation, where the
| speed of the compiler is about as important as that of the
| generated code. The biggest dynamic language I know that uses
| LLVM is Julia, which is a decently big deal, but the
| overwhelming majority of LLVM usage is for ahead-of-time
| compilation of languages like C, C++, Swift, and Rust.
|
| On a bigger-picture note, I'm not sure I at all understand why
| adopting an existing bytecode language would have made things
| easier. Yes, it would have been much easier to reuse existing
| Java code if the JVM had been adopted, or to reuse existing C#
| code if the CLR had been adopted, but those options are
| mutually exclusive; the goal was something that would work at
| least okay for _all_ the languages. Python doesn 't have a
| stable bytecode format, and Rust and Haskell compile to LLVM
| bitcode (which LLVM has no problem lowering to WebAssembly
| since WebAssembly was designed to make that straightforward),
| so I don't see how those languages are in any way disadvantaged
| by the choice of WebAssembly as the target bytecode language
| instead of some alternative.
|
| Or are your concerns about I/O? That's a bigger can of worms,
| and you'd need to explain how you imagine this would work, but
| the short version is that reusing the interfaces that existing
| OSes provided would not have worked well, because the browser
| has a different (and in many ways better) security model.
| neonsunset wrote:
| This is not true. CIL could be an excellent compilation
| target for C++ and was quite literally made with that in
| mind. C# was inspired as much by C++ as it was by Java. And
| CLR back then was made with consideration of C++/CLI, which
| exists even today. You can't effectively express C++ code
| with JVM bytecode, you absolutely can with CIL. You can even
| express most of Rust's generics with CIL nowadays, retaining
| monomorphization, save for zero-sized structs and other edge
| cases.
| nitwit005 wrote:
| None of them started out with web security in mind.
|
| Look at the Java bytecode, and you'll see it features such
| things as a goto with an arbitrary offset:
| https://en.m.wikipedia.org/wiki/List_of_Java_bytecode_instru...
|
| They had to build a verifier that attempts to ensure the
| bytecode isn't doing anything bad. That proved to be fairly
| difficult, and comes at a considerable cost.
| DidYaWipe wrote:
| But it's not as if security concerns are specific to the Web.
| Look at the vulnerabilities found in CPUs over the last
| decade or so. Security is necessary no matter what the
| delivery medium, so I don't see why this is a rationale for
| reinventing the wheel.
| nitwit005 wrote:
| They genuinely spent years trying to make Java more secure
| for the web. That was entirely new effort.
| neocon4life wrote:
| JavaScript developers yet again rediscover bytecode!
| mediumsmart wrote:
| absolutely - one for the great minds to play with while running
| in great circles and one that passes https://jslint.com and is
| allowed to be on the internet.
| n00b101 wrote:
| Can anyone explain the layout and formatting of the slides?
| remify wrote:
| In my opinion Typescript made a mistake staying in sync with the
| ECMA Script specs.
| cryptica wrote:
| I was thinking we should split JavaScript based on the 'good
| parts' vs 'bad parts' as opposed to 'new features' vs 'existing
| features'.
|
| That said I also see the rationale for that. JS is already
| getting heavy and we should limit feature creep.
| DidYaWipe wrote:
| Can we clean up the TypeScript & JavaScript thing at the same
| time?
| rixtox wrote:
| This is also a result of the detachment of TC39 and the developer
| community. Just how many JS developers are participating TC39? I
| can recall multiple TC39 proposals that didn't even consult
| opinions from authors of notable open-source stakeholder
| libraries, and went straight into stage 3.
|
| And btw, the TypeScript tooling scene is far from being able to
| get standardized. TypeScript is basically a Microsoft thing, and
| we don't see a single non-official TypeScript tool can do type-
| checking. And there's no plan to port the official tools to a
| faster language like Rust. And the tsc is not designed for doing
| tranditional compiler optimizations. The TypeScript team made it
| clear that the goal of tsc is to only produce idiomatic
| JavaScript.
| ocular-rockular wrote:
| The same could be said for R and Tidyverse crowd. Honestly two
| entirely separate visions.
| Aldipower wrote:
| No word about Actionscript 3 (ECMAScript 4) here? It compiled to
| the ActionScript Virtual Machine 2 as bytecode. Everybody was
| happy. And then, Steve Jobs came around the corner and damned it
| with a single magical curse. Too bad.
| game_the0ry wrote:
| I hope not. I have a hard enough time trying to keep up with
| front end frameworks.
___________________________________________________________________
(page generated 2024-10-26 23:03 UTC)