It's a bit like the <center> tag. A codebase that's littered with stuff like "InlineStack" is harder to work with and parse because the resulting div soup still requires extra styling, which is now both markup and CSS.
Why is it harder to work with? It makes it immediately obvious what the visual layout is and what the purpose of the component is and a lot of time all you want to do is have a flex on a component and you don't need other CSS to warrant yet another CSS class. It's the same reason why utility CSS was created (eg <div class="flex">). It also saves you from having to come up with a semantic name in your CSS for every wrapper.
React was literally first created in ML out of the author's dislike of MVC, who preferred functional programming and immutability[0]. For a long time, react aspired for its future to be in ReasonML.
Hooks came as no surprise to anyone who paid attention, as the recommended way to write components since at least 2016 was in the stateless functional style whenever possible, and many of us used recompose[1] to simulate hooks long before their introduction.
Maybe I was not paying attention, this is of course a possibility, but until at least early 2019 the react website's main page was only mentioning the class-based "stateful component" as the way to write components.
Although they were mentioning function components at the time in the documentation, I can't say how mainstream that was. Hooks were introduced in Feb. 2019.
Russia invaded in 2014 and the conflict stabilized (but didn't stop) in 2015.
In the meantime, the Syrian civil war was raging on.
Similarly, if we ignore all the events in the prelude to WW2, the world was a very peaceful place. According to Hoover, Roosevelt was a threat to world peace, not Hitler.
I'm not implying anything with the analogy, I'm only trying to illustrate that the world was not peaceful between 2016 and 2020, despite the president's efforts.
Perhaps if we had gotten 2 consecutive terms, it might have provided more long term stability.
If seeing how common `eslint-disable-next-line react-hooks/exhaustive-deps` is any indication, people just don't bother with best practices. Not to mention the majority of people I interview or hire don't know anything about CSS performance, they learn on the job. They'll happily add 1000 box shadows in a view if it's in the design.
Also OP is looking to move an existing React UI to Svelte, why not try Preact first instead of an entire rewrite? Or even Inferno or million.dev? If they did and they're insufficient, I don't even believe the browser's DOM is the right technology for that UI then.
Here's a utility to convert exported Aegis JSON to a Keepass 2 or KeepassXC database if anyone's interested
https://github.com/GeKorm/atk (binaries in the releases page)
Result: Zoom out, show 10 places with ratings starting from 1.5, among them a nail shop and a government building. If I'm lucky, it will also show the 4.7 star pizza place 2 blocks away, for which I needed directions.
Funny thing is, sometimes Maps will zoom right in. The classic is when I'm looking for something obscure near my island off the Croatian coast, and it'll zoom right in to a match... in suburban Bratislava. It's almost like it's hoping I won't notice where it's gone.
The client can track its own error rate to the service, but it would need information from a server to get the overall health of the service, which is what the author probably means. Furthermore the load balancer can add a Retry-After header to have more control over the client's retries.
I think I've misunderstood what circuit breakers are for years! I did indeed think they were a server-side mechanism. The original commenter's description of them is great, you can essentially create a heuristic based on the observed behaviour of the server and decide against overwhelming it further if you think it's unhealthy.
TIL! Seems like it can have tricky emergent behaviour. I bet if you implement it wrong you can end up in very weird situations. I should visualise it. :)
I mean, they can and should be both. Local decisions can be cheap, and very simple to implement. But global decisions can be smarter, and more predictable. In my experience, it's incredibly hard to make good decisions in pathological situations locally, as you often don't know you're in a pathological situation with only local data. But local data is often enough to "do less harm" :)
It's confusingly presented in the video, but they already work in the near infrared, up to ~900nm. They're used with IR illuminators and lasers all the time.
There are tubes that work on a wider spectrum, like the Photonis 4G tubes from UV to IR 350-1100nm. But I found them dimmer than the L3Harris in the video.
Where in my comment did I scoff at the idea of using a GUI? I personally mix a GUI with the CLI. Good Git GUIs certainly have an "Abort merge" button. But it’s far easier to write out a command that everyone can use than hope someone is using a good GUI.
My comment is in agreement with yours! I'm just expanding on how absurd it is to struggle with merge because GP didn't know about a simple --abort, and how common it is even with senior devs.
And yeah I too find a mix of GUI and CLI works great.
Oh I'm the complete opposite. Why does everyone use a GUI for everything? You get good at dealing with the good plan _OK_, but if something goes wrong or you want to automate something, there's no flexibility.
Git's core abstractions map pretty dang well to a GUI. And the commit graph is inherently pretty visual. I find it a heck of a lot easier to navigate a repository graphically than via the CLI (it can be done, it's just not fast). For most people a GUI works better when they get into a sticky situation with git than the CLI. Automation is different, of course, but it's not generally hard to map actions in the GUI to commands if necessary.
Here, every veteran developer uses git and rarely needs to ask for help (although it might save time), and every novice developer uses GitHub Desktop.
This works great.
One exception: if someone does a local rebase on a feature branch, GitHub Desktop will recommend “pull” from their remote instead of “push —force-with-lease”.
reply