439 karma · joined May 11, 2017
The difference between observer approaches like SolidJS or MobX (and I'd also put Svelte in this box) and React's data-flow centric one is one of explicitness. With the observer approach change tracking is more implicit, i.e. embedded into the values you are using and the functions that are using it. Which does fix the problem of forgetting to declare dependencies, because using == declaring.
Now what it does not guard you against *per se* is unnecessary re-runs, I am willing to bet there are tricky cases with tracking of nested objects and updates based on partial changes there. SolidJS does expose various tools for untracking and batching signals, so it might be a matter of trading initial explicitness/complexity for adding it later.
This might be the right trade-off and untracking might be the smaller problem. But that feels like a somewhat team and product specific question. I think it is clear that without state libs React is to barebone to handle most somewhat-complex interactive apps, and a lot of them are observer based (MobX, Recoil, ...). But I do not see it as a silver bullet just yet.
I was satisfied with this reaction from Jonah wrt the mailing list and such:
https://medium.com/@thejonahbennett/statement-on-emails-83c5...
The Web3 stuff is making me more skeptical, but let's see!
> Feels like all tooling starts out with "We're simple, no config or code needed!" and eventually ends up so extensible that it's hard to figure out how to even use it. Then another competitor appears and shouts "We're so simple compared to X, no config or code needed!", and the cycle repeats.
I think that is missing the point of middlewares. They are not a thing you _have to_ configure before you can even get going (which is what zero-config usually alludes to). Instead middleware is a mechanism for sharing code between different routes.
Now that code might contain functionality that can be eliminated through strong conventions (i.e. always parse JSON instead of having to configure a content-type aware body-parser middleware). But that is a very specific use case and middlewares do a whole lot more than that. So even with goodest faith, I think your point does not land.
Namely view code (HTML/CSS/JS) was harder to compose in a scalable fashion, Rails'/Django's template composition feels vastly inferior to proper componentization. Namely limited type checking, globals sharing, ... These things do make it harder to refactor and get rid of unused code, which also has real impact on users.
Another biggie was that there is no great gradual path from server-code to client-code, with potentially additional data. Now React SSR does make you work more for the server use case, in that you tend to write code which should also work on the client-side (which might change with React Server Components) but at least you don't have to face lots of decisions when expanding the interactivity of your app.
All that said, I also agree with the blog that there is still lots of refinements to be done on the React side of the world, I just view the world we came from as far less rosy.
There was money to be made in housing 10 years ago when rents were half of what they are today. What changed is the demand / supply ratio. I guess the laissez-faire logic would be that higher demand drives up the prices so much that investors can't help themselves but build more. Do we have empirical data from other cities that show that relationship? I.e. as rental prices rise so does private investment in housing? And also the opposite, how much do rent caps like the one in Berlin influence housing investment longer-term? I'd argue our Berlinian experiment did not get a real chance to run, given the expectations around it were that the courts might over-turn it, as they did.
From my understanding and from I read over on freakonomics a lot of the assumptions about rent caps come from single neighborhoods in NY which I'd argue does not generalize.
is he being ironic? One of the things I love most about 8601 is it being supported by basically every* std lib (and definitely every library working with dates)
* JS, Python, Ruby, PostgreSQL,...
This one I don't get. Empowering workers, in leftie politics, usually means some version of labor, wage, union,... protection laws (not saying this wrong, I'm myself seeped in leftisms). Thus creating a dependency to the state to protect one's work from the ruthless.
Where is the principal difference between being dependent on the state for cash vs protection?
Wrt the larger UBI point: I see it more as an opportunity for people to find deeper, more personally meaningful, work. My inner optimist hopes people would seek out more fulfilling, self-determined, work. My inner pessimist sees the Wall-E thing, though I would not call it underpinning. My inner realist would like to see more studies.
Thank you!
I'd be curious to hear about examples where the runtime did or would surprise you!
More to your point, as I think you were using this as an analogy for the perils of giving up control: Rust's explicitness should entail all the semantics of your program, and hence async Rust makes you model out all the potentially-racy async interactions with Arc, Mutex, etc. The same middle-man (the borrow checker) who watches over your regular ol' sync code's memory-correctness, now expects extra constraints to be upheld for values passing through async-boundaries. And for me the whole point of Rust is that this correctness proof will do a better job than any person could, for any moderately sized program. So this is middle man you'd want between you and the CPU.
That said, your async runtime could definitely do shenanigans that screw up your nicely modeled program, but that would be a bug in that specific runtime. I haven't deeply read Tokio's source and even if I did, making a qualified judgment about it is beyond me.
2. Is it solving your problem?
2. Check low resolution metrics like stars, open issues, size or recency of commits. Weigh that against your use case. For example if it's a niche, stars matter less. If the requirements are well defined and in a slow moving space, recency matters less. Etc. If it's doing something big and fundamental for you, make sure that it has enough contributors who are likely to not suddenly stop contributing (preferably businesses whose success is tied to it).
3. Read the docs, examples/demos, tests etc. Find posts by people applying it for similar use cases. Does it solve your particular problem well (incidental vs inherent complexity)? Read through some of its GitHub issues to get a feel for the maturity, usability and support of the project.
4. Loop through those steps until you find something that holds up. If everything speaks for it except for longevity concerns start reading the code and consider whether you'd be able to contribute to it.
So I think saying "by thinking anyone with differing opinions is Xist" is a mischaracterization of what was expressed originally.
Err, does it? The first thing this suggests is that the JS community is 7.5x larger (true for Ruby, even larger factor for Perl and not true for Pyhthon [1]). The second thing this suggests to me is that npm is X times more usable than those languages package managers, which from my experience true for Python (not for Ruby though, dunno about Perl).
1 - https://insights.stackoverflow.com/survey/2018/#technology