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.
Yeah, that's good feedback. We don't want to put down the idea of working with a designer later in your company. In fact, many of our users have grown their companies and hired designers to extend their brand into their application UI. We'll work on the phrasing.
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.
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.
I personally prefer F# pipes as it leaves the door open for partial application in the future, whereas Hack pipes closes that door because any partial application would be duplication.
However, I feel like all the people using Ramda should just make their own language if they don't like the direction JS is going in. This is a "too many cooks spoil the broth" situation.
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.
iirc the Hermes has AOT'd bytecode but not real native execution, from what I read they couldn't get the performance up enough to offset the size cost vs their bytecode and for many regular React-native apps absolute performance isn't as important as not being waaay too bloated.
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.
