The book Software Engineering at Google makes a distinction between software engineering and programming. The main difference is that software engineering occurs over a longer time span than programming. In this sense, AI tools can make programming faster, but not necessarily software engineering.

So they can potentially work offline and deliver push notifications.

Very few applications actually need push notifications, a large majority is only annoying users with upselling, or user engagement.

For Apple, sure. But Google has been leading efforts to make the PWA experience good. In origin trial right now is the ability for websites to install PWAs: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/....

This would make it much easier to find and install web apps than the current method.

How is it overly verbose?

I find it very intuitive, with the exception of useEffect.

React's hello world:

```js

<div id="root"></div>

<script>

import React from 'https://esm.sh/react@19';

import ReactDOM from 'https://esm.sh/react-dom@19/client';

const root = ReactDOM.createRoot(document.getElementById('root'));

root.render(<h1>Hello, world!</h1>); </script>

```

---

HTML's hello world:

```html

<h1>Hello, world!</h1>

```

---

JS's hello world:

Nothing, it was already done in HTML

React:

import { useState } from "react";

function Counter() { const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );

}

---------- Svelte:

<script> let count = 0; </script>

<button on:click={() => count += 1}> Count: {count} </button> --------------- React: function Editor({ initialText }) { const [text, setText] = useState(initialText);

  useEffect(() => {
    setText(initialText);
  }, [initialText]);

  return (
    <textarea
      value={text}
      onChange={e => setText(e.target.value)}
    />
  );

} --------------------- Svelte:

<script> export let initialText; let text = initialText;

  $: text = initialText;

</script>

<textarea bind:value={text} />

No one's going to mention VueJS?

I enjoy being a Vue main in these discussions, mostly because everyone leaves us alone lol

I really enjoy the syntax of Vue over React, and if it’s an application that’s complex enough to warrant something like React I’ll almost always reach for Vue so long as it also meets the requirements.

Seeing Svelte 3/4 code always warms my heart. The ergonomics of `$:` are amazing.

The way I approach these situations is by reminding myself that the speaker is implicitly making a request - a request for empathy or understanding. While it's tempting to try to solve their problems, what they really want is for their feelings to be heard.

"Oh, that must have been frustrating."

THIS! And realizing this is a major step forward for many men in learning to better communicate with women (a stereotype, sure, but one that has many true instances IME).

If a tool makes it easy to shoot yourself in the foot, then it's not a good tool. See C++.

I'm no apologist but this statement doesn't ring for me. It's easy to shock yourself with electricity, is it a bad tool?

Electricity isn't a tool, it's nature. An unenclosed electrical plug which you had to be really careful when handling would be a bad tool, yes.

A tool is something designed by humans. We don't get to design electricity, but we do get to design the systems we put in place around it.

Gravity isn't a tool, but stairs are, and there are good and bad stairs.

Appreciate the perspective.

Of course it's bad. It's new. But it won't always be either of those things. I think "bad" is relative assessment and based on a build-up of knowledge, often over decades.

Electrical plugs and stairs are "good" only because that knowledge has been discovered and has been regulated. Expecting a tool to be literally and metaphorically fool-proof immediately upon discovery strikes me as pretty disingenuous.

In the case of AI, the most anti-AI crowd are often vehement with their fingers in their ears saying "it's not good and never will be, and shouldn't exist." To be fair, the pro-AI crowd are often raving as if all the kinks had already been worked out.

A knife then.

Most tools are dangerous in the hands of the inept or the careless. Don’t run with scissors.

A gun is a good tool easy to shoot yourself in the foot with

We tested this against WebRTC data channels (which also uses UDP) and found that the congestion control algorithm used for WebTransport limits its use for videoconferencing. We'll probably look into it again if browsers start allowing this to be configured.

SCTP and by extension, WebRTC data channels, are supposed to use the same congestion control algorithms as TCP/QUIC. But I don't know which CC libsctp does these days.

WebTransport in Chrome currently uses CUBIC but the Google folks want to turn on BBR everywhere. It uses the same QUIC implementation as HTTP/3 so it's going to be more battle hardened.

SCTP: The FORWARD-TSN chunk was introduced to support selective unreliability: it allows the sender to tell the receiver that it will not retransmit some number of chunks, and requests that the receiver consider all these chunks as received.

QUIC has a much better alternative to FORWARD-TSN, either via RESET_STREAM or QUIC datagrams.

I've implemented SCTP before to hack in "datagram" support by spamming FORWARD-TSN. Fun fact: you can't use FORWARD-TSN if there's still reliable data outstanding. TSN is sequential after all, you have to drop all or nothing.

QUIC as a protocol is significantly better than SCTP. I really recommend the RFC

Wow thanks for the tip

I haven't used WebTransport myself, how much can you control? I wonder how often libwebrtc does stuff that wouldn't be allowed in Javascript. Things like probing and overshooting the window?

Since libwebrtc is all in C++ and 'trusted' it can do stuff like faststart or have error correction/bandwidth estimation that is codec aware.

There's no probing in any QUIC implementation but it's possible. There's a QUIC extension in the IETF similar to transport-wide-cc but it would still be up to the browser to use it for any upload CC.

Did you try using the unreliable datagram extension?

For Zoom Team Chat you can set up notifications to only notify for replies to your messages, direct messages, and explicit mentions. I agree that it would be useful to additionally batch notifications for specific channels though.

We're using conventional commits on my team, and it's extremely annoying. I've never had a reason to go deeper into the history of a repo outside of the PR merge commit history. I think it makes more sense to have conventions on PR descriptions.

This article explicitly mentions your first point.