I think the issue is that the marketing is a half truth. Standard is in fact majority owned by content creators, it's just that the marketing makes you assume that the creator saying the line is the owner when that might not be exactly the case.
Honestly Nebula always felt off to me because of this marketing. They never sold it as a place where creators had a more equitable share, or where they had more creative freedom and control (which seem to be true), but they used the idea that they were "fighting the man" by going at it alone. It always felt like a half truth which, turns out, it is.
Also the price always felt too good to be true to me so I always suspected some sort of investment from somewhere to create a loss leader. Though the jury's still out on that. But having worked on video streaming online myself I know first hand how expensive it can get so I wonder how profitable the company is.
I mean, when you're the one selling the gas to light that money on fire you have a vested interest in keeping it that way right?
I do agree that logging and spans are very similar, but I disagree that logs are just spans because they aren't exactly the same.
I also agree that you can collect all metrics from spans and, in fact, it might be a better way to tackle it. But it's just not feasible to do so monetarily so you do need to have some sort of collection step closer to the metric producers.
What I do agree with is that the terminology and the implementation of OTEL's SDK is incredibly confusing and hard to implement/keep up to date. I spent way too many hours of my career struggling with conflicting versions of OTEL so I know the pain and I desperately wish they would at least take to heart the idea of separating implementation from API.
Yeah they're not even deprecated really, that's the wrong word. That implies there not actively encouraged to be used. They just moved them to their own repo outside of eslint itself.
Yes! This is called binding in zigbee parlance. I have a couple of ikea bulbs and switches and, if memory serves me, you can bind up to 10 bulbs to a single switch.
That sounds awesome. I've dabled with something like that but only for lodash (makings sure all different flavours get aliased to a single thing) but I never went too far with all the other stuff.
You wouldn't happen to have an example of what you're doing laying around would you? I'd be genuinely curious to try stuff like that out.
Devil's advocate here: did we consider that any such exponential back off goes out the window when users, faced with a non-working site, will just refresh the page therefor reseting the whole process?
Personally I'd just cache HTTP 429 responses for 1 minute, but you could also implement rate-limiting inside the load balancer with an in-memory KV store or bloom filter if you wanted to.
Perhaps the context you're missing is that all large sites use ECMP routing and consistent hashing to ensure that requests from the same IP hit the same load balancer. Twitter only has ~238 million daily active users. 10 requests/second on keepalive TCP+TLS connections can be handled by a couple of nginx servers. The linked "Full-stack Drupal developer" has no idea how any of this works and it's kinda sad how most people in this thread took his post at face value
I agree with this sentiment. I find that most developers seem to be stuck in thinking of their components as imperative. They expect to alter the state (dom) directly instead of describing the dom as a function of state (props).
Because of that, they quickly reach for the escape hatch that useEffect provides everytime they need to change something.
I genuinely don't know how to help my fellow team members grasp the basic concept of components better. It doesn't seem, to me, like it's something everyone gets eventually. I've actually seen far too many developers who just don't seem to get there even after long months working with component libraries.
As a side note: I don't get all the love for class components. All I remember from using them were the endless bugs because we somehow missed something on willUpdateProps or whatever. Class components could have worked but they always felt like the different life cycle methods were all cobbled together with little overall consistency (see Vue for an example of life cycle hooks done better, even if I have plenty of other gripes with Vue's design)
Indeed. React was a welcome innovation because it enabled V=f(S). That's it.
The vDom was fast enough that it made re-rendering your view on every state change possible.
Now you don't have to worry about rendering, you describe your components as pure functions and you're done with that side of things, now you "only" have to worry about the state of your app.
Seeing comments here wondering "How am I supposed to use jQuery with React otherwise?" is baffling and disheartening.
Honestly Nebula always felt off to me because of this marketing. They never sold it as a place where creators had a more equitable share, or where they had more creative freedom and control (which seem to be true), but they used the idea that they were "fighting the man" by going at it alone. It always felt like a half truth which, turns out, it is.
Also the price always felt too good to be true to me so I always suspected some sort of investment from somewhere to create a loss leader. Though the jury's still out on that. But having worked on video streaming online myself I know first hand how expensive it can get so I wonder how profitable the company is.