etler

There are many use cases where having a value stream is very useful. I do agree having a separate simpler byte only stream would make sense though. I think the current capabilities of web streams should be kept and an IOStream could be added for optimizing byte streams.

Ideally splitting out the use cases would allow both implementations to be simpler, but that ship has probably sailed.

React is slower than the alternatives, but next.js is really really slow.

I don't like AI writing because it's bad writing. It's convoluted and inefficient and doesn't get to the point. If someone writes something that feels like AI, it doesn't matter if it was or not because it's still bad writing. I'm not talking about having a cliche here and there, but rather when the text is just incredibly inefficient.

If someone uses AI to help them write, and they reviewed it, and it's high quality writing, I don't care how much they wrote by hand. But, if I can tell it was written by AI that's just a proxy for telling that the author did not put time and care into what they were writing.

AI bloats text and every other task it does into convoluted redundant cliches. This is true for text and code. Whether it was written by an AI or not, it's not worth my time. If you wrote it 100% by hand and it still sounds like AI, it's still bad writing and still not worth my time.

It used to be better? I use android daily and was given an iPhone for work, and using it is incredibly painful because of the keyboard. I was wondering how people have been putting up with it for so long. When I've asked other long time iPhone users about it they just nodded along so I though it was a long running issue.

If my devs are writing that much code they're doing something wrong. Lines of code is an anti metric. That used to be commonly accepted knowledge.

Very good questions! I still need to flesh out the patterns. While streams of streams are common in functional programming environments, I simply haven't seen them in class based streaming patterns anywhere so they're things to figure out.

Of course, more streams means more resource utilization, there's not getting around that, but that's the cost of parallelism. The use of `yield*` should keep the overhead to a bare minimum. Since the streams are being left alone and aren't consumed until needed, that should preserve some of the back-pressure behavior, although I do need to look into that more deeply.

How the system handles errors probably doesn't have a single solution that works for all frameworks, so I think it should be up to the specific requirements of each use case, but there's also definitely more work to do to explore the options and the patterns.

These are all things I definitely want to hear ideas for as well!

The next thing I'm exploring is applying these patterns to web rendering which will be a real stress test for how they can be used.

I describe it as a word granularity search engine. Lossy encyclopedia is a great analogy too and fleshes it out.

They cited the demo of a port having performance issues several months before release. That seems like a complete non story to me. It's brand new hardware and nobody has experience porting to or optimizing for its specific specifications yet. Early ports being unstable and requiring optimizations all the way up to or even past the release date is standard at the point in a hardware cycle.

I think there is a need for the AI counseling use case, but it should not be provided by a general purpose AI assistant. It should be designed by professional psychologists and therapists, with greater safeguards like human check-ins to make sure users get the help they need.

The best way to stop this is to make those safeguards stronger and completely shut down the chat to refer users to seek help from a better service. Unfortunately those services don't really exist yet.

There would be false positives and that'll be annoying, but I think it's worth it to deal with some annoyance to ensure that general purpose AI assistants are not used for counseling people in a vulnerable mental state. They are not aligned to do that and they can easily be misaligned.

Apple has vertical integration between their hardware and operating system meaning they have way more control. They can adapt their software to enable them to optimize their hardware in ways competitors can't.

For the Linear example, I would argue that adding too much flexibility would make the tool worse. Rigid workflows are consistent making them more robust and scalable. They work consistently needing less guidance or intervention.

When you find a rigid workflow that is both widely applicable and useful, that's how the most valuable companies are made. Those workflows can scale up with little intervention giving them incredibly high yield.

I think the new challenge is introducing flexibility in a controlled manner so we can minimize the added inconsistency needed to achieve broader goals. That way the workflow can find the right balance between robustness and flexiblity for the task at hand.

The call was being relayed to the pilot by the flight supervisor. While he wasn't "on" the call, I think it's fair to say he was "part" of the call. He's still getting live tech support and trying to trouble shoot the plane while flying it. He had an intermediary but I don't think that totally changes the scenario.

I think there's just some nuance to the scenario. The pilot wasn't directly on the call, but was participating in the call with the flight supervisor relaying the information.

I'd compare it to being in the room with someone on a conference phone call and they're relaying the conversation to you and them both ways. I would still say you were participating in the call even though you weren't directly on the call.

Also, he did initiate the call so "F-35 pilot held" is imprecise, but not totally wrong. Either way, the pilot was in an active tech support session with the plane engineers, making this one of the most intense tech support calls in history.

I use AI 90% for research, learning, and prototyping. It's increased my interest because before, I felt that I didn't have time to do all those things, now I can expand my knowledge so much faster that it makes greater challenges feel more attainable.

Working on the same thing :) Glad to see more people working on this too!

https://www.timetler.com/2025/08/19/unlocking-rich-ui-compon...

The value of generating framework components is that you can integrate the rendering with those frameworks. I've been working on a library to do exactly with a custom MDX pipeline: https://www.npmjs.com/package/react-markdown-with-mdx

I've been working on a similar project using MDX as the parser to enable runtime static JSX tags in markdown: https://www.timetler.com/2025/08/19/unlocking-rich-ui-compon...

I'm curious why you decided to go with a DSL instead of embedding an established language?

No and yes.

MDX parses JSX so it's compatible with any JSX runtime, not just react.

You're right that MDX executes arbitrary code because it supports the `import` and string interpolation of MDX and performs unsafe evals.

Because those evals aren't safe to use at runtime, I actually created a library that uses the MDX parser to support the static subset of JSX (which is very similar to HTML making it static and secure): https://www.npmjs.com/package/react-markdown-with-mdx

MDX does needs to be done at compile time because MDX contains unsafe evals in its syntax via imports and string interpolation.

I created a library for runtime MDX because of that: https://www.npmjs.com/package/react-markdown-with-mdx

The components are standard react components so once it is rendered they can set their own state and effects and load in their own data.

I hope I understood your question correctly?

Author here. I'd love to see it! I settled on this approach after not finding any other ways to do it, but it's definitely not the only way. I'd like to see what other approaches people might come up with.

Friendlier doesn't necessarily mean gassing you up. This is a very narrow interpretation of the complaints.

I think the framing of these models are being "intelligent" is not the right way to go. They've gotten better at recall and association.

They can recall prior reasoning from text they are trained on which allows them to handle complex tasks that have been solved before, but when working on complex, novel, or nuanced tasks there is no high quality relevant training data to recall.

Intelligence has always been a fraught word to define and I don't think what LLMs do is the right attribute for defining it.

I agree with a good deal of the article but because it keeps using loaded works like "intelligent" and "smarter", it has a hard time explaining what's missing.

That's really fun! I love minimalist sandbox ideas like this.

I find it's incredibly helpful for prototyping. These tools quickly reach a limit of complexity and put out sub par code, but for a green field prototype that's ok.

I've successfully been able to test out new libraries and do explorations quickly with AI coding tools and I can then take those working examples and fix them up manually to bring them up to my coding standards. I can also extend the lifespan of coding tools by doing cleanup cycles where I manually clean up the code since they work better with cleaner encapsulation, and you can use them to work on one scoped component at a time.

I've found that they're great to test out ideas and learn more quickly, but my goal is to better understand the technologies I'm prototyping myself, I'm not trying to get it to output production quality code.

I do think there's a future where LLMs can operate in a well architected production codebase with proper type safe compilation, linting, testing, encapsulation, code review, etc, but with a very tight leash because without oversight and quality control and correction it'll quickly degrade your codebase.

I've lost count of how many "Migrating from X to Postgres" articles I've seen.

I don't think I've once seen a migrating away from Postgres article.

They also scrape and cache sites on behalf of the user too. I understand why media sites are upset about their lack of control over their content, but that's just how the internet works. Sites and services proxy requests for their users all the time, and since this is live scraping directly on behalf of the user from an affirmative user action, it's not really materially different from a proxy.

You could simply shift the site requests to an end user machine instead and then have that data be sent to your server for processing, so all this seems like a technicality of what machine is doing which work. It's very different from an indexer like a search engine that does batched crawling.

It was dumb of Perplexity to specifically say that they follow robots.txt, and then not respect it immediately after. I doubt it was a consciously malicious decision as it wouldn't make any sense to try and get some good will from that commitment and then expect nobody to notice that you weren't actually doing that. I expect that they simply forgot they even made that promise. That's still a problem though. Too many companies sloppily make pledges because they think it will make them look good only to immediately stop caring about the pledge right after they say it.

While it was definitely wrong of them to commit to it and renege, I don't really think robots.txt should be expected to be respected for a live web scraping use case. I think performing a web request immediately after a user requests it is much more similar to a proxy service than it is to an indexing service like search engines. Should archive.is also be expected to respect robots.txt as well, even though it's directly performing a scrape on the user's behalf? How is live scraping materially different than a proxy or a CDN? robots.txt was created in the context of crawlers scraping content on a batch schedule as opposed to a real time on the fly schedule.

Live request services could even leverage the end user's machine to perform the requests directly and then provide the data to them instead of doing the scrape on their behalf, so I feel as though the directly responsible invoker of the data being taken off their sites is more the user than the service that's acting as a proxy.

The current media order is definitely at risk and it's something we need to find solutions to protect in some way to prevent reporting from dying in this paradigm shift. Trying to push against the entirety of AI progress is not going to work and this is really just screaming into the void over technicalities. Even if live scrape powered AI services were banned, the same service would just move to the end user with apps that will perform the requests directly on the user's device. I don't think anyone outside of the industry cares about the technical nuances of how AI services visit websites for the user. There's a bigger problem at play here regarding the future of high quality media, and it needs to be addressed directly.

For a bit more context, the creator is doing a full rewrite.

I think it would probably have been cleaner to release the rewrite first, then close all the old issues as deprecated. You could isolate the rewrite branch issues with a version tag. Closing then while the new version isn't done may lead to contributers opening new issues on the old version without realizing that it is no longer supported.

But he's not just ignoring the issues and leaving problems in the code base, the entire project is getting a refresh.

https://twitter.com/jdalton/status/1571863497969119238