OscarDC

Transpilation is here a necessary step to test the application because e.g. his browser won't be able to parse raw TypeScript code.

Typechecking is not: the browser doesn't care about it, it's mainly to help the developer verify its code.

So to speed-up the build during development (to have faster iterations) the idea is often to make the building process only about the build by removing "unnecessary" steps like type-checking from it, while having a separate linting / typechecking etc. process, which could even run in parallel - but not be necessary to be able to test the application.

This is often done by using tools like a bundler (e.g. esbuild) or a transpiler (babel, swc) to erase the types without checking them in your bundling process.

I think we both fell in the exact same rabbit hole started in the "Immich" post today!

By the way I tried to look at the code to see where it was defined and, with difficulties I ended up founding:

https://github.com/rschristian/voldephobia/blob/1792b7c39baf...

Yes basically, it's not the same dev yet sway is heavily inspired by i3 and works with i3 config files. As you wrote i3 is x11-only and sway is wayland.

but worse in every conceivable way

I always had an issue with that sentence (and I heard it a lot). Why would experienced software developers always come with a solution worse in "every conceivable way" when implementing logic answering a problem they're having, which would have the huge advantage of being tailored for their own needs?

I'm more of a library developer than an application one but I've seen that many JS webdevs have an aversion toward trying things themselves - instead always going for the most huge/"starred" dependency when they can. I'm not sure the impact of this philosophy is always better for a project's health than the total opposite where you would just re-invent your own wheel.

I do have seen multiple attempts at doing a specific homemade architecture that worked out well for some applications with very specific needs even 10 years later (For example I'm thinking about a 500k+ LOC JS webapp - not intended to be accessed on a desktop browser, but that's not the only successful long-lived JS project I know with their own archi). And I guess a lot of webapps do have their own specific needs where the "default framework" solution leads to some inefficiencies or hard-to-maintain / understand mess.

Presumably this for now has only been seen for a specific tv client API that yt-dlp use and not all youtube videos (well, https://github.com/yuliskov/SmartTube/issues/4444 also saw it for "members-only" videos but again not all videos).

---

Also I suppose you make a reference to software DRM like Widevine L3 vs L1 (same thing for PlayReady SL2000 vs SL3000) which is not exactly Firefox vs Chrome. Firefox has even be known to work on the availability of hardware DRM on windows right now, (through the Media Foundation API I think?).

In the worst scenarios seen right now for example seen on services like Netflix, would be to only have lower qualities (e.g. 480p max) on browsers with only Software DRM available (like firefox) and encrypt better qualities with keys only available when there is hardware DRM available. Though I'm not sure YouTube would go that far for now? Netflix, Amazon and such have contracts with right-holders stating those protections as a requirement, but YouTube does not have (IMO thankfully) the same kind of relation and contract with "Youtubers".

I think that what YouTube wants to do for now is to greatly lower the amount of people not watching contents through its website/app (and thus not seeing ads). I would even think that this is mostly not about yt-dlp users, but more the huge amount of people relying on some Youtube-to-mp3 website or similar accessible tools. Here enforcing software DRM would be enough to at least temporarily break all those tools and force those users to go back on the platform I guess, and maybe you can also sue some tools' developers once there is an "encryption breaking"-mechanism embedded in it (IANAL)?

Not him but because your answer surprised me I chose to reply: at 34 it is also something I always wondered.

Becoming obese always seemed a little extreme to me and I fail to imagine how someone could reach that state without the accordingly extreme food-related habits - though maybe I'm just lucky to have the "right" metabolism and thus cannot relate.

Though even if obesity was always linked to eating disorders, I understand that "just stop" is not an appropriate response to that issue.

A particularly ugly but useful feature of "const enum" (sadly, the "const" flavor of enums are not referred to in this documentation), is that it's the only way to declare a compile-time constant in TypeScript.

e.g. for "development" vs "production" environments, you could write a declaration file for each of those envs as such:

  // production.d.ts

  declare const enum ENVIRONMENT {
    PROD = 0,
    DEV = 1,
    CURRENT_ENV = PROD,
  }

  // some_file.ts
  if (ENVIRONMENT.CURRENT_ENV === ENVIRONMENT.DEV) {
    // do something for dev builds
  }

This is however mainly useful when you're a library developer, as you may not have any "bundler" dependency or any such complex tool able to do that task.

Here, the alternative of bringing a complex dependency just to be able to replace some constants is not worth its cost (in terms of maintenance, security, simplicity etc.), so even if `const enum`s may seem poorly-adapted, they are actually a good enough solution which just works.

I read the README.md of the project but I'm still not sure: What's the expected usage of this? How does the outputed WASM code then interacts with a runtime (and with which, is it intended to be a tool compatible with browsers and other WASM runtimes or is it only compatible with a runtime linked to the project)?

Somewhat linked questions: How does it react if it encounters e.g. web APIs inside the JavaScript code or other global identifiers only defined in some environment (e.g. a recent browser, Node.js etc.)? Or if it's not intended for those environments, how are you supposed to do I/O when using this?

actively omit subtitle languages that aren't "relevant" to your geolocation. I cannot respect a service like that.

This may also be due to legal issues / restrictions in the contract they had with that content's right holders or subtitles providers.

I did not want to annoy anybody, I was just answering the "live very comfortably" part.

Yes I lived in Paris 15th arrondissement a little more than two years ago (for like 4 years?) with a less than 60k euros salary and felt personally that I lived comfortably.

Yes by most normal countries

I know that 30 square meters was comfortable to me at the time and had no shame about it. I still find that I live in a "normal country" and don't really care that much what someone from another "normal country" would use as a diminishing adjective to qualify that apartment's superficy.

is that a life frankly ?

First, it is, and I felt this part was kind of unnecessary. Founding a family is not the end goal of everyone, nor living in a mansion.

So you take a shitty salary because you’re alone or do you take money to progress in your personal life and build something like a family ?

I did found someone (to also live with) in that time period, which roughly make the same salary than I, we both lived comfortably on our own before and our combined remunerations was thus much bigger when living together which means we could afford something bigger. We decided to move from Paris though, but I also understand people wanting to stay there.

And 60k is far from shitty, even in Paris. We even considered ourselves privileged as we had a usually better salary than our friends and a job we liked.

but public transportation is a total disaster [...]

I am not that critical of Paris' public transportation, I thought it was good enough for going to work everyday or where I wanted to go most of the time.

rent.it is around 1500 minimum

I was paying something like between 900 and 1k for 30-ish (don't remember) square meters. It's for the 13, 14, 15, 18, 19 and 20 arrondissements only I would guess, and [close] suburbs.

waiting lines are in average 15 to 20 candidates per rentals

Yes that was an issue to me also. I had to send a lot of proposal everywhere to have a chance.

Telco is 50 euros min without Netflix and football and Disney or Spotify

I just checked. I have different operators for phone and internet, and I'm at 20 for internet and 15 for mobile phone subscription. I'm also very bad at managing money so I'm sure I could spend less, if it mattered to me. No idea how much I spend for electricity, gas and so on, because I've never had any issue with money.

people earning less than 4k net a month in the Paris region do look at the prices today

I did not and my girlfriend didn't two years ago look at prices when doing most day-to-day things, but maybe the situation evolved since then. Though to be honest we never lived an expensive life: we never had any TV for example nor Netflix and such subscriptions, and don't have expensive hobbies nor especially like expensive things.

Not him, but I was in the same situation (I'm still in France with roughly the same salary but not in Paris anymore).

let me guess you live in a 30 square meter hole

Living in a 30 square meter apartment was pretty normal, yes. Don't feel obliged to call it "hole", it was pretty OK when you're alone.

My rent was never more than a third of what I earned net. So generally less than 1K.

any decent car would cost you 300 € a month

In Paris you don't need a car and most people I know don't have one. I still don't have a driver's license and most people I know from my generation don't have one either. So that's not an expense.

telco bundle 100 €

For the whole Internet + mobile, you shouldn't pay more than 30 euros per month in France (which I guess is still pretty high? I'll have to look).

that makes already 3000 euros a month of spending

I was (and still am I would guess, though it's a long time since I've calculated this), spending less than 2000 euros per month. And I'm not limiting myself: I often go out in a restaurant, go to the cinema every week, don't look at prices when I'm doing grocerie etc.

To add to this, a lot of those "W3C API" (most?) (to which I'll also add WHATWG API, like HTML5 - or fetch) have actually no relation to ECMAScript and thus aren't generally in v8 because they are not JavaScript.

Those API could be thought as from the "environment" in which JavaScript run. For example we often call web-only APIs "DOM API": `fetch`, `xmlHttpRequest` and so on.

Node.js also has its own environment. For example both `setTimeout` and `setInterval`, though present in both web and node.js, are implemented differently by browsers and node.js (it's just that node.js decided to go with roughly the same API - see below for code examples for both).

Taking requests as examples there are both declared in blink, the rendering engine and not v8 again because they aren't JS:

- fetch (https://source.chromium.org/chromium/chromium/src/+/main:thi...)

- XMLHttpRequest (https://source.chromium.org/chromium/chromium/src/+/main:thi...)

For the fun of looking even more at some code of reputable projects: for setTimeout / setInterval, I would guess they are declared here in blink: https://source.chromium.org/chromium/chromium/src/+/main:thi...

And maybe here for Node.js: https://github.com/nodejs/node/blob/8a41d9b636be86350cd32847...

To note that "filesystem" API also exist in web world: https://fs.spec.whatwg.org

Again, this API is completely different than in Node.JS

I have the same back-button issues on both Firefox and Chrome (on linux if it matters) when going to this website. Multiple pages in history are e.g. just black screens.

By what I understood of your reply, everything is a measure and I fail to see how something cannot be measured. Or perhaps I wasn't clear in what I meant initially?

In which case you have already measured it, even if not very precisely.

If you're doing a CLI tool for example and it responds soon enough for it to be a bother, you won't want to measure a sub-part of its logic. You may be blindly "measuring" the time the whole command took with your eyes and thoughts, but you're not measuring in any way the time taken by the corresponding logic in the whole thing.

This too cannot be determined without measuring how often it happens.

If the CLI tool logic sub-part is in a specific combination of flags and conditions that you for now didn't see a use case for or even sometimes possibility yet, you may also not measure it, without needing to have to "measure how often it happens". For example you may want to skip some optimizations in what you think will be rarely encountered error handling code, even if you actually never measured it. Even if it does happen more often than you thought, low performance may still be acceptable in some unexpected code (e.g. after a typo in a CLI tool flags).

It may be that the entire performance including the logic is satisfactory.

Or it may be that the conditions to reach that logic are too rare to make the time to measure and optimize worthwhile.

In any case, I understand it as: if you're not bothered about measuring the performance of something, it may be that you don't need to optimize it.

Small nitpick about the website: I'm one of those people that randomly select chunks of text as I'm reading it. It seems that your website make the selection background and text the same color (#fff in the CSS) making it unreadable when doing that.

Therefore I must here control my weird urge to select text, which may be good in the end, but I don't think that's what you intended!

Service workers are like adding extra threads when running JS in your browser. People use them in client-side web app code to get around the single-threadedmess of JavaScript. [...]

Aren't you just describing workers in general here (without the "service" part)?

To me "Service Workers" is a worker purposed especially for proxyfying requests made by the client, on the client, and act upon it (example: by returning a version cached by the js). The main use-case I've seen is implementing an offline mode.

When you just want to unlock multi-threading capabilities in JavaScript, you just rely on "WebWorkers" another worker mechanism without the proxy part, I've never seen those referred as "Service Workers".

With that written, I don't get what Service Workers have to do being on the server-side though :/

sometimes it will accept all [...] cookie categories

That's a shame, I like the idea of explicitly indicating that I don't want anything more than what's necessary (or at least not indicating that I don't care about them).

From my experience in France at least, nobody relies on SMS anymore and less and less people on regular calls, it all goes through Whatsapp.

Even I am guilty of that for both SMS and calls, having a single featureful app with contacts ordered by the most recent discussions descending (as in my country SMS is largely replaced by Whatsapp) leads to less friction than having to scroll through my actual phone's contact.

I agree with the most part of what you wrote and I don't want to turn this even more into an unconstructive flame war than it already is. I just wanted to reply on the following point:

I knew HN had a bunch of conservative and libertarian tech bros but…holy shit. This whole thread is unhinged.

Many people on that thread seem to not be american so thinking of them through a US political lens may not be pertinent - the politically-loaded, US-centric, source of the change may also be the source of the frustration with it in the first place (see the bottom of this reply).

Just on this point, I consider myself left-leaning (and from what I can see, US democrats would mostly be at the center - and Biden center-right - of the political spectrum in my country), yet I share the point of view of the other commenters regarding the "master" change and the ways it is pushed.

In what universe is master/slave not racist

For the "master" part at least, I would say most people do not link it to slavery because most people are not from an english-speaking country.

For me, when I read master I may just think about master recordings. That does not mean that it may or may not have a racism-linked origin (I have no idea about that) but understand that many people around the world don't do the connection. Then, as it is mostly US people that push for other to change that name vehemently, this make many people think that those are americans that want to push their current political ideology down someone else's throat (which has a completely different cultural and political background) and may elicit a strong response.

I get you, but it's both a TypeScript and JavaScript feature, and more importantly TypeScript is including it in its next official release whereas it is still not part of ECMAScript (though close, at stage 3).

So speaking specifically of a new TypeScript feature is justified here.

I interpreted this comment as more of a jab at how inefficient are outlook and teams themselves as applications.

I don't know if it's the right interpretation to have, but I kind of agreed with it, considering huge issues I had with teams (curiously some of them are only there for linux users, weird when considering the fact that I only use teams' web page) - not saying I could do better though!

Just to give my experience, I actually didn't know what that acronym meant. I tried googling it but "ESL speaker" only gave results about loudspeakers and just "ESL" was mostly about some German Company.

I even thought it had to do with sign language at first but didn't get the meaning of the sentence in that case!

---

A little off-topic but that makes me think of another HN thread some months ago talking about acronyms like "SRE" or "SWE" (and some others I since forgot), that many HNers assumed to be understood by everyone. Many non-american/english developers actually never encountered those (including I, I've been software engineer since at least 8 years and never saw those terms beside HN, like I would think most in my country) and it led to the same kind of incomprehension.

Ha! I tell myself exactly the same thing, I even registered to Mt Gox (which I think - my memory is not to clear - included sending some identification papers) to finally just chickening out when it was time to put my money by instead asking my non-tech family what I should do - which of course was not to put money in that weird thing.

Now, I half have a large regret and half tell myself that I would have lost it all anyway.

I guess it doesn't work for example when words contain dashe(s) or apostrophe(s) which might exist (for a single indivisible word) in some languages.

The answer to the concern of potential health issue of cannabis legalization is almost always "what about [this other bad product with some common effects], should we forbid it too?"

This argument always sounds like a fallacy to me, as we're talking about legalizing something that was previously not, not the other way around.

I get that the argument might be seen as relativizing by providing examples of legal substances everybody agree today should be legal, but the way this answer (and others) is always presented sounds to me excessively aggressive and non-productive. If you want to make a point, please make it, don't just stop at this absurd proposition.

---

Some people (I'm not even included in that group as I don't really care about this issue) seem very concerned about the global health implications of cannabis legalization.

Instead of aggressively diminishing this opinion with whataboutisms, legalizing proponents motivated enough to answer to this person should IMO better take into consideration (and respect) this opinion.

One of the program is: https://www.svtplay.se/video/34674843/den-stora-algvandringe...

It depends heavily on the website we're talking about but there's generally a lot going on when streaming video on the web.

Usually what happens at the core is that JavaScript will download video, audio and subtitles progressively through small chunks of data called "segments" and push them to JS-exposed buffers called 'SourceBuffer'. Deciding which chunk to download, downloading them and pushing them already require a lot of JavaScript (for example, you need to decide which video and audio quality to download through adaptive algorithms, which tend to be quite complex, moreover there's also a lot of media events that needs reaction to, like when seeking, rebuffering, changing track etc.). You also have a lot of JavaScript there to limit risks of playback stalling and if you have DRMs, a lot of JavaScript there to be able to recuperate the right decryption keys (an operation you generally wish to finish as soon as possible as it is often the last step before playback).

On some websites, you might want to play with as low latency as possible between the broadcaster and the user. In those cases, you might want to optimize your JS code, have very small checking intervals, and you might again prefer to run as much code as possible in a worker to avoid rebuffering due to the risk of the main thread being too occupied doing other things to push media segments.

Even on non-low-latency contents, some websites which already have a lot of JavaScript running beside video playback such as at least Facebook and YouTube pushed browsers for quite some time now to be able to use the main JavaScript media streaming APIs in a worker (https://github.com/w3c/media-source/issues/175), e.g. in another thread.

You could also have complex contents (lot of audio and subtitles languages, many audio and video qualities, multiple decryption keys, long duration etc.) that may lead to big performance and memory issue when parsing them on the JS-side. Those contents are usually described through a file named "manifest" or "playlist" which in this case can take a lot of resources to process (the document can be up to a huge 15MB XML where I work), often leading either the linked JavaScript to run in a worker or to use webassembly (a solution we chosed). Even more if you consider live contents, where this document might have to be regularly refreshed.

You might also want to apply some processing on the media played, for example transmuxing mpeg-ts segments to MP4 ones so they can be played by more browsers. Those are very frequent operations that can be performance-sensitive and are also often performed in another thread.

Again it very much depends on the website and I mainly know the use cases I personally encountered. Generally, adaptive media player are very complex JavaScript beasts.

Also performance issues and poor memory management from the browser-side can lead to a lot of issues. A recurring issue at my work is bad performance leading through side-effect to a very poor quality being played (due to the high overhead in loading segments, pushing them to the buffer etc.).

All these would suffer without a powerful and featureful JS engine like we generally have today on most browsers.

just watching videos [...] (where the JavaScript takes a back seat)

If you're talking about media websites like YouTube, Netflix, Amazon Prime Video, Twitch and so on or even just videos on sites like Facebook, video streaming actually needs a lot of JavaScript behind the hood. Some of it even being already performance-sensitive today.

Same here on Arch with Firefox (perhaps due to the fact that I'm using a Wayland compositor?). It was quite surprising!