throwitaway1123

> I really loved PHP, but now with go+templ (https://templ.guide) I personally don't have a use-case for PHP anymore, but that doesn't mean it's irrelevant for the world.

This is the first time I've heard of Templ. It looks cool and it was really easy to set up. Apparently there are IDE extensions to enable syntax highlighting and HTML auto-completion, but is there a way to type check the templates? One of the things I love about JSX as a templating language is that errors in your markup get reported as type errors [1]. If I write `<a herf="/foo">` instead of `<a href="/foo">` and run `tsc --noEmit --watch`, TypeScript will complain until I fix the issue. You can even extend the types to support your own HTML custom elements. JSX is a first class citizen in TS (and by extension any editor or IDE with support for TS).

[1] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...

Are you thinking of stagit maybe? Which (as the name suggests) is a static git frontend: https://github.com/oxalorg/stagit

One addendum I would add to the section on node:cluster is that Deno hasn't actually implemented the cluster module yet (it's just a stub), so using it with Deno is pure overhead [1]. Also, there's ongoing work to add node:cluster to Bun [2].

[1] https://docs.deno.com/runtime/manual/node/compatibility/

[2] https://github.com/oven-sh/bun/pull/11492

React has always had the ability to do SSR without Next. You can call renderToString on the server to generate html strings, and then hydrateRoot on the client to pick up where the server left off.

If you like JSX as a templating language and you want to generate simple html strings then just use vhtml with TypeScript [1][2]. You have to import the h function from vhtml in your tsx files, and then update your tsconfig file so that TypeScript knows what to transform the JSX into:

  "jsx": "react",
  "jsxFactory": "h",
  "jsxFragmentFactory": "null",

If you want something a little more powerful then hono/jsx is a decent choice [3].

[1] https://github.com/developit/vhtml

[2] https://github.com/developit/vhtml/issues/31

[3] https://hono.dev/docs/guides/jsx

> Ah yeah dataviews, but you still need to convert from json to those and that takes about as much overhead

You don't necessarily need to have an intermediate JSON representation. Many of the built in APIs in Node and browsers return array buffers natively. For example:

  const buffer = await fetch('foo.wav').then(res => res.arrayBuffer())
  new Worker('worker.js').postMessage(buffer, [buffer])

This completely transfers the buffer to the worker thread, after which it is detached (unusable from the sending side) [1][2].

[1] https://developer.mozilla.org/en-US/docs/Web/API/Worker/post...

[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

> JS can share data between threads, but must convert it all to string

To be more precise, you can send data to web workers and worker threads by copying via the structured clone algorithm (unlike JSON this supports almost all data types), and you can also move certain transferable objects between threads which is a zero-copy (and therefore much faster) operation.

Unfortunately, many users will gather from this experience the following sentiment: "if I want to access the latest cutting edge betas, then I should be using something other than Firefox". The net result of this is less browser diversity.

Node supports URL imports via the --experimental-network-imports command line option. There's also a built in test runner now.

It's been a really eventful month for Node. First they added node:sqlite in v22.5.0, and now TypeScript support is landing. I love the direction Node is heading in.

I actually like having a variety of status codes to represent different scenarios. When I'm debugging a request at a glance my mental heuristic is "200-299 means success, 300-399 means redirection, 400-499 means client error, 500-599 means server error".

Not sure what you mean about JS fetch calls. The status code doesn't determine wether or not the catch block executes. The only thing it does affect is the value of the response.ok boolean (which is true if the status code is less than 300). There are a few cases where fetch will throw an exception, but status codes aren't among them: https://developer.mozilla.org/en-US/docs/Web/API/Window/fetc...

Yeah upgrading a legacy codebase that uses callbacks is not fun, but if the callback functions follow the Node error first value second convention, then it's a little bit easier because you can just use `util.promisify` to convert them to promises in Node. There's also the new Promise.withResolvers method which helps a bit too [1].

[1] https://github.com/tc39/proposal-promise-with-resolvers

This is a really interesting point. You almost never hear async function coloring being conceptualized as a feature rather than a hindrance. Async function coloring is kind of analogous to the borrow checker in Rust. It makes you think about concurrency the same way that the borrow checker makes you think about memory ownership and lifetimes.

The HTMLRewriter API is pleasant to work with. Bun has implemented it in addition to Cloudflare Workers. I would love for WinterCG to work on standardizing this API across JS runtimes so that I don't have to interact with lol-html across a WASM boundary in Node and Deno.

It also had an IR blaster that let you control your television without worrying about misplacing a remote.

> Consider the recent npm supply chain attack a few weeks ago

What supply chain attack are you referring to?

One of my favorite aspects of the early web was the focus on customization. Your Myspace page was literally 'your space' and you were free to customize it with CSS as you pleased. There's a whole generation of developers and designers that started this way. You still see remnants of this philosophy in the contemporary web (e.g. moderators on Reddit can customize their subreddits), but that philosophy is nowhere near as ubiquitous as it was in the Geocities era.

Browsers are very lenient when it comes to HTML parsing. In fact, one of the reasons why HTML sanitization libraries like DOMPurify are so complex is because browsers will tolerate all sorts of twisted broken markup.

> The whole point of using a video app is to communicate things you can't communicate as quickly without video.

The 'whole point' of a visual medium is not just to communicate ideas more quickly. Having eyeballs does not merely grant me a speed boost, it allows me to experience things that are simply ineffable otherwise. People didn't Zoom/Facetime their family members during the pandemic just because it was more efficient than texting them.

> And again, this is about messages simply being undeliverable without the native app. If the web app takes an extra 5 seconds to join the meeting

You're misusing the word undeliverable. Undeliverable means 'can not be delivered', not 'delivered 5 seconds later'.

> Zoom has the money, they don't need to cheap out and do the browser app

They're already doing the browser app. I'm saying they should do it well.

> Their docs specify that there are minimum system requirements for doing 50 rather than 25. This is an efficiency problem at the end of the day - the browser app is less efficient and can't handle as much info at a time with the same hardware.

You originally claimed that there was a hard limit to the number of simultaneous video streams that the browser version could handle, and that this was the difference between sending a message and not sending a message, and now you're walking that point back and saying that the browser version can't do it with the same hardware. So you're tacitly admitting that you were originally presenting a false dichotomy.

> being inefficient can cause security problems

There are multiple confirmed security flaws in the desktop Zoom apps (which you claim are more efficient), and your conclusion is "inefficient = insecure"? If anything, the opposite appears to be true according to your own claims.

> I'd actually wager there's a ceiling to how efficient you can make a browser app, and you can make the native app at least as secure as the browser app

Zoom themselves wagered $200,000, and the result was a critical RCE vulnerability in their desktop clients, and nothing in the browser version. But keep postulating with hypotheticals and ignore objective reality.

> if each case loses 5 minutes of time due to using the browser app [...] because efficient communication is a matter of life and death

First of all you've been throwing around this '5 minute' figure throughout this discussion, but there's simply nothing to substantiate it. Your entire argument hinges on this flimsy point derived from anecdotal evidence. I've never spent 5 minutes trying to set up Zoom in the browser. I predicted several days ago that this discussion would degenerate into anecdote trading, and here we are.

Second of all, if I were dealing with a serious court case then one of my primary concerns would be maintaining confidentiality. You completely ignored the entire point of my court example which was to illustrate the fact that security has serious implications, and you can't simply wave them off by saying "I wouldn't transmit personal information via Zoom". You're trying as hard as you can to avoid the most important aspect of using Zoom in court: security. Instead you wrote a thinkpiece about Zoom hypothetically taking 5 minutes to load. Imagine being a witness in a high profile case, on the brink of going into the witness protection program, with your literal life on the line, only to find out that your private information was leaked because someone didn't like the UX of the Zoom web app. And you have the gall to claim that bad UX is a matter of life and death. Are you being serious here?

You yourself said "I wouldn't transmit my bank account number and routing number or similarly sensitive information over Zoom", and yet you want the Zoom desktop app to be used in courts? That makes absolutely zero sense. Do you not believe courts deal with sensitive information?

> There have been RCE vulnerabilities in browsers too.

We're not comparing the security of web browsers as a whole to the security of the Zoom desktop client, we're comparing the security of the Zoom web app to the security of the Zoom desktop app. Can you find a single example of an exploit that allowed a hacker to execute arbitrary code on a user's computer after visiting zoom.com (even one that was eventually fixed)?

And also, almost all computer users are running web browsers (they come preinstalled on most consumer operating systems). So by downloading Zoom you're adding an additional threat vector on top of whatever threat your favorite browser already represents.

> The example you gave was one where Zoom was proactively publicizing their own work to recruit researchers to find vulnerabilities so they could be fixed before they caused actual issues - and Zoom fixed the issue, you're using Zoom's good behavior in security testing their app against them.

Every reputable organization has a bug bounty program (including browser vendors). You don't get a participation trophy for having a bug bounty program. You're missing the entire point which is that Zoom offered $200,000 to security researchers to find a vulnerability in their products and both of their desktop clients produced critical vulnerabilities yet the browser version did not. Which I would infer means that the browser version is more secure. Once again, do you have any examples of Zoom exploits in the browser?

Zoom can't keep producing vulnerabilities and getting a pass because they eventually fix them. This exploit's existence was publicized before Zoom fixed it. What if it was sold on the dark web and exploited in the interim?

> No it's not, I wouldn't transmit my bank account number and routing number or similarly sensitive information over Zoom.

People are absolutely transmitting critical information via Zoom. Courts literally use Zoom to remotely administer proceedings. I've heard of companies that ask employees to hold up sensitive documents in front of the camera to verify their identity. Hiding your head in the sand and saying "just don't send sensitive info via Zoom" is disingenuous at best. And even if you did buy in to the "just don't send sensitive data bro" argument it doesn't matter because an RCE exploit could potentially expose information that you never transmitted via Zoom that just happens to be sitting on your filesystem.

> The choice is in fact between sending data and not sending data. I've given you one example (the limited number of simultaneous streams) where you're opting not to send data.

The overwhelming majority of your examples have been cases where you've begrudgingly admitted that there's a way to accomplish your goal in the browser, albeit less efficiently. You started this conversation by admitting that you can share your screen in the browser, but doing so via the desktop app saved you a few minutes. I haven't found any published documentation from Zoom in regards to the streaming limit and I'm not willing to call up 49 other people to test this for an HN debate, but like I said, the vast majority of users can fulfill their needs in the browser. The average Zoom user is not hosting digital raves. I couldn't even imagine wanting to have 50 videos playing on my screen vying for attention. And again, there's no technical reason for why you couldn't implement 50 streaming videos in the browser. Maybe Zoom should spend that $200,000 improving their browser product.

> You're at risk of a data breach the moment you connect your computer to the Internet [...] If you have zero tolerance for a data breach you should delete the data so no one including you may access it.

To reason by analogy, this is like me suggesting you wear a seatbelt while driving a car and you responding by saying: "well you're at risk the moment you step outside of your house, so if you really have no tolerance for injury you should simply not leave the house". You're saying instead of opening Zoom in the browser I should delete all personal data from my computer, and for what end? I'm doing this so that I can attend virtual dance parties efficiently? I don't understand how any rational cost benefit analysis could yield such a conclusion.

> "would I prefer to open myself up to attack, or would I prefer not to deliver this message at all?"

This is absolutely a false dichotomy. The choice isn't between sending data and not sending data, the choice is between sending data in the browser vs sending the same data within a desktop application.

> You need to do a complete threat model and explain how Zoom contributes to that risk,

The Zoom desktop clients have had RCE vulnerabilities where hackers were able to remotely execute arbitrary code on victims computers with zero user input required from the victims (they demonstrated this by remotely opening the calculator app). It's very obvious how Zoom contributes to that risk. "A zero-day vulnerability in Zoom which can be used to launch remote code execution (RCE) attacks has been disclosed by researchers. The researchers from Computest demonstrated a three-bug attack chain that caused an RCE on a target machine, and all without any form of user interaction [...] an animation of the attack in action demonstrates how an attacker was able to open the calculator program of a machine running Zoom following its exploit. As noted by Malwarebytes, the attack works on both Windows and Mac versions of Zoom [...] The browser version of the videoconferencing software is not impacted." [1]

> Practically speaking I have conversations in public places all the time and I don't stress about the possibility that someone might be recording me with a parabolic microphone.

Do you yell out your bank account number and routing number in public because you think the user experience of finding a private place to talk is too burdensome? Because that's metaphorically what you're arguing for.

[1] https://it.slashdot.org/story/21/04/09/209227/critical-zoom-...

We might simply have different value systems because I could never justify putting myself at risk of a data breach in order to badly simulate the experience of attending an actual social event and dancing with other human beings. That feels very dystopian to me.

We're getting really deep into the intricacies of Zoom and Google Meet here, and I feel like we're losing the larger plot. If you have a battle station set up for Zoom parties with multiple monitors with 50 simultaneous dancers that you need to keep an eye on, and you don't mind the security risks, then maybe you represent a specific edge case, but I think the vast majority of software users have different requirements that web browsers satisfy handily.

I don't want to take any credit away from Fabrice Bellard and his work on QuickJS. All of the serverless QuickJS derivatives like Shopify's Javy and AWS's LLRT owe a debt of gratitude to Bellard. They're all very thin wrappers over QuickJS (which is by design obviously in order to reduce cold start times). Use whichever verb you prefer in place of 'created'.

I've used Zoom professionally in the browser literally within the past week, and it ran smoothly. We can trade anecdotes here, but it won't be very productive.

What I can tell you is that I felt at ease using Zoom in the browser knowing that I wasn't opening my computer up to a remote code execution vulnerability. Your UX concerns are a bit nebulous, but I'd be willing to bet that the risk assessment departments at most organizations could quantify the cost of a hacker gaining access to one of their employee's computers. I also used Zoom during the pandemic but I wasn't doing a ton of screen sharing (I was more interested in seeing my friends and family members faces rather than their screens).

Yup, AWS actually created a JS runtime called LLRT (Low Latency Runtime) based on QuickJS exactly for this purpose (reducing Lambda function cold start time). The Syntax podcast just released an episode with one of the developers behind LLRT.

> Of course PWAs aren't popular on platforms that deliberately go out of their way

You've got your signals crossed. That was another commenter who wrote that statement [1].

> Strange how we went from "The web is absolutely more than good enough for the vast majority of apps" to "majority of mobile gaming apps."

We didn't go from one thing to another. I addressed a subset of the app market: gaming apps. Just like your Slack example addressed a subset of the app market: chat apps.

> I mean, almost every single web "app" out there suffers from this. The DOM isn't built for highly dynamic interactive applications. It's a system to deliver static text and images.

This is not a technical argument, it's a philosophical one. The council of browser elders never convened to proclaim that web browsers are only meant to deliver "static text and images", that's just your philosophical viewpoint. In fact, Apple is currently pushing WebXR to support the new Vision Pro, so apparently they didn't get the memo about "static text and images" [2].

> Now you're pretending I said something I didn't.

You said that the web is not performant enough. CPU speed is a pretty big component of performance.

> I mean, Slack's app needs up to 20% of CPU even on an M* Mac (last I tried it was M1 Max IIRC) to render a few animated emojis.

Slack's desktop app or Slack's web app? If you're talking about the Electron app, well then yeah bundling Chrome is never going to win efficiency awards, but now you're pretending I said something that I didn't. I'm not defending Electron apps. Everytime I discuss the web on HN someone does a bait and switch and starts talking about Electron. Don't conflate Electron with the World Wide Web.

If we're talking about chat apps, then I've watched high definition streams on Kick, Twitch, and YouTube where the chat is streaming in over Websockets faster than I can read it. The human brain at that point becomes the actual performance bottleneck. But tell me more about how the web can only handle a few lines of text (by commenting on a website).

[1] https://news.ycombinator.com/item?id=40891602

[2] https://webkit.org/blog/15443/news-from-wwdc24-webkit-in-saf...

Plugins like Flash, Silverlight, and NPAPI were common at the time, but anything running in a web browser is still a web application. It feels like you're making a distinction without a difference [1]. Either way, the web can performantly do what Quake Live did back then without plugins today, and it can certainly handle the Flappy Bird and Angry Birds style apps that people are playing on mobile devices today. Just take a look at some of the Unity WebGL and threejs demos.

[1] https://en.wikipedia.org/wiki/Distinction_without_a_differen...

After some of the CVEs linked to the Zoom desktop clients I wouldn't touch them with a ten foot pole [1][2], but I don't want to move the goalposts since we're talking about performance here. It's hard to tell whether or not the disparity is due to a Screen Capture API performance issue, or just bad engineering from the front end team at Google Meet, or even just bad UI design. Hiding features behind buttons and menus will always add a noticeable delay to an action, but that's just bad UI design, not a technical problem.

> but also display, audio input/output, even global keyboard shortcut handling.

I personally have never had a display or audio hiccup that I could attribute to a browser limitation. I don't even own a device with a display powerful enough to max out Youtube.com's 8K video resolution limit. I'm not sure why you've had issues with keyboard shortcuts. Keyboard events are well established and widely supported [3].

[1] https://news.ycombinator.com/item?id=20387298

[2] https://hn.algolia.com/?q=zoom+vulnerability

[3] https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...

> Just because you played Quake doesn't mean the web is good for "vast majority of apps"

It means that at least 15 years ago it was more than powerful enough for all of the 2D Candy Crush style games which make up the overwhelming majority of mobile gaming apps.

> The web can barely display simple text and images without jank because that is inherent limitation of the DOM that you cannot escape

I've seen you repeat this phrase over and over again like a mantra on HN, but without examples I can't really gauge the performance problems you've run in to. The overwhelming majority of jank on the web that I've experienced is due to advertising bloatware (an adblocker is indispensable), and occasionally bad engineering (e.g. someone forgot to make an event listener passive, or isn't debouncing an event) not some inherent limitation of the platform. What are some examples of popular apps that you think require the full brunt of a modern chip? Every M3 iPad review I've watched ends up saying essentially the same thing: "this chip is powerful, but besides Geekbench benchmarks we have nothing to use it for".

The web is absolutely more than good enough for the vast majority of apps. I was playing Quake Live in the browser on a thermally throttled dual core laptop 15 years ago, but the hive mind here at HN will have you believe that the generic social media apps that dominate the charts all need to be "close to the metal": https://apps.apple.com/us/charts/iphone/top-free-apps/36