JavaScript Is Becoming 2 Languages?? FROM TC39

[@pseudonymity0000]

So they want to take javascript, Split it into a higher level variant that's easier to read and wright with easy to code features, and a simplified low level variant to be compiled down to, that's easier to be processed on the back end, but unwieldy to look a to a human.... Kinda like some kind of web assembly or something... Wait...

[@lucidattf]

the exact opposite of what you’re saying. they want to make an extended syntax which compiles to javascript (or js0, but js0 would be what we currently know as javascript, this only would effect future changes), similar to what typescript is

[@tauiin]

I mean thats been done for years and years and years, long before wasm. v8 has bytecode after all :P

[@moussaadem7933]

​@@lucidattf the same thing, they are dual to each other

[@MsBukke]

​@@lucidattfnope, it compiles to js0, not javascript

[@lucidattf]

@@MsBukke js0 would be equivalent to what engines run today, it said in the article?

[@rohitaug]

I'm sure this won't have any adverse effect on the number of javascript frameworks

[@JorgetePanete]

metaframework for metaframeworks

[@XDarkGreyX]

We need to identify as meta frameworks

[@tomorrow6]

I think infinity minus one is still infinity , and infinity times two is similar

[@igoralmeida9136]

every framework will have it's own special version of javascript

[@bedro_0]

Didn't know they redefined "No effect" to exponential growth

[@scheimong]

Javascript, the language that keeps on giving. Giving what I'm not so sure.

[@monad_tcp]

giving cancer

[@monad_tcp]

it gives c4nc3r

[@privacyvalued4134]

Aneurysms. It keeps giving aneurysms.

[@adeidara9955]

6 figure salaries

[@nearest2596]

@@adeidara9955

[@Enzoss100]

JS0 - healthy JS JSSugar - sweeteners added JSDecaf - Decaffeinated JS JSCaff - Caffeinated JS, full of your thrills and frameworks

[@sebirocs]

Coffeescript is back 😎

[@monad_tcp]

JSDiabetes, what happens when you use too much JS

[@temari2860]

JSSoy - wait that's just JavaScript

[@Mglunafh]

JSAdderall™ -- VC-sponsored AI-backed JS to achieve the smallest time-to-market values

[@arterius169]

jsdefecated

[@lightningx10]

Why can't we just make WASM better, this is ridiculous

[@fdssd1736]

The problem is JS. We need to get rid of JS, not try more and more absurd ways to "fix" what is fundamentally broken.

[@mrkostya008]

Because wasm cant be put into a script tag and just be executed, but instead must be compiled and provided on a separate url.

[@justsomeonepassingby3838]

​@@mrkostya008so you would rather compile, minify and bundle your augmented javascript into compressed files provided on a separate url ?

[@lunar_mycroft]

@@mrkostya008 The way you'd actually implement this is to implement javascript in WASM, and ship that interpreter with the browser. This is needed for backwards compatibility anyway. You could also add a attribute to script tags which would allow you to specify which interpreter to use, which would open up the possibility of using languages other than js in script tags (e.g. maybe you'd prefer lua, or python, or ruby, etc)

[@Daktyl198]

Before WASM existed, Mozilla successfully created their ASM.js standard which was a subset of JavaScript that could be ahead-of-time optimized. It's basically exactly what Google is suggesting here, but nobody cared when Mozilla did it lol.

[@Necropheliac]

Nobody is actually demanding new syntax. The new syntax is constantly being shoved down our throats by people we don’t even know or care to know. I’m not saying the new syntax is bad, but I’m just saying that most of us developers are not clamoring for this state of rapid change. I can only speak for myself but frankly I find it annoying compared to other languages I use like Python, Perl, PHP, etc… That’s not really the most pertinent point though. The real issue here is that there are a lot of web browsers and applications that use JavaScript and after decades of being lost on the wilderness we’ve finally arrived at a place where most of them are adhering to one set of standards. Dividing JavaScript in half by how people want to develop it, is making it more difficult for browsers and applications to adhere to these standards and we’re going to start regressing back to a time where it was a lot more difficult to develop something that works for everything. The way developers want to write code should take a back seat to ease of compliance. Universal compliance reduces complexity for everyone. Don’t make it more difficult than it needs to be.

[@emilemil1]

I don't like the idea that all the JavaScript I write in my IDE no longer straight up runs in the browser, since it might use syntax that JS0 doesn't support. Or that my quickly thrown together vanilla JS Node script can't use the features I'm used to anymore. At that point why not just make the language entirely compiled and run gibberish machine-only code in the browser? Or even better, improve WebAssembly so it doesn't need JavaScript glue!

[@thewhitefalcon8539]

Compatibility

[@cucumberwithketchup]

Yeah, I don't get why people don't want to support capabilities parity between js and wasm and call it a day. Then you can use anything you want, probably even brainfuck

[@ThiagoRochaA1]

This

[@fuzetsu]

I don't think there would be anything stopping a developer from writing JS0, and configuring their IDE to error on unsupported syntax. If someone chooses to do that they would just have to wait longer (or forever) for new features.

[@ThiagoRochaA1]

​@@fuzetsu That's not very practical.

[@srinthildev749]

Just like its frameworks, the JS itself will multiply

[@hamm8934]

Can we all stop pretending WASM is some pipe dream at this point? Just push browsers for direct DOM access (and other browser APIs) in WASM and come up with a registry or way to distribute the binary. Do these 2 things and WASM will flourish. This isnt cold fusion. Its literally pushing browser companies to prioritize implementing some basic APIs for another context. Cmon.

[@TheRealCelerate]

Are you using common sense? You do know that's heresy, right?

[@monad_tcp]

" Just push browsers for direct DOM access " that's the problem, they don't want to create the darned API

[@monad_tcp]

"way to distribute the binary" I came up with a way to distribute the binary embedded in the script tag. We add the OPcodes of the WASM binary VM as unicode codepoints to the unicode specification. Then we just do a simple binary translation that involves shifting-oring the opcodes into codepoints, that's very fast for CPUs to do, its almost free, compared to shit like BASE64. Then we just add to the HTML specification something like UTF8 representation of WASM

[@UwU-f2a]

WASM size is still big, bigger than JS. While it still need to call JS to interact with DOM because it doesnt have access to the DOM, the main reason for WebAssembly poor performance is not the need to interact with JS, it's just whole design of WebAssembly. It was primarily designed to run C++ or Rust. So what we have is something close to real CPU, but without useful CPU features that managed runtime engineers use to get really good performance (like runtime code generation, direct stack access, memory protection, etc). In WebAssembly GC they addressed this issue not by introducing lacking features, but by turning WebAssembly in something similar to JVM, with notion of objects, references between them, etc. Yet they did it with major flaws, like trapping instructions, so languages like Java or C# still suffer from generation of excessive code to address these flaws.

[@jearlblah5169]

@@monad_tcpyou know WAT exists right? It’s the textual version of web assembly

[@xxHANNONxx]

I clicked view source, and the next thing I knew, I woke up hog tied in the trunk of a car, halfway through Mexico.

[@ernestomotta5178]

First time?

[@capsey_]

remember guys, it's all just abstraction for loop is just while loop with extra steps while loop is just goto with extra steps goto is just JZ with extra steps JZ is just 0x74 with extra steps 0x74 is just 01110100 with extra steps

[@minerscale]

01110100 is just electrons being stored or not stored in a small capacitor being stored or not stored in a small capacitor is really just fluctuations in the electromagnetic field fluctuations in the electromagnetic field is uh urghm um I don't think anyone knows

[@hooflung128]

Son: Father, why did the world end? Father: Son, the JavaScript developers who could, never stopped to ask themselves if they should.

[@fitmotheyap]

JavaScript about to implement IRL access, modify the world to your wishes... it was all a mistake.

[@spicybaguette7706]

All I want is a JSSugarDaddy. Is that too much to ask for?

[@warrenarnoldmusic]

Your request aligns with mine DietCockJS😅

[@BlackwaterEl1te]

Nothing an extra layer of indirection can't solve.....

[@msclrhd]

Not all developers and not all projects are using tools to transpile JavaScript. I don't want to have to pull in node and a whole complex build process just to make a simple website or page use specific JavaScript features. I have a handfull of projects that use minimal JavaScript to hook up some interactions, or just provide and include JavaScript files. It's also easy to create a single page HTML file with CSS and JavaScript when experimenting with features or UI.

[@xybersurfer]

isn't that kind of the idea behind JSSugar? to bring these tools more into the standard

[@epajarjestys9981]

@@xybersurfer no, retard. JSSugar will require a build step to compile to JS0 if that idea gets implemented.

[@msclrhd]

@@xybersurfer If I'm writing a server in Java, Go, Rust or whatever that has minimal JavaScript usage, in order to get the JSSugar features I would need some sort of transpilation step to compile it. I need to also make sure that the build tool I'm using supports the JSSugar (and JS0 as it needs to leave JS0 unchanged) features I want to use. I need to make sure it supports the all the engines (Firefox, Ladybird, Chrome, etc.) at the versions I'm targeting. Then if I need to upgrade it I need to make sure it doesn't cause me to upgrade (e.g. if it drops support for the version of Java/Rust/etc. I'm using), or that I can upgrade all the components in tandem. Not to mention ensuring that my IDE supports the new JSSugar features and how they are implemented in the transpiler I'm using, especially for things like debugging -- not just for following lines (which can be done by source maps) but other things like new classes (viewing the type correctly) or other things like internal state values for matching or for/yield/return.

[@fuzetsu]

​@@msclrhd Couldn't one write JS0 directly in this scenario? If the project has minimal JavaScript usage anyway, missing out on some newer syntax features is probably a small sacrifice for lower complexity and lack of reliance on build steps.

[@MrDraganox]

@@fuzetsu At first there will be little difference between JS0 and JSSugar but imagine in 10 years time I can only imagine the huge frontier we'll create over time

[@punishedbarca761]

Fireship is going to have a field day with the concept of js assembly

[@UnidimensionalPropheticCatgirl]

asm.js (low level subset of js) was already thing mozilla cooked up, and wasm is still a thing.

[@Daktyl198]

@@UnidimensionalPropheticCatgirl Everybody forgets about asm.js, but I guess it really was way ahead of it's time... like most old Mozilla projects. New Mozilla could never capitalize on it though :/

[@gabrieltorresuberbucek6111]

Front end was a mistake.

[@ra2enjoyer708]

Nah, php takes this crown.

[@justsomeonepassingby3838]

Bloating the web standards to allow anyone to write any kind of application was a mistake I think a "unix philosophy oriented refactor" is needed

[@SorinSilaghi]

Just plug them into the matrix

[@SpeakChinglish]

Since this is a weak argument, have a weak response: "so is your face".

[@atiedebee1020]

​@@SpeakChinglishit's not an argument, it's a statement

[@muslim8622]

At this point, just add in the browser LLVM or JVM with native binding to the Web API. Creating a new VM doesn't make sense when some already existed and battle tested for decades

[@flyinginthedark6188]

They had it in chrome already, called NaCl (Google Native Client). It's basically LLVM IR bitcode. It had a lot of security issues and no one wanted to use it.

[@somenameidk5278]

​@@flyinginthedark6188 I've seen a few references to a "NaCl" in the scripts of a game i mod, and given the game's history, that would have to be it! Thanks for accidentally telling me what that goddamn unsearchable name is referring to!

[@muslim8622]

​ @flyinginthedark6188 Maybe LLVM is too low-level or the implementation was not good enough, too high privilege, etc... But i don't think adding a VM in the browser should not be a no-go overall because that what we have with WebAssembly, actually and Javascript is also compiled to bytecode under the hood if i'm not mistaken. A well sandboxed JVM, LLVM, BEAM, Dart VM or whatever you want, make far more sense to me than JSSugar/JS0 because all this VM have languages ready-use, mature toolchain, mature compilers, ecosystem. JSSugar/JS0 feel like the replication all those VM but badly executed where nobody is happy. You're stuck with Javascript (poorly designed language), the build step more complicated, unavoidable, the burden on tooling authors increase and the performance are not good. Where is the good part of all of that ?

[@spaceman7790]

Not me I work in C++. I just came to watch the world burn.

[@steviegt6]

cppfront 🤷‍♂️

[@VarunG-y6p]

What do you do? Where do you work?

[@erasehehe]

at least in the JS world you don't need to use CMake and visual studio

[@gusic4529]

@@erasehehe at least we aren't compiling an interpreted language

[@fuzzy-02]

Same here, I'm cooking with Go. Wanted to say they should make JS into NULL languages instead of 2.

[@spicybaguette7706]

TCP Can also do NACKs, by repeatedly acknowledging the same sequence number. The sliding window is how much data there can be in-flight. That is, data that is sent but not yet acknowledged. The problem comes when the sliding window is full, so the sender can't send any more packets before it receives an acknowledgement from the receiver that shifts the window forwards. This usually means that some packet is lost (at a large enough window size) and needs to be retransmitted. This is necessary because of the abstraction TCP provides: an ordered stream of bytes, that all come down in the same order than they come in. UDP doesn't have this restriction, and so you can receive packets in any order that you want. However, you have to do more work to piece your data together again. Another thing to consider is the rate that the sender sends packets. It gradually increases the sending rate until it finds that a packet was dropped. Then it will slow down the rate it sends packets to ensure that no further packets get lost. This mostly happens because routers drop packets because they either can't process or send them fast enough, which causes their queue to overflow, so they have to make space. Modern/well-configured routers can also set a bit in the IP header that indicates it is congested, and that the sender needs to slow down. The receiver reads this bit and then sends a signal to the sender to slow down. This is called ECN (Explicit Congestion Notification) and can solve the latency penalty involved with packet loss. Packets being lost by other means is more rare, except in wireless networks where stuff gets lost all the time. Modern networks like LTE and WiFi try to mitigate this with forward error correction, basically adding redundant information to increase the likelihood of data being received correctly

[@clem-1917]

This is how we defeat AI programmers.

[@furinick]

Do nothing and just wait for updates? Perfect!

[@ReedoTV]

Finance in JS is asking for trouble. It will end up with Array.finSort

[@Lord_zeel]

It sounds like they're basically saying "screw it, everyone should just use Babel and we shouldn't bother with new features" which... isn't a great way to go. One of the most important parts of engine implementations are the potential for optimizations that are simply impossible with syntactic transformers. Not to mention all the weird edge cases the transpilers need to deal with in order to produce runnable JS from even lightly "sugared" code. It sounds like they want to offload all the work onto the tooling projects, rather than improve the engine. And what about dev tools? If JS0 never includes decorators or matching, will devtools work? Do I have to now also connect an external debugger to the process in order to debug JSSugar features forever? That sucks. I think they are vastly overblowing the impact on users here, I think their main concern is that adding features make's their own jobs harder and they don't want to deal with that, so instead why not make the developer experience for everyone else worse. The rise of TS and built systems should not be taken as an indication that devs want this or are okay with it - it should be taken to indicate that there is something very WRONG with the ecosystem that we have to compile a language into a simpler version of itself. If we WERE compiling into bytecode and shipping that, then at least in theory there would be some reasonable advantage to it - but we're not. We are literally just transforming one version of syntax into another and that sucks at every level. That should not be baked into the spec, that should not be seen as the way to move forward. We should be thinking of ways to reduce or eliminate the need for that nonsense, not make it a requirement for everyone moving forward.

[@_FFFFFF_]

Cant wait to see how js devs deal with multiple toolchain debugging.

[@justsomeonepassingby3838]

Since we got that far, how about adding a Python syntax, compiled to typescript compiled to javascript compiled to compressed minified bundles ?

[@Nyxar-2077]

JavaScript was a mistake 🙏

[@shapelessed]

React was a bigger mistake.

[@lMINERl]

from web dev , I agree

[@gracjanchudziak4755]

It's hard to not agree but this comment was created after 1 minute of video release, and I want to ask, what is your point? Everybody knows it and I don't think bot's comment like that is valuable. Better answer what to do with it? Because everybody complain but there is no answer and we are still forced to use this crap.

[@mgame8082]

So? What are you gonna do about it? Learn it, use it, get the job done!

[@kartik4792]

Time to build a new browser I think this is actually the right time to start investing in a new browser. Current browsers have too many unnecessary features which make them slow, unmanageable and vulnerable to security issues. As time passes they will become more and more bloated as people who were working on them for many years will switch jobs and start working on more interesting stuff.

[@channeldsr9983]

You already have wasm, why do you need to split lang? Make js deprecated and move to ts to wasm compilation - that's all

[@JorgetePanete]

Make JS and TS deprecated and allow Rust on the web or its intermediate representations

[@markmywords3817]

browsers historically support backward compatibility so much that old ways of writing CSS HTML and JS still work today. So I doubt that would happen. Another path is to just support both, more likely IMO

[@einargs]

Compiling JavaScript to Web Assembly would make it extremely slow and large. JavaScript is as fast as it is because the interpreter can specialize functions, do runtime profiling to guide optimizations, etc. There are projects that compile JavaScript to a bytecode format like Facebook Hermes in order to take advantage of ahead of time compilation, but the produced bytecode is still higher level than machine code and for good reason.

[@dpgwalter]

​@@markmywords3817 Deprecated code can still be used, it's just not recommended anymore.

[@UnidimensionalPropheticCatgirl]

@@einargs I mean wasm is also super high level, it’s crazy bespoke stack machine not resembling anything thet exists in hardware… but that’s not the issue.

[@rmidifferent8906]

Wait, are they trying to implement decorators on the language itself? Like you have a decorator for types, then a decorator for a match, then a decorator for a decorator... All of it only to get slightly better syntax. Those people should be locked up

[@spicybaguette7706]

Honestly, the V8 devs kinda did this to themselves didn't they. Something something induced demand

[@jhonatanjacinto]

The "I don't want to be disappeared" got me laughing really hard indeed...

[@macerdough]

I wish this energy and resources would be redirected to making a good build system for C++, a faster runtime for the snake language, or literally anything else.

[@NicolasJoye]

Thank you for doing these. You help me get through tough times!!!

[@fusedqyou]

Love it when they make an excessively complex framework even more excessive. I'm sure this won't mess anything up.

[@Exilum]

My guess is we're going to end up with something like: -JS0: engine js -JSSugar: extended JS with TS support out of the box -TS: compiles to JSSugar, maybe deprecated in standalone if the TS people somehow feel like it integrates well with JSS. That means there's no need for a TS0, as not using any JSS feature would make it valid JS0 in the first place. So there's no loss only having transpiling from TS to JSS and just having the JSS pipeline deal with the conversion to JS0 I think it's quite positive. The way I see it, JS is held back by its own weight. It just can't evolve all that fast, and it's only going to slow down as legacy takes its toll on the engines. Separating the dev space from the user space is a better idea than it sounds if you consider the cost-benefit ratio. It will have to be supported by proper source maps for error handling but that's pretty much it. This also means the JSSugar syntax won't have to take as many performance considerations as it did before. Something that is inefficient to interpret might be transformed into a better form in the transpilation step. They'll care about whether this can be boiled down to efficient javascript rather than whether it can be interpreted effectively. It'll really be about developer experience.

[@sadboisibit]

Going from ES5 to ES6 was a major improvement imho but since then I feel like every new version of ES20XX has bloated the language with minor developer focused quality of live improvements that I could not care less about. The only new(ish) feature I actually use was from ES2020 when they added optional chaining and nullish coalescing. Everything else just makes me go "huh, okay, neat" then I forget about it.

[@SimonBuchanNz]

Async/generators, spread, class privates, *lots* of library methods? 2015 was big because it was 6 years worth of improvements the reset of es5, but they haven't really slowed down that much.

[@remmoze]

Skill issue ngl

[@sadboisibit]

@@remmoze 100%

[@taragnor]

Yeah the optional chain and null coalescencing was a real nice addition.

[@Klaus-bm5ek]

the specification must expand to meet the needs of the expanding specification

[@F.a797]

7:26 It's also worth noting that a TCP extension called SACK (Selective Acknowledgments) offers also offers a way to handle missing segments. Rather than explicitly saying which packet is missing, SACK tells the sender which packets actually arrived successfully. For example, if packet 69 is missing, instead of sending a "NACK 69," the receiver would send acknowledgments for "packets 20-68" and "packets 70-100." From these ranges, the sender can figure out that packet 69 is missing and needs to be resent. However, some network devices (middleboxes) between the sender and receiver might not recognize SACK because they're running older software. These devices might flag SACK packets as suspicious or handle them incorrectly, causing communication problems. Hence why HTTP3 uses QUIC which re-implements a similar solution in UDP.

[@F.a797]

also SACK deez nuts

[@digiryde]

Oliver - "Please, Sir, May I have MOAR?" Google - "You WANT MOAR?" Also Google - "Cook it in your own pot, though."

[@cabanford]

Can we please all pull together and make JS zero languages?

[@rasibn]

Google basically wants another typescript.

[@daylordd0752]

They goin after that market share 🔥🔥

[@ankushm3t]

TypeScript#

[@roccociccone597]

@@ankushm3tGoScript

[@follantic]

Ecmatypes

[@nisonatic]

The problem with Typescript? Google isn't in charge of it.

[@catcatcatcatcatcatcatcatcatca]

Thats not how UDP works. It’s a stateless connection so the client can’t send a NACK over UDP, nor could the server react to it. The basic consept of ACK or NACK assumes a stateful connection, and UDP is connectionless protocol. Instead you have a separate, stateful connection for control (SCTP) and UDP control for sending data fast. The NACK is transmitted through the control connection. The control session simply performs a handshake to open the session, controls ending the connection so the server isn’t sending a constant stream of data to a client who already peaced out (else it could not tell this happened), and sends few NACKs and occational heartbeats and statistics. So while one could implement their own stateful protocol for this over UDP, using TCP for the control connection is kind of a no-brainer. It’s the stateful connection build in to every network stack, handled specially by routers and firewalls, and so on. Pretty much every UDP based protocol uses TCP for control and maintaining some level of statefulness. With IP multicast the routers maintain a state of which of their clients are signed up to which multicast groups. Application layer protocols just rawdogging UDP are rare, uncontrollable and anonymous. Like IRC (internet RELAY chat)

[@AnthonyBullard]

JS0 is just JavaScript as in the current standard. The proposal is just for future proposals to be targeted to one or the other standards. The process for JSSugar acceptance is shorter. A JSSugar feature can eventually make it to JS0. That’s it It literally the world we have today, but where proposed features without the need for polyfills that are focused on sugar will have a formalized standard for what is approved, as opposed to “we will compile any Stage 1 proposal if we can”

[@annoorange123]

16:10 did you just tell me to go func myself? 🤐

[@MrEW1985]

I think this is a step forward. The advancements in other languages boil down to syntactic sugar. If there just was an engine that an implementer has to make and all the sugar is built on top of that it would decrease the difficulty of making a new engine and maintaining the existing ones

[@Chris-on5bt]

Read 'new domains' point on the slide deck and was like wtf who does serious financial programming in JS. Then literally Prime and the whole chat agreed. Its the Primehivemind.

[@felipesharkao]

I sadly do financial programming in JS. I wish I didn't, but I do

[@dimlylitcorners]

In a better timeline: 1995 Netscape left it as the original JavaScheme and made it even more Scheme- and Self-like. Gave the browser a smart JavaScheme implementation with caching, optimizing, jit compiler. Added new language features exclusively as build time macros. Put all the JavaScript sugar in an (optional) external tool chain such that JavaScript is never seen by any browser which only run the optimized JavaScheme really fast

[@serenditymuse]

Thanks for coverage of HTTP2 and HTTP3. Very clear. The thing that bugs me about JS tooling is that most of it is written in JS which isn't a great language for building new language features, real macros and so on. Would love it if Scheme or Common Lisp was used for extensions. :) Or just write in those in the first place and it auto transpiles to something browsers or V8 understands. I can dream can't I? Screw decorators? Why? Just a higher order wrapping function. Very useful. Good luck finding problems in those layers of transpilers. Especially if as a senior dev you have to understand something about all of them as is the case in current tooling.

[@Lord_zeel]

13:25 I recently started using Decorators (via Babel) and I'm loving them. But yeah... we need tooling that understands them or debugging, and we aren't going to get that util they are implemented in engines. It's not too bad though, and the neat thing is that once you have the decorators working you basically forget that they're there.

[@msclrhd]

Debugging is going to be interesting when wading through tons of transpiled code!

[@VV-nw4cz]

Go iterators are extremely simple. The key thing with them is that for ... range ITERATOR does not do the iteration anymore, it is like a func that calls a function that has for loop inside.

[@AllanSavolainen]

The nice thing about JS has been that I can modify and run it without compilation. This would mean that vanilla JS devs would be forced to use JS0 with limited features. Browsers should have the latest and greatest version of JS. Backend people can do compilation and during that add features their JS server doesn't support.

[@DaVince21]

That presentation is the funniest thing I've seen come out of a corporate environment in a while.

[@ivanjermakov]

It would be cool is JS had some kind of "primitive mode" where you can only use a small subset of features in exchange with JS engines being able to squeeze more optimization out of it. Or we should keep JS alone and improve WASM infra because it is the same niche.

[@meryplays8952]

Doesn't sound a bad idea. What I'm suspecting is they intend to merge Dart VM+ JS VM work in one virtual machine and re-implement Dart as a transpiler on top of JS0. Not bad at all. It may benefit projects like Clojurescript or Scala.js.

[@konberner170]

The good news is that because the tooling here is so simple, the attack surface to add new backdoors will be mostly fixed ;)

[@jeffreyblack666]

My understanding of what they were saying was more like TypeScript would become JSSugar, with extra features added, and that gets converted to JS0. Better words for helping: JS0 can just be called JS, or javascript. JSSugar can instead be called JSMaker or JSHelper

[@snowman1185-v]

Love these break downs.

[@MrDraganox]

I was waiting on this video, finally 🎉

[@HudsonAfonso]

They Are Multiplying!

[@ludawig_]

I'm so glad I do most of the time backend stuff without JSSugarMommy's. 👍Why not improving WebAssembly or creating a new more complete native JS alternative?

[@gustavcoetzee5018]

great vid. i used udp playing with micro controllers. learned so much.

[@digiryde]

Decorators are awesome for the holidays.

[@lerdev]

i like JS, like how alive it is! Debats, improvements, evolution... its super cool!

[@juliegredler5636]

Come for the debats, stay for the dumpster fires!

[@ijchua]

14:51 Python's iterators are excellent

[@fennecbesixdouze1794]

Imagine imposing a pre-compilation step onto the language at the committee level but then deciding to just transpile to "JS0" and not actually take advantage of compilation to go down to something like webassembly.

[@davidmcken]

And the sheer number of UDP protocols that lack that retry mechanism, at best its a feature of QUIC or whatever built on top of UDP not UDP itself.

[@mjerez6029]

What if JS0 becomes a highly optimised language, I think mozila was already investigating think it was called asm.js this could also make javascript faster and we could apply optimisations usually applied by the compiler in compiled languages. Think something cool can comes from it.

[@UnidimensionalPropheticCatgirl]

it’s the JS ecosystem, if you manage to make it fast, JS developers will figure out how to make it twice as slow as it is today.

[@toTheMuh]

After going from new javascript frameworks everyday to new javascript runtimes every day we now will get new javascript every day

[@chadthundercock8091]

Why must we suffer? So glad to be working with C++

[@supdawg7811]

It's crazy that we could do this OR we could just simply have a consortium of browsers agree to build out HTML- and other-major-API support for a new or existing better langauge. Or really commit to WASM and supply money to those willing to spend time on getting languages to support it.

[@danhorus]

I feel like this whole proposal is an allegory. They're basically saying "instead of engines implementing new syntax in JS, let build tools implement them in TS"

[@TankorSmash]

This is how Haskell works, and it allows some cool stuff. I'm all for it

[@DrownedLamp9]

...And woukd you like sugar or sweetener in your coffee? Mr.Script: Yes

[@karakaaa3371]

That last paragraph is really citation needed. I really doubt most developers are hobbyists using vanilla js.

[@luizgrocco]

I love the proposal, imagine if we keep decreasing the size of JS0 so that engines have to implement less and less which guarantees security and less bugs on the engine side, and JSSugar would just compile to that. And maybe further down the line we make JS0 so minimal that it is actually more like bytecode, a kind of assembly language. Wow, if that happens maybe even other languages could compile down to that and we could make JSSugar whatever language we want. Oh wait, that already exists and is called WASM!! Why the f not just make WASM better with direct access to DOM apis and stop the madness???

[@petzilla999]

the best UDP explanation i've ever seen

[@allNicksAlreadyTaken]

If you don't want to impact performance and security, just implement the JS0/JSSugar split yourself. Do a precompilation step and only emit more text that will be interpreted by your JS0-interpreter. Why do they no just do that? This also leaves the door open to potentially adding specializations and optimizations to high-level constructs that would be part of JSSugar. It would suck to be in a situation where certain constructs get compiled to JS0 inefficiently without any way to do it properly, but information was lost, so you can't generate better code.

[@Wワイ]

Launch Promote Abandon

[@mikescholz6429]

Am I the weird one then for writing regular spec compliant JavaScript? I got in a lot of trouble in school (mostly math) because I refused to do pointless things that were a waste of my time to still get the right answers. This is what TypeScript feels like to me.

[@YassineMikeAlpha]

Wasm keeps improving day by day

[@YT-dr8qi]

So JS0 is gonna be a bytecode(-like) for web which is JIT compiled by a browser later

[@grug_smash_keyboard]

i dont think this is necessarily a bad thing, we already have languages that compiles to JS (gleam, reason, elm). Splitting the language changes the decision making as well, now JSSugar is just another language that will need to compete with all these languages for front end development. Slowing down development on JS0 can also help these languages and other browsers to catch up in terms of compatibility @21:00 not sure if prime is serious, by this logic JSSugar and TSSugar should compile directly down to JS0 lol

[@elzabethtatcher9570]

The single thing that JS maintainers had to do 15 years ago, was to allow devs to write typed variables, sorta like PHP did back then. That way there would be no need in TS, transpilators, and all this shit,

[@MrMysticphantom]

To me this seems more like a Linux type scenario.. where JS0 is the kernel and the Sugar is the distro level

[@rmidifferent8906]

Another year of making JS better for beginners

[@br3nto]

Yeah I’m moving more and more to the no-build camp. This craziness is adding more complexity not less. I don’t think the extra complexity is worth it. If there was a clear path to simplicity, and we had to get more complex first to get to the simplicity, then sure. But I can’t see how this solution leads to simplicity… the proposed solution is basically a complexity multiplier.

[@josh.salles]

You Pavlov'd me into eating candy by saying sugar too much. I'm blaming you for this

[@szeredaiakos]

Sending down bytecode has no mentionable immediate downsides. You can compress it if it gets big. The problem is that all those JS runtimes developed have no particular use anymore (sunk cost fallacy),.. and it'll get hard to gather insight what that bytecode does, so it also can have a security problem. A common intermediate language could work .. but then you also ask the question Why? There are no real arguments for either of them. Performance? 99% of applications do not need more performance.

[@VelcorHF]

What does Firefox think? Cause Google already laid off my opinions and I’m over chrome. Why does the open source community have to please a publicly traded company with insane profits.

[@karola.7908]

won't JSSugar be basically what TS is today? If so, wouldn't it just be better to incorporate TS into the standard?

[@isaac_shelton]

I'm personally looking forward to multiple source maps per file

[@Altrue]

Yes, if there's anything JS needs, it's MORE complexity, MORE variations, and most importantly, Google in control of yet another web thing.

[@MyAmazingUsername]

9:44 Steak Holders? 🥩

[@untoldhorrordude]

There's JVM, CLR, V8, SpiderMonkey, WASM, Kismet (Unreal Blueprints), HashLink, and a whole ton of other language VM's. There needs to be a language VM standard instead of this mess. It's almost like there's a need for a compiler framework that supports JIT and compilation to an assembly/bytecode format...sounds a lot like LLVM or something.

[@forrestforce]

ight im retiring. I only code for my own side projects now but this ecosystem is straight ass nowadays. The amount of not language specific things you need to know to run a piece of code now is straight ass. ass cheeks.

[@chonchjohnch]

Isn’t it transpiling, not compiling? I’ve never understood this nomenclature amongst web devs

[@fennecbesixdouze1794]

The security argument here is literally bonkers: Either the engine maintainers implementing the features will have the burden for security, or the tools transpiling JSSUGAR to JS0 will have the burden for security. I'm pretty sure I trust Google to get V8 right better than some rando's fragile house-of-cards build setup. Not to mention if the burden is on the people transpiling JSSUGAR to JS0, once it turns out that their transpilers are not implementing some feature securely, not only do the transpilers need to put out a fix, everyone who has the vulnerable JS0 code released now needs to recompile and re-release their code, instead of V8 just putting out a security patch.

[@nightshade427]

so we will have a browser based language that isnt the actual language, but a subset of the language that is sort of frozen that we then use a seperate tool to compile the real full language. So no build and web as learnjng platform is dead? What about browser console and debugging, can only use the subset not the full language?

[@pseudonymity0000]

Can we please just admit Javascript was a mistake and switch to Lua for web scripting already?

[@IvanKleshnin]

Lua is slow AF

[@pseudonymity0000]

​@@IvanKleshnin Tell that to all the game engines.

[@phatkin]

Lua *is* slow af. game engines love it because the compiler is really small, and it doesn't use a bunch of RAM.

[@fluffymcdeath]

We need to progress languages so that perfectly good programs will stop working if the maintainer goes away thus opening up a niche for new programmers. Solved problems cannot be allowed to remain solved. That would be anti growth.

[@impostersyndrome7175]

With so many devs out there using JS and TS, I think there will be a lot of pushback for such dramatic changes. I feel like I am getting old because I just can't understand how devs are happy with how we have to create code for the web these days. I love implicitly typed TS, but I draw the line when I have to use a complicated build step. TSC is all I use in my builds, and I output in the latest JS into lots of files that use ES imports. When I need to troubleshoot, its basically the same code as the TS but without types. Source maps not really needed.

[@limpiadora]

23:49 I don't know if he's joking or what!? but this is probebly not what's gonna happen, typescipt will impelment jssuger and transpile it to js0, becase this already happen, you can define what's the target you wanna compile in the tsconfig!