joshum97

> Coding AI is different. By that I mean building features that use an LLM, where much of the programming involves writing prompts to get the output you want.

As soon as you add LLM fuzziness to a codebase, it seems to propagate like a virus. You can’t get anything reliably useful for machines downstream of a prompt—even with structured output & friends there’s always the possibility it’ll be flat-out wrong. Reminds me of the old “function coloring” issue except it’s probabilistic instead of async. Obviously it opens up incredible possibilities but I do miss the days where you could predict exactly what would happen by reading code.

marketers

There's nothing wrong with "dirty" HTML. Modern layouts require lots of wrapper elements--certainly some sites use them unnecessarily, but it's not reasonable to expect a nice modern layout to use the same number of elements as a basic document. And utility CSS has merits. That's a totally separate concern from inaccessible div soup--you can still use sections, navs, aria- attributes, etc.

If you're working with a marketing team, you'll find that they are desperate to serve their content to LLMs, to counteract the rapidly shrinking number of people actually visiting websites. What I don't want is for that to mean "build the website twice, one for humans and one for LLMs". Websites are for people—bots can adapt.

I feel like I am going insane. Who in their right mind would feed an LLM raw HTML in the first place??

HTML is a markup language. User agents present it in a way that makes sense for the user—visually, or through assistive technology. Nothing about adding LLM “users” should change this—their user agent, the harness, should present HTML in a way they can natively understand, by translating it to Markdown.

We are not going to rewrite the entire web because harness developers are too lazy or stupid to pull an HTML to markdown package from npm. If some sites want to do so anyway, good for them, in many cases I’d love to skip the CSS/JS and read the markdown directly (or better, nicely formatted). But don’t blame website authors for your harness wasting your tokens.

Might be tolerable if it would have given us fully automated utopia, but instead we get to watch the world burn and know nobody’s gonna do anything about it.

If things keep going this direction my job title is just going to be "tool call".

I'm a bit intrigued that he ended up happier now that Claude's in the driver's seat and he's playing a supporting role. Maybe I'm ngmi but I'm not sure I'd be happier.

Very nice!

Really fresh approach to site “addons” by just copying in and owning a folder instead of installing a million packages.

Really excited for JS to finally get something similar with Iterator and AsyncIterator helper methods. It's way behind Ruby in that regard.

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

https://github.com/tc39/proposal-async-iterator-helpers

This is a cool approach. Definitely better than an all-at-once cutover!

If only Ruby had better support for static typing though. Clearly infinite dynamism works for some folks and a lot of successful businesses, but I couldn't live without a type checker pointing me towards all of the places that need fixing. Kind of forces you to have comprehensive test coverage or you're screwed, which maybe isn't a bad thing.

I’m working on eslint-plugin-solid for this reason, and while I haven’t implemented this yet (it’s complicated), it will eventually warn when something is wrong with reactivity in general.

Nit: to me at least, "Never deal with another freelancer" comes off as unnecessarily harsh (even if it resonates with some). I understand the product is targeted to early-stage startups without the budget to hire someone, but it sounds like it's putting down the idea of working with a designer altogether (see "no need to hire a designer"), when you could poise it as complementary to working with a designer eventually if we choose to do so.

This looks a lot better with the F# proposal:

    return cb(predicate) |> negate |> filter;

We've suffered under "bad parts" in JavaScript before, and the solution was not to use them, which works out fine for the most part. But I tend to agree, adding a functional language feature built in a way that conflicts with Ramda and nearly all existing FP libraries is no better than simply using R.pipe.

In response to people repeatedly advocating for F# + partial application over Hack, TC39 responds with what is essentially a threat:

> To emphasize, it is likely that an attempt to switch from Hack pipes back to F# pipes will result in TC39 never agreeing to any pipes at all. PFA syntax is similarly facing an uphill battle in TC39 (see HISTORY.md).

While I can respect differences in opinion, this feels heavy handed.

Here’s the relevant section: > In most cases, React Native will use JavaScriptCore, the JavaScript engine that powers Safari. Note that on iOS, JavaScriptCore does not use JIT due to the absence of writable executable memory in iOS apps.

I think React hooks would fit nicely anywhere you need incremental computation, and a compiler is the first thing that comes to mind. They’re made for efficiently updating the output (DOM) in response to small changes in the input (sum of past user actions). If you can format your problem like that, based on a component structure, a similar API might be a good fit.

Esbuild does have a JS transform API, so you could write a command line tool that walks the file system (Babel, ESLint, Prettier, etc. all do this so you have examples), transforms each file, and writes the code back out. Snowpack's build command also does this.

I’d push it one step further and include “unskilled” labor too. The value added to society is measurably positive no matter the skill level of the immigrant.

Back in college, I had a summer research internship where the previous year, the interns tried to migrate a large Java code base to Gradle and left it in a broken state. Knowing little more than the Java language at the time, I spent about a month getting Gradle to build it correctly. It was incredibly frustrating not to be able to understand what Gradle was actually doing, instead only copying random lines from example configurations. Almost every time I would fix some errors, new ones would appear with no way to know how close I was to the end.

It’s nice to know that I wasn’t the only one who struggled!

Does Lucet (https://www.fastly.com/blog/announcing-lucet-fastly-native-w...) meet those needs?

Good point about conditional compilation. It’s a trade off I’ll leave for language implementors to make. I tend to think that easily preventing a malicious package from sending your file system contents to some server is usually worth 10-20% perf loss, and that might even be made up by Wasm SIMD and other proposals.

I would agree with you, except that LLVM IR isn’t platform independent. For all of Wasm’s warts it’s the best supported low level cross platform IR we have.

I think Wasm outside the browser could benefit package managers. As far as I know, Rust and some other compiled languages distribute their crates/packages in source code form, which then have to be compiled before use. If packages were distributed in Wasm (plus headers/type declarations), you could JIT or quickly AOT compile them. Plus, you’d get safety guarantees to make sure a package isn’t doing anything it hasn’t been permitted to do.