As a BE engineer when that happened, I had just started to become proficient in it, coming from Angular. I threw in the towel and went back to my backend world of peace and happiness. So he's not alone, these deprecations are insane.
I hear from the b/e people about containers, serverless, lambdas, ORMs, queues, schedulers, caches, pipelines (ok, I use these too), databases, API gateways. Oh, but it's podman now, not Docker. And they're moving everything off AWS to Azure. And there's three versions of the API my f/e needs to talk to still in production. And every micro-service depends on a different version of Node. Apart from the one that's in Ruby and the stuff from that department who only use .NET.
I don't believe this promised land of clarity, comfort and purity exists. It's just mess on both sides of the internet connection trying to solve different parts of the problem of turning user needs into money.
More often you inherit a stack and rarely you move away from it. And even if you jump on the latest infrastructure trends, there will probably be enough enterprise customers that they will support it for a while.
The beauty of this is that these technologies all tend to be optional, backwards compatible, and interchangeable. You make your choices when architecting depending on what you want to solve. You can build Hussain Bolt or Frankenstein. On the FE, just the landing page is a mission.
Most likely because you work on apps in active development.
Wait till someone asks you to add some feature in app that was deployed a few years ago and need something new.
Maybe fixing security issues by updating the dependencies? How likely will that happen without you having to rewrite the code of the app?
- they're much harder to learn and understand than the callback hooks from class components
- The built in ones hide all the ways React is managing state for you behind obscure names that don't reflect how or when to use any of them
- The new-ish `use` built-in doesn't follow the same usage rules as the rest of them (you can use it in places you can't use the others)
- the stateful ones create side effects (unless you pretend that state is an argument), so they don't even follow an easy-to-grasp version of the functional paradigm
- they have strange quirks (like you basically have to write your component function to use its hooks before you render anything... so you can't early return)
- the mental model for how to put them together when you're writing custom ones is a little bit funky too.
- the early "advert" for them was that we could put all our domain knowledge together in one place, rather than spread about over multiple callbacks. Given that we usually need to interact with a couple of domains at a time, in time with component lifecycles, I think this makes the code harder to work with rather than easier
You still can't add features like error boundaries in React without class-based components somewhere in your app. Even if they added these features to functional components today, it would be years before they'd consider them safe to remove.
HOC still exist and builtin features like `React.memo(MyComponent)` along with the like of more functional styles means they aren't ever going away.
But they're not deprecated. Where's the forced churn?
Every place that I've been at has made the gradual shift to migrate stuff away from class components as new stuff gets built or refactored. Seems like a pretty common development habit.
Mea culpa: they’re not being deprecated. But the existence of custom hooks removes the bulk of (if not all of) their utility, and make it much easier to reason about code and make your code well-typed.
The reality is that virtually all of the public AI tech available right now is from OpenAI. Over time as more models are commercialised and generally available, it's probable that Helicone will serve them too.
Unfortunately they are relying on the iOS app store to distribute their app, so safe to say they won't be around much longer due to third-party services etc etc.
If user don’t want to access the iOS App Store they can build the app themselves, I don’t really see what’s your counter argument here. The point I’m making is do not rely on any third party service completely
Essentially, Bolt (and Fast etc) are offering the convenience of a "1-click checkout" identical to Amazon's 1-click checkout button.
If you transact with Bolt at least once through any of their merchants, then Bolt will have saved your billing and shipping information so that future purchases are instant and do not require checkout forms to be completed. Theoretically with the reduced checkout friction there is a reduction in abandoned carts.
@Bitfinexed (https://twitter.com/Bitfinexed) would argue that order books based on USDT (Tether) are not, and either the rug would be pulled or you will quickly find that you're holding ~2% of filled value (actual backed Tether)
There are many big trading firms trading billions a day willing to do the tether leg for you if you don't trust it yourself (they will take the risk), but a sale like this wouldn't happen at once anyway.
Chunking JS just leads to massive latency issues as the client is forced to download dozens (or hundreds) of "efficiently" chunked JS files.
The e-commerce platform Magento 2 is packed with this kind of bullshit and is part of the reason my colleagues and I abandoned it for our clients' large e-commerce websites:
It seems though that in your example, all of the files being loaded are necessary on first load, and the total quantity is huge. Would the problems still be present if less JavaScript was depended upon on first load?
