Indeed, cognitive load is not the only thing that matters. Non-cognitive toil is also a problem and often enough it doesn't get sufficient attention even when things get really bad.
We do need better code review tools though. We also need to approach that process as a mechanism of effectively building good shared understanding about the (new) code, not just "code review".
> My react code now doesn't look very different to my react code in 2019
Server components, Next application directory breaking emotion for styling, stricter rules for hooks, the compiler breaking change tracking libraries such as MobX removing the need for useMemo and similar. This is just off the top of my head in React land.
You're complaining about MPA. Maybe if you choose SPA with vanilla React you would've felt that for the last 8 years there's been a flurry of conversation and innovation that's specifically not about SPA. The conversation around SPA has been frozen for nearly a decade.
Unless maybe you want to start talking about CRDTs? But that's kind of niche, and CRDTs are actually an old conversation, one which started before React was first released. That should give you a sense at the pace of conversation for SPAs.
Also, because next broke emotion, toolkits such as Mantine broke backward compatibility in order to move off of emotion, so second order instability effects still affect SPAs
If you have a very large project which uses MobX, I don't think the amount of warning matters. You'll most likely have to (eventually) completely rewrite large amount of code, to the point where it might be easier to migrate to SolidJS.
If you have a large project then it's your victory or fault for whatever comes of using software marked as not ready. The React team has been absolutely clear that it's not ready.
On an aside, SolidJS has been taking a huge momentum hit recently, I think the drop in downloads is a lagging indicator. It's not an easy space, I love SolidJS and recognize that Ryan Carniato likely took a career hit to work on Solid, but my bet is that Solid will fail to catch critical mass. Really sad as I love the Solid experience.
That promise doesn't really make sense to me - although partial compilation will likely ameliorate most migraiton pain for library dependencies if they come pre-compiled with the compiler.
Code written with the react compiler in mind will inevitably be MUCH slower without the compiler, as its not going to manually add any memoization. Likely to the point where its not going to be usable without it.
> Implementing a basic "useState" and "runFunctionComponent" is easier than most third-semester CS assignments.
I'm not sure it is. There is a global dispatcher that finds the right component state to use and increments a counter to ensure that the correct state "slot" for that component is used. There are also a bunch of mechanisms to prevent slot mismatches. I guess you could make a loose analogy with writing custom allocators, except instead of the binding knowing the address, the order of calling useState determines the address :) Really not that simple.
> I'm not sure it is. There is a global dispatcher that finds the right component state to use and increments a counter to ensure that the correct state "slot" for that component is used.
Explicitly not part of that proposed task. We're talking about a basic hooks implementation with useState here, not how react deals with its tree of components.
For the sake of the task the signature of runFunctionComponent just needs to be
where runFC would wrap the call to the function component to pass the appropriate props and store the return value, freeing students from thinking about that. Also specify the function doesn't need to be re-entrant.
In either case it won't need concern itself with what the component returns (children, whatever), matching children to tree nodes, or scheduling, at all. Would be nonsense to cram that logic in there anyhow.
What you were talking about would make a good later task: easy to get a basic implementation, but hard to get an implementation that isn't subtly wrong in some way. Plus you can slap on extra goals like supporting keys. Lots of room to score students beyond just pass/fail.
The one place where signal based fine-grained reactivity still wins are lists.
Updating the "done" state of a single todo item nested in a list of todo items still causes an entire list (of possibly hundreds of items) to re-render.
In principle you can solve this with fully normalized state shape but in practice things like MobX (especially when combined with SolidJS) still provide the best ergonomics and separation of concerns with very little compromise.
I'm however excited to see what kind of DX improvements the compiler can bring to the table. Perhaps someone will have a good idea and we'll get something that's at the level of MobX.
Ok haven’t tested this but assuming a naive implementation of an array of 1000 items and setting completed: true in one of them by updating the array would trigger 1000 calls to the inner components.
If the react compiler is used, 999 of them will return their memoised result. 1 will need to be rendered again.
Which has an overhead but is still a huge gain compared to actually creating vnodes and diffing all render results for all items.
You are right, in case of fine grained reactivity, this could just trigger a render on the specific item. But for that to work, the framework will need to wire up 1000 subscriptions to prop changes, have proxy objects and shit like that. There is a larger initial overhead for that and the memoisation + brute force approach might be better at the end.
The setup / overhead is for the initial render, but after that I'd be surprised if O(N) defeats O(1) even with a bit of a bigger constant (given a sufficiently large N). Also, given React Fiber, I doubt that those 1000 calls will simply be function calls - I'd expect plenty of overhead on that end too.
Would be interesting to design a realistic benchmark around this. IIRC Michel Weststrate (the author of MobX) had a realistic example based on draggable elements on diagrams, where the diagram link lines needed to be recomputed in realtime as you drag the boxes around.
Another realisitc option would be large dashboards made of tables where lots of data updates come in real time.
You're selecting for people who feel they're priviledged enough to reach out to support and ask for bill forgiveness even when they may've messed up, repeatedly. This does select for something but I'm not 100% sure "people who are doing this work professionally" is that clear-cut, especially once you move past western cultural norms.
Hello, maintainer here. Happy to see this little project on the front page of HN. Unfortunately it hasn't received the appropriate attention from me lately, mainly because of the difficulties of running tests (and the android emulator) on GH action runners. Attempt to add some basic tests can be found here https://github.com/spion/adbfs-rootless/pull/62
This submission motivated me to check out the latest state of virtualization in GHA and it looks like GH shipped it for all linux runners https://github.com/actions/runner-images/discussions/7191#di... - so it might be possible to get that PR working now.
Encrypted storage is an implementation detail of the filesystem. Once you're at the point of connecting an unlocked phone to a computer running ADB, you can just transfer files and not care about whether or not the underlying data is encrypted at rest.
I don't think there should be any significant difference in funcitonality, other than perhaps the set of directories accessible. In general, you should be able to access anything that you can view / access using `adb shell ls`, `adb pull` and `adb push`
There is honestly not much to learn, and that might be part of the appeal. At its core, JS is a relatively simple dynamic language with a clean syntax. Despite the clean syntax there are quite a few quirks in how some of the internals work (sorting and pervasive string comparison and casting, equality operator, etc). The most interesting thing about it is probably the programming model of free-form objects and closures: rather than using classes, you could write functions that return free-form records containing functions (and getters) that close over the lexical scope of the function. This gives a kind of dynamic object construction flexibility without the additional boilerplate.
For the base language I recommend Dr. Axel Rauschmayer's books (https://exploringjs.com/) as they're kept very much up to date.
Where things get really interesting is TypeScript, which takes all of this dynamism and manages to model it with a type system that doesn't feel all that constraining. It also ameliorates most of the core language papercuts. I don't really have good recommendations for TypeScript for now, other than browsing typescript issues and pull requests for examples written by Anders Hejlsberg
You have to be very careful with the library and tooling ecosystem, however. There are a billion ways to do things, many of them incompatible with each other, and things break all the time. This includes major, popular libraries and frameworks with good looking documentation websites, so it can be difficult to pick something solid and stable. This is where most of the pain of using JS comes from.
We do need better code review tools though. We also need to approach that process as a mechanism of effectively building good shared understanding about the (new) code, not just "code review".