The New JS Features Coming Soon (I'm so hyped) 

Theo's lack of knowledge here was... surprising. Not saying base 10 numbers wouldn't be useful to have in JS... but it makes perfect sense that it's not the default.

​@@DavidMulderOne This guy doesn't spend more than an hour on these reaction video's. Lazy content.

I wish it was a more well known fact about the nature of floating point representation. I've seen floats used in situations where the dev was clearly just using it for a lazy convenience, but totally ignorant of the loss of precision they'd just created. Especially bad, because many times those numbers represented financial values.

Yes - I though this was well known. I imagine the advantage of using binary encoded floating point is that it can use the native CPU support for floating point arithmetic if present.

I'm sure he knows it follow the ISO-standard, it's just more fun to complain about javascript.

totally, google, an US company owning the web is an incredible threat

Especially considering that Firefox does often is not slow to implement, but they have good reasons to not have some web APIs or are not agreeing with the implementation

Yeah, what are these awful takes. Isn't this common knowledge at this point?

He still fanboys apple despite their constant anti-consumer attitude.

Chromium has a near-monopoly because it is better than the other browsers, they're not doing anything wrong. Nerds will complain on the internet but most of you will never even _attempt_ becoming a Firefox contributor, your loss!

@@pokefreak2112 Chrome has a monopoly because Google controls Google Search and Android and showed Chrome down our throats for the last 10 years. It's not miles ahead of other browsers in anything really. Not saying it's not good, just saying it's not that better than others. Although there was initial period when Chrome appeared when it really was a breath of fresh air in browser wars.

@@pokefreak2112 🤣 You're trolling

@@tiedye001 Not really though. Between Chrome 124, Safari 17.4, and Firefox 125 on Can I Use, Chrome has almost all of the features supported or at least partially supported, where as Firefox and Safari have a lot more Red than Chrome

Not sure if it was meant to be funny? The fact that engineers from both Google and MS are going full time on V8 while Gecko is being starved to death with barely minimum resources. Saying Firefox is holding back web is like saying the resistance is holding back the world domination. smh

comparing multibillion orgs with non profit mozilla and saying that it lags behind sure is strange move

Yeah it's a silly comment from him that doesn't seem to understand that Chrome and Edge are basically skins on top of Chromium. There are also instances where Firefox had support for something years before Chromium. For example subgrid is one of them and also animating some flexbox features. To be honest, In the last few years I had way more issues supporting Safari than I've had Firefox on anything I've worked on. Safari and especially Safari on iOS always have the weirdest issues. It's actually admirable that Mozilla is managing to keep up with Chromium at all considering the lack of resources.

@@rand0mtv660 I think Theo is laughing his ass off seeing how a handful of people are triggered for no reason lol. He prolly understands the gravity of his statement, but he just likes to have fun with Firefox people haha.

​@@ky3ow So, let's talk about Safari

What does polyfilled mean?

@@Darkstar159 A third party library/your own custom implementation that fills the missing feature.

As I've mentioned in one other comment, I personally had way more issues supporting Safari (especially on iOS) rather than Firefox. But Safari team is definitely stepping things up, I think in the last 1-2 years they invested significantly more effort into Safari and implementing the spec. Only downside is that Safari is still tied to OS updates and not independent so people that don't want to update the OS also don't get latest Safari.

Agreed, safari can be awful.

Safari has soo much bugs we have to mitigate on my work...

If we go into complex numbers territory, then we should also add GA rotors.

It has BigInt, though 🙂

@@EdwinMartin BigInt != BigDecimal

@@MelroyvandenBerg Klopt

I had to implement my own Decimal type for counting money which is perfectly discrete to the cent

a feature that is polyfilled so holding back slight performance gain not the feature as whole at all XD

Looks more like Java's stream api

it's funny to see js becoming c#

@@mrkostya008 they’re all just specialized monads in the end, so same thing different name

@@mrkostya008 It's LINQ. Plain as day.

If he this excited to see literally LINQ from C#... it's 2024. LINQ was there in 2007, and it borrowed from Haskell. But never mind. If this guy actually saw what LINQ to SQL does. I don't think he'll understand it at first. And then he'll have a "holy shit!" moment six months later. We won't get into building LINQ expression trees

All numbers in JS are floats.

Tbh I’m just waiting on full type / ts support

No one did. People moved back to loops because they are simple to write, simple to edit, easy to get performance, often easier to debug, and everyone knows what a for-loop is regardless of background and skill.

It might not be a perfect take, but I have several guesses: 1) AFAIK, workers require an event listener or a broadcast channel, this might make it harder to get a type safe implementation with typescript (without a library to abstract it or some type magic) 2) I'm not certain about the efficiency of instantiating web workers. A quick google search got me 40ms, it's probably inaccurate, but it sounds about right. What we want from web workers isn't fast instantiation. In the case of the shadowrealm, you'd expect a realm to be fast to initialize and throw away. 3) Web workers don't exactly have the same environment as regular js land. You might want your "unknown" isolated code in the shadowrealm to be able to access every single JS API while isolated. Workers are known to be workers at dev time, we don't expect realm code to know it's in a realm and still run just fine. 4) Going back to efficiency, because the shadowrealm does not serialize or deserialize, it's also that much faster. It still uses the heap instead of reserving its own memory. In that sense, it's weaker isolation, but it fulfills its purpose.

The api is very different, workers need explicit communication back to the main thread but the realm stuff is just calling a function so theres no 'contract' the code in isolated realm needs to uphold

@@TurtleKwitty Yeah, it's single threaded and the API is quite different. I was mostly responding to his comment that it would allow for new stuff. As far as I can tell you could polyfill ShadowRealm's API fully with web workers (it just would be multi threaded)

You mean Java *finally* got it in 2014 after C# introduced LINQ in 2007?

It was pretty trivial to create map function for iterators already, these extensions just make it a little bit easier and more natural. eg. a map iterator function -> function *map(i, fn) { for (const a of i) yield fn(a); }

⁠@@proosee oh, you mean the stuff that Haskell has had out the box since at least Haskell98 and most likely even Haskell 1.0 from 1990? (which is before Java and C# existed)

@@asdfghyter yes, but well, don't judge me if I don't count Haskell as mainstream, widely used, well supported language. Maybe when Haskell earn some decent package manager after existing for over 30 years then I will reconsider.

@@proosee sure, it isn't mainstream and it certainly wasn't back then, but that's kind of the point. mainstream langagues are very slow to adopt good features from more academic languages like Haskell. And as I said, it existed even before someone had considered making either of the languages, so they don't have the excuse of it being something new

Me too. In my job we slice and dice and compare and add time, dates and durations. We have a lot of legacy horror that is going to be dumped.

I started using the temporal polyfill for now and it's great. Only downside is converting back to regular dates when interfacing with other libraries

I've read your comment a few times and I'm still not sure what you mean exactly. Regarding the closing of the underlying iterator when take() is exhausted, it's not an obligatory side effect of the iterator protocol but a deliberate choice by the authors of the proposal to avoid memory leaks. Iterators may have resources that must be freed, but they can't until the iterator completes. Let's say you've got an iterator that reads a file line by line. First, it opens the file, then it yields a new line after each next() call until it finishes, then it closes the file. If the file is 20 lines long but you only take 10, the file would never be closed if take() didn't call return() on the original iterator.

@@piaIy If take built an iterator that passed the done flag at index i, yet could continue after said flag, it wouldn't be an iterator. It'd be some sort of zombie hybrid type gluing two iterators together. The best way to insist on having that implementation would be to have an additional exhausted flag or an exhausted method. The done flag does not just indicate the end of the iterator, but also the exhaustion of said iterator. An exhausted iterator should be thrown away, and going against it would mean that every library developer would have to deal with the possibility of a second iterator hiding behind the first, either ignore it (no code change, but an unsupported feature) or handle it (code changes everywhere).

​@@Exilum these methods create a new proxy iterator that delegates the calls to the inner iterator, but it also has its own state. If you have an infinite iterator named _x_ and you define _y = x.take(1)_, it won't mutate x right away, you can still call x.next() as many times as you want to get the next value. Only when you call y.next() for the 1st time will it mutate x and jump to the next value, and when you call it again, both will be done, including x. But this last behavior is an implementation detail for extra safety, you could still write your own take(innerIterator, limit) generator that would yield the value of innerIterator.next() in a loop up to the limit, then return without closing the inner iterator. Your take generator wouldn't yield any new value, it would be exhausted without affecting the other, but then you would be responsible for cleanup (you could call innerIterator.return() to accomplish this). It's even possible to get around the cleanup behavior of the built-in take(); you can wrap the yield statement in a try-finally block and change the control flow, like using continue in a loop, but this has its own drawbacks, like making it trickier to intentionally close the iterator with return().

implement IDisposable interface perhaps?

The proposal only adds a mechanism of enforcement, and whether a Disposable requires `using` or not is dependent on the library defining the Disposable. Language designers are not enforcing `using` in general; it is opt-in (for libraries). > Were such enforcement to be mandatory, these hosts [Node, DOM, Electron etc. who provide disposables] would need to implement and maintain a completely parallel set of APIs purely to support using. As a result, we are proposing this as a purely opt-in mechanism that could be leveraged by new APIs that need stronger enforcement guarantees. And it's also still stage 1 anyways. If it still doesn't sound like a good idea, now's the time to strike it down.

Disagree, this is how memory leaks happen. The language should prevent the programmer do be able to do dumb things like never dispose resources, but also provide interfaces when you want more control.

@@kisaragi-hiu I understand that it is an optional and separate from the primary Disposable of the proposal, however the fact that it exists is a problem, as inexperienced or close-minded developers won't see the difference between the APIs or will not be open to changing a forced API to a non-forced API.

@@neociber24 At the moment, it is easier than ever to not dispose resources, and `using` will only make it harder. That doesn't mean you should make it 100% impossible to manage disposables because of a few clueless developers. Having a forced `using` disposable is as dumb as the leniency of ==, and if it gets through there will probably be a feature added in the future that allows you to bypass the forced `using` just like ===. Let's imagine that you have an API that returns a `binaryStream` that can be read from and written to. In this hypothetical, the stream only accepts bytes on its `write` methods and implements forced disposable. Now, you have decided that you need to write some strings to the stream, however manually converting to bytes is a little tedious. The solution is to create a `binaryStreamWriter` object that takes ownership of the stream and exposes both byte and string `write` methods. Now realize that the existence of the `binaryStreamWriter` object is impossible because of forced disposal. Forced disposal does not allow for transferring of ownership because it will always be disposed by the scope it was declared in via the `using` keyword. Even if you were to fetch the `binaryStream` within the writer, you still would not be able to store it as a property of the writer because it would be disposed by the scope of the writer's factory method. The only true way around it is to use a separate thread that never exits the factory method due to a `while (true)`, and that is arguably way more harmful than forgetting to (or not knowing to) dispose resources. So I ask again, why would you hurt experienced developers just because of a small subset of clueless developers who do not know how to use a language.

What is Quantum here? The Firefox redesign you mean? And why do you think Chromium has terrible UX? I think Chrome browsers in general have bad devtool experience (atleast the looking part) but from a user perspective, i think its fine.

@@ark_knight Quantum is the browser that replaced Firefox, different goals and priorities, but the legacy components can still be used to bring back most of the power Firefox had Chromium has a terrible extensions API (true, WebExtensions are based on that and most of the issues persist, but at least uBO works as expected), you can't configure your toolbar as needed, you can't remove close tab buttons that only bring despair when the browser isn't able to fully restore the state of just closed tab, no way to get mouse gestures to actually work unless implemented natively (WebExtensions force the use of ContentScripts, and these only work within the viewport, need to be injected into AL frames, and can't be injected into some classes of pages leading to inconsistent flow), the long lasting text rendering issue finally got partially patched in upstream, I think over a year after MS prepared the patch, but image scaling issue persists and don't get me started on mobile...

Only we understand.

The main driving force for adding Signals is so that we get more library integration, eg. You could create a Signal in React and use in Vue. etc. It's a bit like Promise, can you image if every lib implemented it's own variant, they would be way less useful. Now lets assume you wanted to create a Widget that worked on all frameworks, Vue / React etc, if you made the component say using direct DOM methods, your component would now work with any framework with very minimal effort.

A library could offer a native Signals build where they replace their own implementation with a thin wrapper around native Signals. The resulting library could then be smaller and potentially more performant.

Ah yes, just like we all write native web components to work with all those other frameworks we don't use

@@pairofrooks It's true Web components have not really taken off, I think the main reason is if say your using React, you will create a React component, and because State is pretty unique to React, say compared to SolidJS, your kind of tied in. But lets say you wanted to move to SolidJS, you could transition the State to use Signals, and maybe even convert some bits to WebComponents, moving to SolidJs is now much simpler. Regardless, having extra features baked into the browser like this is surely a good thing, not sure why anyone would grumble about it.