12 ms·

Should JavaScript be split into two languages?

142 points by em-bee 2y ago

peutetre 2y ago
Better to focus on WebAssembly instead. Bring every language to the web. JavaScript for some scripting, any other language for bigger applications.
- em-bee 2y ago
  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 2y ago
    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 2y ago
      right, making those APIs accessible from WASM is something i am also waiting for.
      - croes 2y ago
        So you want more rights for code that’s harder to read than obfuscated JS?
    - xscott 2y ago
      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 2y ago
        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 2y ago
        Or you can just draw to canvas to make the UI fast which is what Flutter does now: https://flutterweb-wasm.web.app/ https://flutterweb-wasm.web.app/ https://www.youtube.com/watch?v=Nkjc9r0WDNo https://www.youtube.com/watch?v=Nkjc9r0WDNo
        emseetech 2y ago
        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 2y ago
        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?
        anonzzzies 2y ago
        What is missing is that I never want to touch js for anything, so how do I do that if I have to write glue and imports in js/ts?
        xscott 2y ago
        I thing we agree. JavaScript is awful, and TypeScript is simultaneously impressive and still awful. I think we have three options: A) Get your hands dirty and write what you want. Once. B) Chant along with the mob who doesn't even understand what they're asking for. C) Wait several years for some super complicated solution to be designed by committee. I wouldn't even want direct access to the DOM if we had it today. The DOM as an API is atrocious. Instead, I want a set of nice functions that do things like put a graphical chart on the page - all in one call. Or one call to pass a bunch of 3D triangles or splats to visualize in a WebGL canvas. Or one call to play some audio samples. Or a function to poll for recording audio. And so on... I choose option A.
  - hn_throwaway_99 2y ago
    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.
- fny 2y ago
  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 2y ago
    It already supports WebAssembly. All browsers do. Here's a demo of Dart and Flutter compiled to WebAssembly: https://flutterweb-wasm.web.app/ 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 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-app-for-more-than-8-000-device-types https://www.amazon.science/blog/how-prime-video-updates-its-...
    - wiseowise 2y ago
      [flagged]
      - a57721 2y ago
        Kotlin and Rust are modern languages that were designed much later and not so hastily, so they have less warts than JavaScript as a result.
        wiseowise 2y ago
        Kotlin is a lipstick on a pig that effectively doesn’t exist outside of IntelliJ, single vendor that is only interested in driving sales to their IDEs and doesn’t work without bringing baroque Gradle. It has amazing coroutines library and it started with a nice set of features but failed to evolve. Sealed types are a joke compared to union types in TS. No inline types so you’re forced to created stupid data classes everywhere even if it’s used only once. Constant fight between wannabe functional programmers that try to replicate Rust’s Result monad, but without official language support, and exceptions crowd. Static delegation. Still no pattern matching when even freaking Java has it nowadays. Hilarious. Constant focus on KMM, even though language stagnated for a while. Rust is just a pain to develop. Slow to compile and constantly have to please borrow checker. I’m not sure if you’re joking, but you can’t seriously think that Rust is better language for prototyping than JS/TS. > designed much later and not so hastily, so they have less warts than JavaScript as a result. That’s irrelevant. Modern JS has evolved over the years and is a joy to use now.
- rafaelmn 2y ago
  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 2y ago
    Garbage collection is solved to the extent that host garbage collection is now available via WasmGC: https://developer.chrome.com/blog/wasmgc/ https://developer.chrome.com/blog/wasmgc/ https://v8.dev/blog/wasm-gc-porting https://v8.dev/blog/wasm-gc-porting But languages like C# want more features in WasmGC: https://github.com/dotnet/runtime/issues/94420 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 2y ago
      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 2y ago
    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 https://github.com/tc39/proposal-binary-ast
    - rafaelmn 2y ago
      Problem with AST is that it still kind of forces JS semantics which we should be working away from if we're doing this big leap.
- RandomThoughts3 2y ago
  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.
  - anonzzzies 2y ago
    I was in your camp, but we truly lost. Almost everyone I know literally ONLY uses a browser for everything. On mobile some things force you app use, but if that weren't the case, people would use it from a browser. Games in browsers, movies, email, anything. So it makes sense to only open a browser in an OS; it is basically what users do anyway.
- jokethrowaway 2y ago
  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 2y ago
    > 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://avaloniaui.net/ https://platform.uno/ https://platform.uno/ https://flutter.dev/ https://flutter.dev/ Flutter example: https://flutterweb-wasm.web.app/ https://flutterweb-wasm.web.app/
    - ec109685 2y ago
      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.
      - peutetre 2y ago
        It loads fast for me in Firefox, MS Edge, and Chrome. It's a 2 megabyte transfer and runs quickly. If you're using Safari it's true that Safari's WebAssembly implementation is behind the other browsers. But that's a Safari problem more than a WebAssembly problem.
  - akira2501 2y ago
    > 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.
tgv 2y ago
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 2y ago
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_frontend.md 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.
sshine 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      > 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 2y ago
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 2y ago
  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 2y ago
    > sourcemaps etc do currently exist for JS. Are those being supplied with every website you use?
  - ec109685 2y ago
    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.
    - ratorx 2y ago
      I’m not sure if it exists, but it definitely seems doable (a regular debugger has to map instructions to lines of code). If the browser starts treating JS as assembly, then there would probably be a greater onus for features like this.
      - ec109685 2y ago
        That would be nice. Was stepping through some modern react code, and the amount of cruft you see is terrible in the transpiled result.
- sshine 2y ago
  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 https://www.typescriptlang.org/tsconfig/#sourceMap [2]: https://elm-lang.org/news/time-travel-made-easy https://elm-lang.org/news/time-travel-made-easy (2014 [3]: https://devtools.vuejs.org/ https://devtools.vuejs.org/
ninetyninenine 2y ago
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 2y ago
  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 2y ago
    Yeah but if I change jobs or work on another project then I’d have to learn two standards.
    - loftyal 2y ago
      Did you read the article? The sugared JS would be a superset of the target JS. So you would only need to learn the sugared.
      - ninetyninenine 2y ago
        Need to learn both because I still need to know what is sugar in order to use the subset.
- bitwarrior 2y ago
  You didn't read the article.
- akira2501 2y ago
  > 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.
deleted 2y ago
[deleted]
jas39 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
    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-app-for-more-than-8-000-device-types https://www.amazon.science/blog/how-prime-video-updates-its-... https://web.dev/case-studies/google-sheets-wasmgc https://web.dev/case-studies/google-sheets-wasmgc
  - jas39 2y ago
    That is a misconception; there is a cost of abstraction, although this cost may disappear if AI gets really smart.
- wiseowise 2y ago
  > 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 2y ago
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 2y ago
  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 2y ago
    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 2y ago
  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 2y ago
bitwize 2y ago
JavaScript so wants to be Scheme. Can we just do Eich's original thing and put Scheme in the browser?
- peutetre 2y ago
  WebAssembly enables that: https://www.spritely.institute/hoot/ https://www.spritely.institute/hoot/
  - davexunit 2y ago
    Heh thanks for dropping the link! The dream of the 90s is alive thanks to Wasm GC.
hn_throwaway_99 2y ago
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 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 2y ago
  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 2y ago
    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 2y ago
      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
kmeisthax 2y ago
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 2y ago
  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 2y ago
  > 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 2y ago
  > 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 2y ago
  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.
LudwigNagasena 2y ago
It should have been split into JS and Wasm. Instead they decided to make Wasm a second-class citizen without web API access.
mircerlancerous 2y ago
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 2y ago
  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 2y ago
    This is not what happened in C vs C++.
- anon7000 2y ago
  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 2y ago
    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.
  - o11c 2y ago
habosa 2y ago
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 2y ago
  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 2y ago
    > 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 2y ago
  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.
no_wizard 2y ago
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 2y ago
  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 2y ago
    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
  - senfiaj 2y ago
    bigint cannot be replaced by regular number when working with arbitrarily large whole numbers. With regular numbers you will lose precision out of the range [Number.MIN_SAFE_INTEGER, Number.MAX_SAFE_INTEGER]. If you try to implement such functionality via JS, it would be even much slower than the bigint native implementation. So, it's great to have such thing natively implemented.
nephy 2y ago
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 2y ago
  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 2y ago
"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.
- emaro 2y ago
  Moving features out of the core (JS0) would break backwards compatibility and therefore many existing sites.
- PeterWhittaker 2y ago
  > ECMA not Ecma Incorrect: https://ecma-international.org/about-ecma/history/ https://ecma-international.org/about-ecma/history/
  - TheRealPomax 2y ago
    Cool: my comment is about them spelling it wrong, writing it as "emca".
    - BrendanEich 2y ago
      Also, it did start life as an acronym, and that spelling perdures in the hated "ECMAScript" name.
    - PeterWhittaker 2y ago
      Oh, duh! Good catch! Apologies!
- yakshaving_jgt 2y ago
  > 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 2y ago
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 2y ago
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 2y ago
Why JS0 and not wasm? Why is wasm so damn limited?
- singularity2001 2y ago
  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 2y ago
> 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 2y ago
  I literally use BigInt on the backend every single day at work lol.
- 3np 2y ago
  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 2y ago
  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 2y ago
    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 2y ago
      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.
belter 2y ago
https://news.ycombinator.com/item?id=41936300 https://news.ycombinator.com/item?id=41936300
- dang 2y ago
  Thanks—that thread had two comments, which I've merged hither since the current thread is ongoing.
dang 2y ago
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 https://news.ycombinator.com/item?id=41795190 - Oct 2024 (1 comment) Proposal of JavaScript becoming a compiled language: JS0 and JSSugar - https://news.ycombinator.com/item?id=41764825 https://news.ycombinator.com/item?id=41764825 - Oct 2024 (2 comments)
- itsgabriel 2y ago
  https://news.ycombinator.com/item?id=41764825 https://news.ycombinator.com/item?id=41764825
  - dang 2y ago
    Added. Thanks!
hoppp 2y ago
I use bigint all the time. Not adopted? Its not true.
- senfiaj 2y ago
  Yep. Even if it is used on the 1% of websites it's still a usage. Sure, I don't expect it to be used as commonly as a regular number.
jauntywundrkind 2y ago
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.
- avvvv 2y ago
  JS0 is supposed to be a high level language. Theoretically it could improve performance by allowing more explicitness in the generated code than in normal JS, thus helping out the JIT optimizer. I don't see how a browser running JS0 can be any less secure than a browser running JS
mirekrusin 2y ago
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 2y ago
> 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 2y ago
Add structs/value types, pattern matching and we can freeze the language until end of days.
allenap 2y ago
Split it into a thousand pieces and send each to separate, distant stars. Put three in a Phantom Zone.
Timwi 2y ago
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 2y ago
  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 2y ago
  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 2y ago
    "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.
neocon4life 2y ago
JavaScript developers yet again rediscover bytecode!
mediumsmart 2y ago
absolutely - one for the great minds to play with while running in great circles and one that passes https://jslint.com https://jslint.com and is allowed to be on the internet.
n00b101 2y ago
Can anyone explain the layout and formatting of the slides?
remify 2y ago
In my opinion Typescript made a mistake staying in sync with the ECMA Script specs.
cryptica 2y ago
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 2y ago
Can we clean up the TypeScript & JavaScript thing at the same time?
rixtox 2y ago
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 2y ago
The same could be said for R and Tidyverse crowd. Honestly two entirely separate visions.
Aldipower 2y ago
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 2y ago
I hope not. I have a hard enough time trying to keep up with front end frameworks.
8n4vidtmkvmk 2y ago
I'm a little annoyed that they said Bigint uses cases never materialized. I've used it several times and it isn't something that's easy to transpile. A bigint class has bad ergonomics and there's no way the perf can be equivalent.
- senfiaj 2y ago
  Same toughs. It's irreplaceable when working with arbitrary sized integers. Even if it's used on 1-2% of websites, it's still a significant usage. Surely, it won't be used as commonly a regular floating point number.
- styfle 2y ago
  It’s because Google doesn’t use Node.js or any JS outside the browser, so they assume low browser usage is low usage in general which isn’t true. https://github.com/search?q=BigInt+language%3ATypeScript&type=code https://github.com/search?q=BigInt+language%3ATypeScript&typ... https://github.com/search?q=BigInt+language%3AJavaScript&type=code https://github.com/search?q=BigInt+language%3AJavaScript&typ...
odyssey7 2y ago
Imagine Google not having the resources to maintain their V8 engine after the hiring downturn, and telling us they want to change JavaScript because their V8 engine has become challenging to maintain. A proposal rooted in attempts to improve the language would be one thing. This appears to be about Google struggling with technical competencies and not having the budget to do the right thing. “A Google engineer presented … JavaScript VMs (virtual machines), they say, are “already very complex because of pressure to be fast,” which compromises security, and “feels especially bad” when new features do not get adoption.“ “The foundational technology of JavaScript should be simple, according to the proposal, because security flaws and the “complexity cost” of the runtimes affects billions of uses, whereas the benefits are restricted to developers and applications that actually use that complexity to advantage.” Maybe try something besides c++ for V8 if you are having security issues? The apathy towards proper tail calls in V8 leads me to distrust Google’s language proposals. But now that abdication appears to possibly have been a canary? Perhaps even prior to the pandemic they couldn’t keep up with maintaining the V8 C++ codebase, and that’s why PTCs got skipped? By the way, what happened to Golang and Dart?
pabs3 2y ago
Sounds like WASM is their JS0 already?
oceanstone 2y ago
> this possible solution is Google’s preferred solution Is it though? Sounds more like a single team's preference, and not necessarily a team of FE engineers
voidr 2y ago
If we take this logic, we should get rid of JavaScript support entirely and only support WASM, which would be a direction, but it would ignore how developers are using the platform. It is now becoming rare when I see any serious project that still uses JavaScript, everyone I know is using TypeScript and I don't recall any job posts not requiring TypeScript. What are the standards bodies doing? They are still implementing hacks upon JavaScript instead of seeing the writing on the wall. Maintaining JS engines is difficult because of the old stuff that few developers actually use, it would make a lot more sense to start deprecating those features and adding the new ones developers actually want. I started using alternatives to NodeJS because I don't feel like I should subject myself to a compilation step if I don't have to.
pier25 2y ago
Just no. Browsers operate at a scale never seen before. Imagine all the extra energy and bandwidth needed if core functionality is moved to the application code when you have billions of users. What we need is more native functionality (implemented in the JS engine with C++ or Rust) to have as less user land code as possible. As an example, imagine how much energy, bytes, and CPU would be saved if browsers and JS engines included reactivity and JSX. Or if browsers included an API similar to jQuery. Quick math to grasp the scale: 100kb * 1 billion users = 100TB of data that needs to be transferred and parsed many times, every single day. It's absurd.

142 points by em-bee 2y ago

Better to focus on WebAssembly instead. Bring every language to the web. JavaScript for some scripting, any other language for bigger applications.

em-bee 2y ago
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 2y ago
  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 2y ago
    right, making those APIs accessible from WASM is something i am also waiting for.
    - croes 2y ago
      So you want more rights for code that’s harder to read than obfuscated JS?
  - xscott 2y ago
    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 2y ago
      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 2y ago
        Or you can just draw to canvas to make the UI fast which is what Flutter does now: https://flutterweb-wasm.web.app/ https://flutterweb-wasm.web.app/ https://www.youtube.com/watch?v=Nkjc9r0WDNo https://www.youtube.com/watch?v=Nkjc9r0WDNo
        emseetech 2y ago
        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 2y ago
        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?
        anonzzzies 2y ago
        What is missing is that I never want to touch js for anything, so how do I do that if I have to write glue and imports in js/ts?
        xscott 2y ago
        I thing we agree. JavaScript is awful, and TypeScript is simultaneously impressive and still awful. I think we have three options: A) Get your hands dirty and write what you want. Once. B) Chant along with the mob who doesn't even understand what they're asking for. C) Wait several years for some super complicated solution to be designed by committee. I wouldn't even want direct access to the DOM if we had it today. The DOM as an API is atrocious. Instead, I want a set of nice functions that do things like put a graphical chart on the page - all in one call. Or one call to pass a bunch of 3D triangles or splats to visualize in a WebGL canvas. Or one call to play some audio samples. Or a function to poll for recording audio. And so on... I choose option A.
- hn_throwaway_99 2y ago
  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.
fny 2y ago
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 2y ago
  It already supports WebAssembly. All browsers do. Here's a demo of Dart and Flutter compiled to WebAssembly: https://flutterweb-wasm.web.app/ 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 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-app-for-more-than-8-000-device-types https://www.amazon.science/blog/how-prime-video-updates-its-...
  - wiseowise 2y ago
    [flagged]
    - a57721 2y ago
      Kotlin and Rust are modern languages that were designed much later and not so hastily, so they have less warts than JavaScript as a result.
      - wiseowise 2y ago
        Kotlin is a lipstick on a pig that effectively doesn’t exist outside of IntelliJ, single vendor that is only interested in driving sales to their IDEs and doesn’t work without bringing baroque Gradle. It has amazing coroutines library and it started with a nice set of features but failed to evolve. Sealed types are a joke compared to union types in TS. No inline types so you’re forced to created stupid data classes everywhere even if it’s used only once. Constant fight between wannabe functional programmers that try to replicate Rust’s Result monad, but without official language support, and exceptions crowd. Static delegation. Still no pattern matching when even freaking Java has it nowadays. Hilarious. Constant focus on KMM, even though language stagnated for a while. Rust is just a pain to develop. Slow to compile and constantly have to please borrow checker. I’m not sure if you’re joking, but you can’t seriously think that Rust is better language for prototyping than JS/TS. > designed much later and not so hastily, so they have less warts than JavaScript as a result. That’s irrelevant. Modern JS has evolved over the years and is a joy to use now.
rafaelmn 2y ago
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 2y ago
  Garbage collection is solved to the extent that host garbage collection is now available via WasmGC: https://developer.chrome.com/blog/wasmgc/ https://developer.chrome.com/blog/wasmgc/ https://v8.dev/blog/wasm-gc-porting https://v8.dev/blog/wasm-gc-porting But languages like C# want more features in WasmGC: https://github.com/dotnet/runtime/issues/94420 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 2y ago
    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 2y ago
  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 https://github.com/tc39/proposal-binary-ast
  - rafaelmn 2y ago
    Problem with AST is that it still kind of forces JS semantics which we should be working away from if we're doing this big leap.
RandomThoughts3 2y ago
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.
- anonzzzies 2y ago
  I was in your camp, but we truly lost. Almost everyone I know literally ONLY uses a browser for everything. On mobile some things force you app use, but if that weren't the case, people would use it from a browser. Games in browsers, movies, email, anything. So it makes sense to only open a browser in an OS; it is basically what users do anyway.
jokethrowaway 2y ago
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 2y ago
  > 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://avaloniaui.net/ https://platform.uno/ https://platform.uno/ https://flutter.dev/ https://flutter.dev/ Flutter example: https://flutterweb-wasm.web.app/ https://flutterweb-wasm.web.app/
  - ec109685 2y ago
    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.
    - peutetre 2y ago
      It loads fast for me in Firefox, MS Edge, and Chrome. It's a 2 megabyte transfer and runs quickly. If you're using Safari it's true that Safari's WebAssembly implementation is behind the other browsers. But that's a Safari problem more than a WebAssembly problem.
- akira2501 2y ago
  > 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.

tgv 2y ago

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 2y ago

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_frontend.md 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.

sshine 2y ago

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 2y ago
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 2y ago
  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 2y ago
    > 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 2y ago

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 2y ago
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 2y ago
  > sourcemaps etc do currently exist for JS. Are those being supplied with every website you use?
- ec109685 2y ago
  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.
  - ratorx 2y ago
    I’m not sure if it exists, but it definitely seems doable (a regular debugger has to map instructions to lines of code). If the browser starts treating JS as assembly, then there would probably be a greater onus for features like this.
    - ec109685 2y ago
      That would be nice. Was stepping through some modern react code, and the amount of cruft you see is terrible in the transpiled result.
sshine 2y ago
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 https://www.typescriptlang.org/tsconfig/#sourceMap [2]: https://elm-lang.org/news/time-travel-made-easy https://elm-lang.org/news/time-travel-made-easy (2014 [3]: https://devtools.vuejs.org/ https://devtools.vuejs.org/

ninetyninenine 2y ago

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 2y ago
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 2y ago
  Yeah but if I change jobs or work on another project then I’d have to learn two standards.
  - loftyal 2y ago
    Did you read the article? The sugared JS would be a superset of the target JS. So you would only need to learn the sugared.
    - ninetyninenine 2y ago
      Need to learn both because I still need to know what is sugar in order to use the subset.
bitwarrior 2y ago
You didn't read the article.
akira2501 2y ago
> 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.

deleted 2y ago

[deleted]

jas39 2y ago

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 2y ago
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 2y ago
  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 2y ago
    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 2y ago
  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-app-for-more-than-8-000-device-types https://www.amazon.science/blog/how-prime-video-updates-its-... https://web.dev/case-studies/google-sheets-wasmgc https://web.dev/case-studies/google-sheets-wasmgc
- jas39 2y ago
  That is a misconception; there is a cost of abstraction, although this cost may disappear if AI gets really smart.
wiseowise 2y ago
> 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 2y ago

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 2y ago
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 2y ago
  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 2y ago
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 2y ago

bitwize 2y ago

JavaScript so wants to be Scheme. Can we just do Eich's original thing and put Scheme in the browser?

peutetre 2y ago
WebAssembly enables that: https://www.spritely.institute/hoot/ https://www.spritely.institute/hoot/
- davexunit 2y ago
  Heh thanks for dropping the link! The dream of the 90s is alive thanks to Wasm GC.

hn_throwaway_99 2y ago

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 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 2y ago
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 2y ago
  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 2y ago
    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

kmeisthax 2y ago

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 2y ago
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 2y ago
> 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 2y ago
> 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 2y ago
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.

LudwigNagasena 2y ago

It should have been split into JS and Wasm. Instead they decided to make Wasm a second-class citizen without web API access.

mircerlancerous 2y ago

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 2y ago
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 2y ago
  This is not what happened in C vs C++.
anon7000 2y ago
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 2y ago
  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.
- o11c 2y ago

habosa 2y ago

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 2y ago
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 2y ago
  > 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 2y ago
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.

no_wizard 2y ago

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 2y ago
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 2y ago
  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
- senfiaj 2y ago
  bigint cannot be replaced by regular number when working with arbitrarily large whole numbers. With regular numbers you will lose precision out of the range [Number.MIN_SAFE_INTEGER, Number.MAX_SAFE_INTEGER]. If you try to implement such functionality via JS, it would be even much slower than the bigint native implementation. So, it's great to have such thing natively implemented.

nephy 2y ago

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 2y ago
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 2y ago

"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.

emaro 2y ago
Moving features out of the core (JS0) would break backwards compatibility and therefore many existing sites.
PeterWhittaker 2y ago
> ECMA not Ecma Incorrect: https://ecma-international.org/about-ecma/history/ https://ecma-international.org/about-ecma/history/
- TheRealPomax 2y ago
  Cool: my comment is about them spelling it wrong, writing it as "emca".
  - BrendanEich 2y ago
    Also, it did start life as an acronym, and that spelling perdures in the hated "ECMAScript" name.
  - PeterWhittaker 2y ago
    Oh, duh! Good catch! Apologies!
yakshaving_jgt 2y ago
> 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 2y ago

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 2y ago

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 2y ago

Why JS0 and not wasm? Why is wasm so damn limited?

singularity2001 2y ago
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 2y ago

> 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 2y ago
I literally use BigInt on the backend every single day at work lol.
3np 2y ago
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 2y ago
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 2y ago
  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 2y ago
    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.

belter 2y ago

https://news.ycombinator.com/item?id=41936300 https://news.ycombinator.com/item?id=41936300

dang 2y ago
Thanks—that thread had two comments, which I've merged hither since the current thread is ongoing.

dang 2y ago

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 https://news.ycombinator.com/item?id=41795190 - Oct 2024 (1 comment) Proposal of JavaScript becoming a compiled language: JS0 and JSSugar - https://news.ycombinator.com/item?id=41764825 https://news.ycombinator.com/item?id=41764825 - Oct 2024 (2 comments)

itsgabriel 2y ago
https://news.ycombinator.com/item?id=41764825 https://news.ycombinator.com/item?id=41764825
- dang 2y ago
  Added. Thanks!

hoppp 2y ago

I use bigint all the time. Not adopted? Its not true.

senfiaj 2y ago
Yep. Even if it is used on the 1% of websites it's still a usage. Sure, I don't expect it to be used as commonly as a regular number.

jauntywundrkind 2y ago

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.

avvvv 2y ago
JS0 is supposed to be a high level language. Theoretically it could improve performance by allowing more explicitness in the generated code than in normal JS, thus helping out the JIT optimizer. I don't see how a browser running JS0 can be any less secure than a browser running JS

mirekrusin 2y ago

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 2y ago

> 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 2y ago

Add structs/value types, pattern matching and we can freeze the language until end of days.

allenap 2y ago

Split it into a thousand pieces and send each to separate, distant stars. Put three in a Phantom Zone.

Timwi 2y ago

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 2y ago
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 2y ago
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 2y ago
  "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.

neocon4life 2y ago

JavaScript developers yet again rediscover bytecode!

mediumsmart 2y ago

absolutely - one for the great minds to play with while running in great circles and one that passes https://jslint.com https://jslint.com and is allowed to be on the internet.

n00b101 2y ago

Can anyone explain the layout and formatting of the slides?

remify 2y ago

In my opinion Typescript made a mistake staying in sync with the ECMA Script specs.

cryptica 2y ago

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 2y ago

Can we clean up the TypeScript & JavaScript thing at the same time?

rixtox 2y ago

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 2y ago

The same could be said for R and Tidyverse crowd. Honestly two entirely separate visions.

Aldipower 2y ago

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 2y ago

I hope not. I have a hard enough time trying to keep up with front end frameworks.

8n4vidtmkvmk 2y ago

I'm a little annoyed that they said Bigint uses cases never materialized. I've used it several times and it isn't something that's easy to transpile. A bigint class has bad ergonomics and there's no way the perf can be equivalent.

senfiaj 2y ago
Same toughs. It's irreplaceable when working with arbitrary sized integers. Even if it's used on 1-2% of websites, it's still a significant usage. Surely, it won't be used as commonly a regular floating point number.
styfle 2y ago
It’s because Google doesn’t use Node.js or any JS outside the browser, so they assume low browser usage is low usage in general which isn’t true. https://github.com/search?q=BigInt+language%3ATypeScript&type=code https://github.com/search?q=BigInt+language%3ATypeScript&typ... https://github.com/search?q=BigInt+language%3AJavaScript&type=code https://github.com/search?q=BigInt+language%3AJavaScript&typ...

odyssey7 2y ago

Imagine Google not having the resources to maintain their V8 engine after the hiring downturn, and telling us they want to change JavaScript because their V8 engine has become challenging to maintain. A proposal rooted in attempts to improve the language would be one thing. This appears to be about Google struggling with technical competencies and not having the budget to do the right thing. “A Google engineer presented … JavaScript VMs (virtual machines), they say, are “already very complex because of pressure to be fast,” which compromises security, and “feels especially bad” when new features do not get adoption.“ “The foundational technology of JavaScript should be simple, according to the proposal, because security flaws and the “complexity cost” of the runtimes affects billions of uses, whereas the benefits are restricted to developers and applications that actually use that complexity to advantage.” Maybe try something besides c++ for V8 if you are having security issues? The apathy towards proper tail calls in V8 leads me to distrust Google’s language proposals. But now that abdication appears to possibly have been a canary? Perhaps even prior to the pandemic they couldn’t keep up with maintaining the V8 C++ codebase, and that’s why PTCs got skipped? By the way, what happened to Golang and Dart?

pabs3 2y ago

Sounds like WASM is their JS0 already?

oceanstone 2y ago

> this possible solution is Google’s preferred solution Is it though? Sounds more like a single team's preference, and not necessarily a team of FE engineers

voidr 2y ago

If we take this logic, we should get rid of JavaScript support entirely and only support WASM, which would be a direction, but it would ignore how developers are using the platform. It is now becoming rare when I see any serious project that still uses JavaScript, everyone I know is using TypeScript and I don't recall any job posts not requiring TypeScript. What are the standards bodies doing? They are still implementing hacks upon JavaScript instead of seeing the writing on the wall. Maintaining JS engines is difficult because of the old stuff that few developers actually use, it would make a lot more sense to start deprecating those features and adding the new ones developers actually want. I started using alternatives to NodeJS because I don't feel like I should subject myself to a compilation step if I don't have to.

pier25 2y ago

Just no. Browsers operate at a scale never seen before. Imagine all the extra energy and bandwidth needed if core functionality is moved to the application code when you have billions of users. What we need is more native functionality (implemented in the JS engine with C++ or Rust) to have as less user land code as possible. As an example, imagine how much energy, bytes, and CPU would be saved if browsers and JS engines included reactivity and JSX. Or if browsers included an API similar to jQuery. Quick math to grasp the scale: 100kb * 1 billion users = 100TB of data that needs to be transferred and parsed many times, every single day. It's absurd.