vinnymac

This isn’t a complete answer, but my short list for moving the tech many steps forward would be:

* replying with “I don’t know” a lot more often

* consistent responses based on the accessible corpus

* far fewer errors (hallucinations)

* being able to beat Pokémon reliably and in a decent time frame without any assistance or prior knowledge about the game or gaming in general (Gemini 2.5 Pro had too much help)

I already use streaming partial json responses (progressive json) with AI tool calls in production.

It’s become a thing, even beyond RSCs, and has many practical uses if you stare at the client and server long enough.

It would require a blog post for me to answer this in detail, but overall it’s due to the fact that monorepos trend toward specific stacks and runtimes. They aren’t often as flexible as they’d have you believe, so you might find a low level programmer isn’t able to operate as efficiently when operating in a primarily NodeJS-based Monorepo. Plus it makes it easier to separate parts of your business that are distinct, simplifying the complexity of security, maintenance, and compliance.

I don’t think one should have 100s of them, practically speaking less than 5 should be enough to model any business today. It can be freeing though, and allows developers to take advantage of the tools that best fit there needs so they can go back to getting shit done.

Small piece of advice you should be debouncing your primary input at the very least, especially because you insert an entry into the browser history for every character typed (consider only doing that on submit). Plus if any calls are made to the network in response to a key press you’d add unnecessary pressure.

Presently trying to navigate back to the comments from your site after typing out a domain required far more effort than navigating backward a couple times.

I established monorepos for the last two large projects I operated. I’ve never heard such nice compliments from contributors in my whole career. It seems not only can it be a productivity booster but people genuinely love when things are easy to grok and painless.

Multiple large monorepos in an organization are highly valuable imo, and should become more of a thing over time.

I used to use PT for years. Nowadays I use Linear instead for project management and love it.

In true pivotal tracker spirit their mobile apps are terrible, but perhaps that’s for the best.

Oof that semicolon comment really took me straight back to high school.

I think writing code on paper is actually a very good exercise, but professors who get upset over missing semicolons can go to hell.

What’s cool is that with html includes (import specification) we could have supported this without any JS.

https://www.w3.org/TR/html-imports/

“Worse” here is relative to how we have designed sites such as Google maps today. The current web would fundamentally break if we stopped supporting scripts after page load, so moving would be painful. However, we build these lazy and bloated monolith SPAs and Electron apps because we can, not because we have to. Other more efficient and lightweight patterns exist, some of us even use them today.

If you can exchange static content, you need very little scripting to be able to pull down new interactive pieces of functionality onto a page. Especially given that HTML and CSS are capable of so much more today. You see a lot of frameworks moving in this direction, such as RSCs, where we now transmit components in a serializable format.

Trade offs would have to be made during development, and with a complex enough application, there would be moments where it may be tough to support everything on a single page. However. I don’t think supporting single page is necessarily the goal or even the spirit of the web. HTML imports would have avoided a lot of unnecessary compilers, build tools, and runtime JS from being created for example.

https://www.w3.org/TR/html-imports/

I am thinking about a different time, when JS did less, and these decisions were being made.

Today, what you are saying is definitely a concern, but all APIs are abused beyond their intended uses. That isn’t to say we shouldn’t continue to design good ones that lead users in the intended direction.

I don’t disagree at all mind you. I’ve been developing websites for 25 years or so now. I just think we could have done better with the standard.

If you’re asking if it would incentivize us to be more careful when introducing additional interactive functionality on a page, and how that functionality impacted performance and page speed, I expect it would.

Thinking about how the web was designed today, isn’t necessarily good when considering how it could work best tomorrow.

You misunderstand me, I’m not proposing we get rid of JavaScript.

I am saying that allowing for JavaScript to be dynamically downloaded and executed after the page is ready was a mistake.

You can build your Google docs, your maps, and figmas. You don’t need JS to be sent after the page is ready to do so.

I believe allowing the dynamic loading of scripts was a mistake, and we should undo support for it. So were iframes.

Everything after ready should have been static content.

I can't speak for the desktop experience lately, but just last weekend I opened the YouTube app on iOS to this peak user experience:

https://files.catbox.moe/vzo65c.JPG

I have had a similar experience. After using Kagi, I don't really get why someone would pay for what they are offering today.

19/20 the neon blue one really messed with my head and kind of hurt to look at for some reason, so I am not surprised I got it wrong.

This is especially true for script kiddies, which is why I am so thankful for https://e18e.dev/

AI is making this worse than ever though, I am constantly having to tell devs that their work is failing to meet requirements, because AI is just as bad as a junior dev when it comes to reaching for a dependency. It’s like we need training wheels for the prompts juniors are allowed to write.

Same I’ve been writing React for 11 years now.

Before that I used Backbone on top of jQuery.

Before that I used jQuery.

Before that I used the document, but I still use the document.

I have barely had to learn anything each decade.

I expect most people are going to open the door right in front of them, rather than walk the long way to gain entry, even if they are aware the door is monitored by a security camera.

You might be interested in e18e if you would like to see that change: https://e18e.dev/

They’ve done a lot of great work already.

Depends on the ticket.

If it's "Get us to the moon", it's gonna take me years to write that ticket.

If it was "Make the CTA on the homepage red", it is up for debate whether I needed a ticket at all.

I think as a guide for buying honey his advice is valuable, although a bit dramatic, and it won’t apply to every country or region.

As someone who is a beekeeper and owns a farm, you can be much more certain what you’re getting is honey where I am from when it’s being purchased from the back of a van from some random person with some glass jars, than you can at any supermarket. Hi it’s me I am the random person with the glass jars :)

Your effort to make these posts consumable by the masses doesn’t go unnoticed. It’s clear you put a great deal of work into them, and the quality you achieve raises the bar in many ways for what to expect when learning about the web. If only all educational materials on MDN could reach these heights.

Offline evaluators such as laminar and (evalite wip) stay out of the way fortunately. Evals can be very useful when they do.

The README lists all the ports here: https://github.com/matomo-org/device-detector?tab=readme-ov-...

Code is a liability. Not writing code is one of the best things a developer can do on any particular day, aside of course from deleting it ;)

Are there any other desktop environments that support JS?

Not sure if this is the same idea as the one above, but the ones I’ve heard send the nukes up separately, so that the final launch craft is not impacted by the mass of the nukes. Instead as the craft passes by each nuke, they are detonated, and so it accelerates.

They actually mention this as an alternative explanation other than missing fungi and parasites after rereading the article:

> Another possibility is that the queens could have developed an "acquired taste" for pesticides, as researchers put it, due to prior exposure in their environment.