JavaScript Is Becoming 2 Languages?? FROM TC39
ฝัง
- เผยแพร่เมื่อ 21 พ.ย. 2024
- Recorded live on twitch, GET IN
Article
caolan.uk/note...
By: Caolan McMahon | x.com/caolan?l...
My Stream
/ theprimeagen
Best Way To Support Me
Become a backend engineer. Its my favorite site
boot.dev/?prom...
This is also the best way to support me is to support yourself becoming a better backend engineer.
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagen
Kinesis Advantage 360: bit.ly/Prime-K...
Get production ready SQLite with Turso: turso.tech/dee...
I'm sure this won't have any adverse effect on the number of javascript frameworks
metaframework for metaframeworks
We need to identify as meta frameworks
I think infinity minus one is still infinity , and infinity times two is similar
every framework will have it's own special version of javascript
Didn't know they redefined "No effect" to exponential growth
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...
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
I mean thats been done for years and years and years, long before wasm. v8 has bytecode after all :P
@@lucidattf the same thing, they are dual to each other
@@lucidattfnope, it compiles to js0, not javascript
@@MsBukke js0 would be equivalent to what engines run today, it said in the article?
JS0 - healthy JS
JSSugar - sweeteners added
JSDecaf - Decaffeinated JS
JSCaff - Caffeinated JS, full of your thrills and frameworks
Coffeescript is back 😎
JSDiabetes, what happens when you use too much JS
JSSoy - wait that's just JavaScript
JSAdderall™ -- VC-sponsored AI-backed JS to achieve the smallest time-to-market values
jsdefecated
Javascript, the language that keeps on giving. Giving what I'm not so sure.
giving cancer
it gives c4nc3r
Aneurysms. It keeps giving aneurysms.
6 figure salaries
@@adeidara9955
Why can't we just make WASM better, this is ridiculous
The problem is JS. We need to get rid of JS, not try more and more absurd ways to "fix" what is fundamentally broken.
Because wasm cant be put into a script tag and just be executed, but instead must be compiled and provided on a separate url.
@@mrkostya008so you would rather compile, minify and bundle your augmented javascript into compressed files provided on a separate url ?
@@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)
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.
I clicked view source, and the next thing I knew, I woke up hog tied in the trunk of a car, halfway through Mexico.
First time?
Just like its frameworks, the JS itself will multiply
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!
Compatibility
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
This
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.
@@fuzetsu That's not very practical.
All I want is a JSSugarDaddy. Is that too much to ask for?
Your request aligns with mine DietCockJS😅
Son: Father, why did the world end? Father: Son, the JavaScript developers who could, never stopped to ask themselves if they should.
JavaScript about to implement IRL access, modify the world to your wishes... it was all a mistake.
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.
Are you using common sense? You do know that's heresy, right?
" Just push browsers for direct DOM access " that's the problem, they don't want to create the darned API
"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
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.
@@monad_tcpyou know WAT exists right? It’s the textual version of web assembly
Nothing an extra layer of indirection can't solve.....
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.
isn't that kind of the idea behind JSSugar? to bring these tools more into the standard
@@xybersurfer no, retard. JSSugar will require a build step to compile to JS0 if that idea gets implemented.
@@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.
@@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.
@@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
Since we got that far, how about adding a Python syntax, compiled to typescript compiled to javascript compiled to compressed minified bundles ?
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
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.
@@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!
@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 ?
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
JavaScript was a mistake 🙏
React was a bigger mistake.
from web dev , I agree
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.
So? What are you gonna do about it? Learn it, use it, get the job done!
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.
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
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
Not me I work in C++. I just came to watch the world burn.
cppfront 🤷♂️
What do you do? Where do you work?
at least in the JS world you don't need to use CMake and visual studio
@@erasehehe at least we aren't compiling an interpreted language
Same here, I'm cooking with Go.
Wanted to say they should make JS into NULL languages instead of 2.
This is how we defeat AI programmers.
Do nothing and just wait for updates? Perfect!
Cant wait to see how js devs deal with multiple toolchain debugging.
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.
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.
Skill issue ngl
@@remmoze 100%
Yeah the optional chain and null coalescencing was a real nice addition.
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.
Nothing precludes them from eventually moving JSSugar features into JS0 once it is popular and has clear benefits to being implemented natively.
Thank you for doing these. You help me get through tough times!!!
The "I don't want to be disappeared" got me laughing really hard indeed...
Fireship is going to have a field day with the concept of js assembly
asm.js (low level subset of js) was already thing mozilla cooked up, and wasm is still a thing.
@@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 :/
Honestly, the V8 devs kinda did this to themselves didn't they. Something something induced demand
You already have wasm, why do you need to split lang? Make js deprecated and move to ts to wasm compilation - that's all
Make JS and TS deprecated and allow Rust on the web or its intermediate representations
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
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.
@@markmywords3817 Deprecated code can still be used, it's just not recommended anymore.
@@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.
Finance in JS is asking for trouble.
It will end up with Array.finSort
JS is great for finance, "100" + 2 = "1002". You can make money out of thin air!
@@SandraWantsCoke My "JS for Day Traders" course is only $10,000 on Udemy!
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.
also SACK deez nuts
Front end was a mistake.
Nah, php takes this crown.
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
Just plug them into the matrix
Since this is a weak argument, have a weak response: "so is your face".
@@SpeakChinglishit's not an argument, it's a statement
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.
"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. 🤮🤮🤮
Love it when they make an excessively complex framework even more excessive. I'm sure this won't mess anything up.
16:10 did you just tell me to go func myself? 🤐
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
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)
They Are Multiplying!
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"
Wasm keeps improving day by day
the specification must expand to meet the needs of the expanding specification
Yes, if there's anything JS needs, it's MORE complexity, MORE variations, and most importantly, Google in control of yet another web thing.
After going from new javascript frameworks everyday to new javascript runtimes every day we now will get new javascript every day
That presentation is the funniest thing I've seen come out of a corporate environment in a while.
Love these break downs.
I was waiting on this video, finally 🎉
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.
Decorators are awesome for the holidays.
i like JS, like how alive it is! Debats, improvements, evolution... its super cool!
Come for the debats, stay for the dumpster fires!
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
Oliver - "Please, Sir, May I have MOAR?"
Google - "You WANT MOAR?"
Also Google - "Cook it in your own pot, though."
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???
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.
the best UDP explanation i've ever seen
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.
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”
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
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.
Launch Promote Abandon
great vid. i used udp playing with micro controllers. learned so much.
This is how Haskell works, and it allows some cool stuff. I'm all for it
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.
I sadly do financial programming in JS. I wish I didn't, but I do
@@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
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.
That last paragraph is really citation needed. I really doubt most developers are hobbyists using vanilla js.
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
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.
This reminds me of "Interview with Senior Javascript developer"
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.
The good news is that because the tooling here is so simple, the attack surface to add new backdoors will be mostly fixed ;)
"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).
14:51 Python's iterators are excellent
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.
Debugging is going to be interesting when wading through tons of transpiled code!
nothing but Big Decorator propaganda
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.
Nice! I always wanted zero JavaScript in my projects
Split it into java and script.
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.
Im literally thankful that i avoided any web development since this is becoming more and more horror like.
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.
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
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.
Can we please all pull together and make JS zero languages?
It amazes me how the JavaScript ecosystem manages to become worse and worse :D At this point they should just make WASM first class in browser engines and let JS become a compiled language, that also compiles down to WASM. Would also make things easier for folks who want to run JS on the server (for whatever reason), if it could be compiled to a binary.
Why must we suffer? So glad to be working with C++
If you just work with C++ then how are you suffering from this?
I wish there is more work with c++
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?
9:44 Steak Holders? 🥩
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.
For sure, JavaScript isn’t approachable to beginners because it is too compact. Moar stuff!
All of the available programming languages are too complicated! I'm going to make a programming language that's simple, for the people! Oh, but, y'know, this'd be a nice feature... Ooh, and we _have_ to have regex pattern matching... hmm, and templates would be nice...
My old programming language is too complicated! I'm going to make a programming language that's simple...
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.
12:01 that person means Oracle will kidnap him over trademark copyright misuse of js name.
I'm personally looking forward to multiple source maps per file
Another year of making JS better for beginners
0 days since last "game breaking" javascript news
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.
They should just use a VM and allow many frontends to be implemented, i.e. many languages. This is how the JVM works with so many languages running on top like Scala, Java or Kotlin, same with the .NET runtime and C# or F# (or even Java and Python) running on top... they all then compile to an IL (intermediate language) that the runtime interprets. They should build this on top of WASM perhaps. What I want ultimately is to stop shipping text and ship binary IL and for us to be able to write in our favorite languages. Or at least something better than TypeScript.
RIP the fly in this video.
...And woukd you like sugar or sweetener in your coffee?
Mr.Script: Yes
You Pavlov'd me into eating candy by saying sugar too much.
I'm blaming you for this
If you want to get humbled as an experienced JavaScript or C# or Java or Go or [insert language here] expert ... sit next to an experienced Python developer for an hour and try and write the same thing as them in an hour. Fucking Python is (and I hate this fact) the most productive language in the world syntax-wise. Performance is shit, but there is no logical reason why the other language compilers couldn't use the Python syntax (that I can tell).
I see you have this new feature... have you met my good friends... SECURITY VULNERABILITY and his best friend... SUDDEN DEPRECATION.
Welcome to the coolest coffee bar in town... SILVERLIGHT, MOVE YOUR FEET AND MAKE WAY FOR OUR NEW FRIEND. Take a seat, you will fit right in here... [promising but rarely used codebase]
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.
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.