JavaScript Is Becoming 2 Languages?? FROM TC39

[@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

[@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?

[@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

[@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?

[@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.

[@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

[@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.

[@srinthildev749]

Just like its frameworks, the JS itself will multiply

[@justsomeonepassingby3838]

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

[@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

[@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.

[@BlackwaterEl1te]

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

[@spicybaguette7706]

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

[@warrenarnoldmusic]

Your request aligns with mine DietCockJS😅

[@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

[@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

[@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 ?

[@clem-1917]

This is how we defeat AI programmers.

[@furinick]

Do nothing and just wait for updates? Perfect!

[@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]

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

[@D0Samp]

All current TCP stacks also support Selective ACK, in which the receiver can submit multiple ACKs to explicitly request lost packets in the last transfer window instead of just acknowledging the first continuous set of packets. In particular, it's essential to avoid the slow start problem in which the window size is only increased slowly because packet losses keep it small.

[@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.

[@karakaaa3371]

Nothing precludes them from eventually moving JSSugar features into JS0 once it is popular and has clear benefits to being implemented natively.

[@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

[@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.

[@jhonatanjacinto]

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

[@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.

[@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

[@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.

[@thrash1337]

What could possibly go wrong

[@_FFFFFF_]

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

[@spicybaguette7706]

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

[@marcopollom]

Split it into java and script.

[@ReedoTV]

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

[@SandraWantsCoke]

JS is great for finance, "100" + 2 = "1002". You can make money out of thin air!

[@ReedoTV]

@@SandraWantsCoke My "JS for Day Traders" course is only $10,000 on Udemy!

[@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"

[@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 :/

[@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.

[@kupopo1]

21:00 My expectation is that TS would transpile directly down to JS0 (or at least have an option to). If you're currently using TS and/or a bundler/optimizer, you won't need to add any additional tools you're not already using.

[@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.

[@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.

[@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)

[@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.

[@Klaus-bm5ek]

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

[@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

[@nightshade427]

and they say cpp is bloated, welcome to js where we have a compiler for your transpiler for your interpreted language because the engines don't want to try and keep up with the bloat anymore

[@annoorange123]

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

[@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”

[@snowman1185-v]

Love these break downs.

[@toTheMuh]

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

[@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.

[@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!

[@M0du5Pwn3n5]

"They argue that new features are placing a performance...burden on JS engines" But, if they aren't allowed to even know the constructs are being used, if they have to desugar to JS0, then surely that would place a greater performance burden. That means anything added to JSSugar fundamentally cannot be easily optimized. It sounds like they are basically saying "sure, but it won't be our job anymore so that's fine". The fact that they have to confront perf questions right now is GOOD. It is what prevents us from returning to the dark ages of a million footguns from language features that you shouldn't actually use because they annihilate performance (as opposed to only about a thousand of those right now).

[@HudsonAfonso]

They Are Multiplying!

[@MrDraganox]

I was waiting on this video, finally 🎉

[@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!

[@xxXXuser69420XXxx]

nothing but Big Decorator propaganda

[@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.

[@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

[@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

[@p-j-y-d]

"State of JS development today already requires tooling to be productive & competitive. No evidence suggesting tooling use would decrease in future." So they want to irreversibly worsen the state of affairs. 🤮🤮🤮

[@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.

[@DaVince21]

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

[@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.

[@IARRCSim]

21:30 If JSSugar is essentially testing demand for proposed features that just might end up in JS0, wouldn't JSSugar have breaking changes frequently? My understanding is that the TypeScript would just transpile directly to JS0(the JavaScript that runs directly in the browser) like it does now. I can't see an advantage to translating into a language that needs to be translated yet again. That would be needlessly inefficient and more bug-prone than going directly to a very stable JS0 standard. JSSugar will be a very unpopular, rapidly changing standard that has some transpiler tools competing with TypeScript. Why would anyone use JSSugar? Why not JS0 so there is no transpiler, source maps... or use TypeScript which has better stability than JSSugar, better static code analysis, and better developer tools?

[@alexholker1309]

Only if the syntax changes between JSSugar and JS0 implementations, or the JSSugar implementation is removed before the JS0 implementation is added. It's more likely that for a few patches both the JSSugar preprocessor and JS0 would have support for a feature, in which case JSSugar would continue transpiling to the original JS0 equivalent despite JS0 now natively supporting either version.

[@rns10]

12:01 that person means Oracle will kidnap him over trademark copyright misuse of js name.

[@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

[@YassineMikeAlpha]

Wasm keeps improving day by day

[@karakaaa3371]

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

[@NakamuraSatou]

I honestly don't think the person who wrote this knows anything about interpreters. Whoever wrote this was basically saying it's hard for a billion dollar company like Google to have an interpreter that implements all those syntax sugar so we should instead rely on some random startup or individuals to add the exact same feature in their whatever transpiler. If a syntax sugar can be implemented via a transpiler, it's also trivial to implement in the browser. The whole point of letting browsers implement those features is so that they might be able to do some additional optimization.

[@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.

[@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???

[@jamesdrummond187]

This reminds me of "Interview with Senior Javascript developer"

[@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.

[@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.

[@l10nbit]

This is just an attempt to keep the feature creep at bay. Now they have a reason to say no, you can put this in Sugar. The unfortunate side-effect is that they are embracing the "build step". This paves the way for wasm only browsers once a "direct wasm-browser interaction API" is passed.

[@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.

[@lorenzrosenthal119]

7:42 ok but what about UPS?

[@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.

[@konberner170]

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

[@rudde7251]

Why not just give WebAssembly access to the DOM and compile js straight to WASM at this point?

[@UwU-f2a]

there reason why there is no direct access from wasm to dom is because security reason and big effort. in currect model, WebAssembly interact to the DOM via javascript. This was a compromise to reduce attack surface and implementation effort, to get a version 1 out the door. Allowing direct DOM access would have required implementors to harden every individual DOM API to make sure the new call path doesn’t open any security holes, thats mean isnt not easy, maybe need long time and people just isnt interested in it since javascript in frontend is already very fast, the bottleneck usualy lie in the backend

[@xxXXuser69420XXxx]

@@UwU-f2a "javascript in frontend is already very fast" categorically false. gaslighting dare I say. any serious app 1. isn't using js in the backend. 2. lazy loads 95+% of all its js because of the insane slowness of JS, (skeletons/loading indicators, ring a bell?)

[@Dylan_thebrand_slayer_Mulveiny]

"Yo dawg, i heard you like transpiling languages..."

[@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.

[@ferinzz]

So basically they're seeing everyone rely on frameworks to do anything and say "Ok, JS is just an API to frameworks. No programmers are going to learn anything more unless they're building the frameworks" Seems weird. But also this is why I don't want to get into web dev.

[@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.

[@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

[@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.

[@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

[@xxXXuser69420XXxx]

@@felipesharkao my condolences, don't let it ruin you, get help brother, you are valuable and loved and programming critical systems in js is no way to live

[@DaVince21]

Honestly, this doesn't sound too different from, say, Java compiling into bytecode. Actually, we already have a bytecode-like format in the browser! It's called WebAssembly! Why not go in _that_ direction, put the focus there, compile it to _that?_

[@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.

[@ijchua]

14:51 Python's iterators are excellent

[@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.

[@gustavcoetzee5018]

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

[@YT-dr8qi]

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

[@CricoKiss]

I think JS needs to "freeze" and avoid crazy new syntax that few are actually using. If you need something that the vanilla JS syntax doesn't provide, then use Typescript. But having a new standard will make the ecosystem even more confusing. It's the wrong solution to a real problem.

[@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?

[@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.

[@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?

[@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!

[@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.

[@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?

[@digiryde]

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

[@thechosenone729]

Im literally thankful that i avoided any web development since this is becoming more and more horror like.

[@gustavcoetzee5018]

Will it not make things just more confusing.