afiori

The reason react sites are bloated is because there are a lot of things that are easy to do once you have better DX, there is nothing stopping you from making completely static sites with no js (solid-js 2.0 has a whole "htmx-like" mode that lets you have good interactivity even with js disabled).

WebComponents are useful for cases where you want something slightly more integrated than an iframe or want to make a library of small widgets

WebComponents were created out of spite for react and are the composability equivalent of medieval artist drawing horses that look like they had never seen an horse

I don't why a sha256 project could not support sha1 usages too: if you try to merge/rebase/cherrypick/whatever a sha1 commit in a sha256 project git could simply recompute the needed s256 data and keep old sha1 ids as validated metadata. you could even use either hashes as tree-like refs.

you could even do the same in reverse and "import" sha256 commits in sha1 projects. the only real difference would be which one is used as primary key in git's internal store.

The only alternatives to nuclear are coal and LNG

Or starting with solar more 20 years ago.

I think it is so that the server extensions can do stuff on the client, imo the weirder part is that it installs a bunch of stuff on the remote

> If you treat a branch as your unit of review, then it becomes super difficult for someone to submit a chain of related changes. You'll be constantly rebasing your pull requests onto each other as you get feedback from dependent branches.

> A rebase can introduce change to a commit in cases such as handling conflicts or squashing.

and with change ids you can quickly separate commits that changed from commit that did not.

> Also, a commit already retains it's commit message after rebasing.

but commit message are not ids, there is no command for checking out a commit by its message, nor any sense that commit with the same message are somehow functionally related

change ids are more analogous to commit messages than branches, eg suppose that in a feature branch you have a "Delete deprecated classes" commit; in git there is a clear idea of "cloning" this commit (eg rebase, cherrypicks, maybe reverts) and the common sense that the new commit inherits the same commit message. Change ids are the same thing but in hex id form that can be created for every new commit/stash/index.

They allow for example to identify all the clones of a commit and they allow to give stable identities across rebases eg suppose you rebase a typo at the beginning of a feature branch without change ids a reviewer sees n new unrelated commits while with change ids it is possible to clearly identify which commits where changed/added/removed since the previous review iteration.

IMO one of the main insight in the maxim is the importance to have the form communicate the function to the user.

my point is that that a lot of people shit on js for having "weird crazy stuff in it" and then the example is 0.1 + 0.1 + 0.1 !== 0.3 or NaN != NaN which has nothing to do with js semantics

JS is weird, and not having a stronger separation between ints and floats makes NaNs more common than in other languages (eg parseInt would not return NaNs in C or python) but for many "weird" examples people are making fun of normal stuff.

NaN means only NaN, 0/0 is NaN at the cpu level.

to my weak undestanding only pow and hypot behave like this; pow for math reasons and i could guess that hypot does that to sorta have |x| <= hypot(x,y)

yes, source release on day one, proprietary license valid forever, free license becomes valid after X time and users need to only satisfy one of them.

Many projects already do this; proprietary source does not mean closed source, it can simply be freely available but with no copyright concessions

> But using locks is bad for performance and latency and thus UX. yeah but this way you have only one lock, with free threads or preemptive multitasking you have to have them sprinkled into every data structure each with its potential for deadlock and livelocks.

Also look at single core focused systems like spacetimedb, sometimes if a workload is not embarrassingly parallelizable multithreading can make things slower.

JS needs some way to more easily push things off the main render thread, but i think that there is no easy solution for it. (maybe a model like iirc clojure had where "threads" would automatically rollback and retry in case a data race was detected could work to handle off-threads tasks in js, but it is a quite far off solution)

A lot of the bitching about react always had the same flavour of the complaints that JavaScript dares to have a NaN

To be fair it is stupid that NaN !== NaN but that is how IEEE and CPUs made floats to be

JavaScript's execution model uses cooperative concurrency to avoid a tons of data races, preemptive non-parallel concurrency would make all web development incredibly harder

C++ and python are exactly where I would expect this problem to come up

True, but in a sense a single frontier model of today would be of incredible historical significance in the far away future.

Sure but each of them is being priced as if each one is gonna have 90% marketshare in the future.

Markets and rationality are sometimes just acquaintances

For a lot of people writing prose is a chore

> (2) There is nothing actually forcing the open source release.

the anti-cloud-use license would include it, with no need of a separate release

I cannot answer your main question, but i can give you recommendations wrt what you are gonna try to do.

Very likely there will be a lot of parts of the app you are not going to understand, those will be the main problems so help claude help itself.

Make it add diagnostic/event-logs to every part of the stack and potentially even design implementations around traceability (eg avoid batch background processes that touch many flows if possible). so that claude can check whether runtime behaviour matches expectations. also store historical data to help debug regressions.

Treat implementations as cattle not pets, once a feature is done consider scapping it and turning it into a design doc, then ask claude to reimplement interactively with you step by step explaining to you what is going to do, why it matters, etc. this is a very good way to minimize the black boxes you don't understand in the app.

if the app is web make it work very well with playwright for e2e ux tests.

finally i like the architecture given in https://www.youtube.com/watch?v=4KvbVq3Eg5w (use ui composition to define feature) but this has little to do with claude

An Oxford comma before the or would make it clearer maybe

you are right a stack of printed qr codes is better

Yes, but i cannot create a robot that can get married, people do not have the right to give personhood to tools

Woke activists love the word "systemic" for a reason.

If a bunch of good people acting in good faith produce a result an evil mastermind would want does it matter if they are good? On many levels obviously yes, on some practical levels the system and the incentives still need to change.

Weirdly I think humans should have more rights than machines

A legislative solution to Flock seems a lot more feasible than one for literacy

Most uses of .env files are for apps or containers imho, so you could just have a .env file in each folder and configure docker compose /node / whatever to pick it up

courtesy of chatgpt there is also this abomination

    ht tp://[\x00::gg]\t/foo\nbar/%/%QZ/%F?q=<\"|{}>##