I ran into some of those issues with the chunk size and hash misses when writing bitsync [1], but at the time I didn't want to get too clever with it because I was focused on rsync algorithm compatibility.

This is a cool idea!

[1] https://github.com/claytongulick/bit-sync

I'm so glad someone has finally described the phenomena so well.

"Comprehension debt" is a perfect description for the thing I've been the most concerned about with AI coding.

One I got past the Dunning-Kruger phase and started really looking at what was being generated, I ran into this comprehension issue.

With a human, even a very junior one, you can sort of "get in the developer's head". You can tell which team member wrote which code and what they were thinking at the time. This leads to a narrative, or story of execution which is mostly comprehensible.

With the AI stuff, it's just stochastic parrot stuff. It may work just fine, but there will be things like random functions that are never called, hundreds or thousands of lines of extra code to do very simple things. References to things that don't exist, and never have.

I know this stuff can exist in human code bases too - but generally I can reason about why. "Oh, this was taken out for this issue and the dev forgot to delete it".

I can track it, even if it's poor quality.

With the AI stuff, it's just randomly there. No idea why, if it is used, was ever used, makes sense, is extra fluff or brilliant.

It takes a lot of work to figure out.

There's potentially a genetic predisposition as well? [1].

[1] https://www.sciencedaily.com/releases/2010/10/101027161452.h...

I actually went back to the s25 from the fold because of this.

When you get sand in the hinges, it's pretty annoying and difficult to clean out. I was always nervous about taking my phone out on the beach.

That's tough living in Florida, the whole state is basically a giant sand bar.

I also actually didn't like the fold part. Most of what I do on a phone is read Kindle or browse the web.

For Kindle, the phone was uncomfortable to hold with one hand for long periods to read.

Web browsing was worse than a normal phone because many common sites like weather.com have responsive design that get very confused and unusable with that "in-between" size. The display on the outside of the phone that you can use while it's closed was so tiny and narrow it was unusable as well.

The whole thing was heavy and clunky feeling. (This was the most recent galaxy fold, the pixel one may be better)

I was pretty happy to go back to a normal form factor.

The new Pixel 10 fold has a sealed hinge, and is water proof.

I think (hope?) that the best thing that will come from tye AI hype will be innovations in power creation and delivery.

If the unexpected side effect of building these giant stochastic parrots is that we usher in an age of decentralized, safe nuclear SMRs, it will have been well worth it, whether or not they are actual productivity boosters.

I think the exact opposite of that is what is most likely to happen.

Lightweight native web components rendered on the light dom with lit-html and a simple API layer in express 5 is about as close to perfect as I've ever found.

The only "weakness" is that it doesn't have guard rails, so may not be great for larger teams with mixed experience.

I try to structure functions and validations like this in a early-return list at the top of a function.

    if(val <= someconstant)
        return; //not valid

    if(!(condition2 || condition3))
        return; //not allowed

    ...

The author mentions this technique as well.

I find it particularly useful in controller API functions because it makes the code a lot more auditable (any time I see the same set of conditions repeating a lot, I consider whether they are a good candidate for middleware).

I try to explain this to newer developers and they just don't get it, or give me eyerolls.

Maybe sending them this article will help.

Sudden outbreak of common sense.

This looks cool!

Maybe it's because I'm on my phone and I don't see the full UI, but I'm having trouble navigating the tutorial section.

I don't need the "hello world" basic tutorials, I'm looking to jump in to a point that meets where I am with GLSL - is there a TOC or something for the tutorials?

Some sort of path or progression that you can jump around on?

Hey, thank you ! there are 5 tutorial exercises - filter the exercises by the intro difficulty. Once you're done with them we recommend choosing some interesting easy exercises and reading the learnings info about them - there is no real order but we are working on a concept of tracks to order our exercises a bit more. Coming soon

Web components are neat but they don't solve the problem React solves. React provides a simple mental model for managing client state, which is the one of the main challenges in frontend. It's basically, "re-render everything when one of your dependencies changes" -- and that's extremely easy to understand and reason about. It incurs significant performance overhead, but your app has to be fairly large before you start running into meaningful perf issues.

An outsiders perspective: react LOOKS like a simple mental model because all the front-end folks got used to it. Its not simple, its not intuitive, and this fact fundamentally makes it a bad framework: mediocre engineers often end up using it wrong because of this.

I've had an easier time learning Vue than React, and I've probably spent much longer trying to learn react. And if im not wrong, AI writes better Vue code than react code as well.

React is simple. When you really think about your data model, you’ll find out that you only need a handful of global properties, and the rest is data derivation and integration to your API or your storage layer.

Most issues stem from developers refusing to read the docs and to plan their presentation layer.

I agree with some of this. I find react unintuitive. I find it infrutating how many hoops I have to jump through to get things done in react. In the past, I've only looked at UI as a thing I tack on after writing the core functionality. So I go write the core functionality. Then I try to add a react UI on top. Suddently it requires me to re-write my entire core because it wants control of all state. No other UI system I've used does this.

If what you wrote is truly a core, you’ll only need to write a few functions to translate it to the reactive pattern. You already know the state of your core and the events that drive its transition, matching it to React’s is often pretty straightforward.

> mediocre engineers often end up using it wrong

Might be because mediocre engineers don't read the docs.

My style with web components solves it really well.

Just have each component maintain it's own state. Class setters work great. If you need the component to update, just call render() in the setter.

It's super simple, encapsulates logic, and brain-dead simple to debug. You know exactly where to go for everything: the component.

I've always felt like react's approach to state management was creating more problems than it solves.

How do you handle state that affects multiple components? Like a filter button that affects a list table. In React you just hoist the state up and make both components dependent. If you're managing all state via internal component state, then you need to explicitly pass state between the components. That's okay for simple cases, but in my experience it breaks down pretty quickly. Once you have more than a few components involved, you end up writing your own state reconciliation.

There are a few different ways.

One really easy way is to put a custom element at the root of the dom and just add/remove event listeners, maybe one-shot if that's all you need.

I also have a convenient little library called ApplicationState [1], which basically does the same thing but can persist state in indexdb.

Lots of other libraries out there too.

[1] https://claytongulick.github.io/applicationstate/

That's why I wrote Lit State, a simple state management lib to use in combination with Lit, a simple web components lib. It works really simple, and it's simple to use. Much more intuitive than React.

https://github.com/gitaarik/lit-state

For me it's about productivity. I can code anything in react without opening the doc once, cause it's javascript and useState/useEffect. Zero pain points. I can focus 100% on delivering features. I can't comment on web components but I worked with Angular for 2 years a decade ago and I was always in the docs wondering what's the syntax to render a list or what's the function to do even the simplest things. Same with Backbone.js before Angular.

Completely opposite experience for me and when I used to write React I’d avoid useEffect like the devil.

The ecosystem really is the main argument. If you want to hire developers who can work productively in your codebase, part of that is being able to match their expectations of what the code looks like. React standardizes your codebase, even if the standard produces complex code.

Sure, but when I balance all the factors, bundle size, performance, weird ecosystem stuff like redux, framework churn, and debuggabilitiy I still scratch my head.

Every react team I've migrated over to WC have picked it up within a couple days, and I've had universally positive feedback on the change.

Also, the web components ecosystem is pretty dang good these days. Between ionic, shoelace, and all the others, there aren't really any functional gaps that I've seen.

I think at this point it just has momentum, and people just go with what they know.

There is no shortage of developers who can understand Java Script and general application development concepts. And why would I ever want to hire a person who can only be productive in confines of single framework.

I feel like "other than the ecosystem" is doing quite a bit of work here.

For sure, and that's the primary valid technical argument.

I've never really been a big one for that particular argument though. I've seen the same argument made about Cold Fusion, flash, flex, visual basic, asp server controls, jquery, dojo, moo tools, backbone, and many others.

Same here. All my front ends for business apps are bunch of native web components, some libs and some core managing business logic. All pure Java Script. Works like a charm, no build needed.