> I wouldn't trade Spotify for it, but I'd still be sad to see it go.
Compared to that. Or listening to any Youtube or podcast instead of listening to the radio station hosts prattle on instead of playing the next track.
Nostalgia for radio is like nostalgia for the winter I worked at a cozy cafe at age 17: I have some good memories and every once in a while when I'm stressed at work I yearn for those simpler times... but there's a reason why I will never go back. No need to glorify it just because of some fading attachment to the yesteryears.
Of course you're free to listen to whatever you want, but I'm still happy to tune in to my old home town/country radio station every once in a while (when visiting or via streaming), and I still find their programming quite enjoyable. So it's not abstract nostalgia to me.
The reason why there's churn in the web ecosystem isn't because Javascript is missing some minor syntax changes that Python has. It's because UI development is a constant workshop for discovering better abstractions, particularly in bridging the gap between server and client-side code in the browser.
Personally, I think the real problem with the web ecosystem is HTML. HTML is for printed documents as web "pages," literally. It even has <figure> which is for "fig. 1" kind of things.
HTML is so bad that we NEED Javascript because CSS isn't enough. For example, there is no way to define a layout in HTML for different screen sizes and then SEPARATELY define the content of that layout. Nor is there a way to define in HTML that a div should jump from one part of the screen to another if there isn't enough space. We spent years telling the lie that we're supposed to split semantics and presentation, but in reality CSS simply doesn't provide enough power to actually ignore the structure, since you can't tell div1 to align itself to div2 if div2 isn't an ancestor or sibling of div1. Now every website looks extremely simple because if they made it even a tiny bit more complicated it would be impossible to make the flexboxes wrap right with just CSS.
Well, we "need" Javascript because it provides programming capabilities that HTML, being a markup language, cannot provide on its own. HTML is just the substrate for representing the UI.
All you would be doing is creating another programming language while taking another swing at coming up with yet another abstraction for UI dev like everyone before you.
Not really HTML2. Almost all current UI engines uses an xml variant, and they have a much lower number of components and a simpler foundation. And they provide you with a easy-to-use 2d context when you need to do custom components. What we need are better primitives for web applications. And separated from the web as documents.
data-star isn't a successor to htmx, it's a pretty different take on hypermedia, using SSE for a streaming, dynamic hypermedia driven system. cool, definitely capable, but significantly different
htmx generalizes hypermedia controls, and that's all it will do, forever
I've seen similar comments about that scene over the years but I don't get it.
How is it naive?
It's clearly creative license to be more interesting and provocative. They could have just made his eyes glow and stuff happen on screen, but that wouldn't have been as cool.
This is not an example of the "rule of cool", there's a human and technological point that is made by this scene.
However, because the movie drops most of the context from the original work, it is only something visually striking and impressive for most people.
In-universe, this is considered almost nonsensical technology (for the obvious reasons that are invoked here).
It doesn't really matter what it's an example of nor what the real motivation was. Your emphasis that it's deliberate only supports my point that it's not a naive vision of future HCI from the 90s.
Yeah I think that kind of thing isn't supposed to be "predictive". The "rules" in series aren't very clear, sometimes they type stuff out into a keyboard, sometimes they connect a cable from their head, sometimes they just pass stuff around/hack basically just just "telepathically" without even needing the wire, they do whatever seems cool for a scene. I think the "splitting fingers" thing happens in one of the movies but also in SAC, but I think the point is just that it looks interesting and seeing the fingers do that and start suddenly typing quickly gives a sense of tension/urgency that you wouldn't get if it was just the character sitting back and staring at the screen (even if "in universe" they're able to work just as effectively that way)
Agreed the main reason is the point of the show is to be entertaining and visually interesting, and that is entertaining and visually interesting. Why do the robots look like spiders without any of the features of spiders that would actually be useful in a robot but look scary instead of cute to humans? It's not because it's a naive idea of what robots would look like.
But even aside from the fact that visual style outweghs realism in this work, it's not weird or remarkable anyway.
The robot has to type sometimes for the same reason you sometimes have to manually type a password into a keypad or your food order into a pos terminal even though you have a password manager in a phone with a dozen kinds of connectivity in it. None of your dozen forms of connectivity is compatible or available with any of the terminals dozen forms of connectivity. Even if you both have something the same plug, it doesn't mean you can use it.
You may also choose to do your "adversarial interfacing" the manual way even if you had a direct option available and even if you desperately wanted speed, simply for safety.
How do you write a singleton service that can feed state back into the component that calls it when that state changes?
For example, `api.fetchInfo()` would want to feed Loading | Success(T) | Error(E) back into the React component call-site when they change.
EventEmitters come to mind but aren't without their own issues like subscription leaks. And you have to track component arguments in order to know when to call the service again when they change which is a classic source of complexity.
Hooks provide a solution for this since they themselves are just nested React lifecycle constructs (like useState + useEffect).
In class components you just could await the result and perform a set state, and that would be it. Easy as pie.
But now in function components when everything is called all the time without your control you have to use escape hatches like use effect just to work around react.
Hooks let you wrap all sorts of logic (and other hooks) and return values that rerender the callsite component when changed. Just keep adding on to my hook example and you get more and more code that you need to repeat in every class component that uses it.
Of course, the class component solution to this was to use an HOC, but that had its own issues like complex data flow and wrapper hell.
Hooks solve problems of composition without Yet Another Wrapper and they give clearer data flow, better ref forwarding, etc.
It's easy to see complicated useEffect spam and blame hooks but frankly that wasn't any better when it was happening at different layers of HOCs.
You can just use a service instead, expose public methods and hide private while keep expending and refactoring the internal logic. The same way it’s been done for decades. The only problem is the one that react created for itself in function components which is when to refresh the render from the state.
Interactive UI development just isn't easy nor simple regardless of the platform and framework.
A tool like React can shrink the space you need to be vigilant about to ensure performance (not just speed but also UX), but you still need vigilance and attention to detail to make sure you're not making mistakes like running something on every re-render that you meant to do just once.
And it has its own idiosyncrasies that you need to be vigilant about. Like if you write a hook `const x = useMyHook({ optionA, optionB })` then you need to handle the cases (either at the call site or inside the hook) where the options object is new one every render and when optionA or optionB are non-primitives that change every render.
The problem is that it doesn’t do anything. Maybe you slightly slow down a volumetric spam attack, but you’re just putting a sleep() before letting spam through which might be the worst solution.
As for economic viability, it’s still just a sleep(). Even if it somehow did cost extra money to use more of the CPU, botnets don’t even use their own hardware.
And if you make the PoW so hard that it takes very very long to solve then you basically made a captcha that bots have no problem doing (it’s just time) and humans don’t want to do at all especially on their phone.
Same here, Envy is my main apple (I typically eat 2 apples a day, one each for morning and afternoon snack). ~80% of the time Envy apples blow my socks off, Maybe 2% of the time they're just ok. I'll get a SweeTango or Cosmic Crisp if Envy are not available, but I've just never had one that I thought was better than Envy.
I went through a big Honeycrisp phase and really enjoy them, but I have thin enamel on my teeth and frequent eating of uncooked Honeycrisp leads me to a lot of tooth pain, they're just a little too tart. They are my go-to baking apple though.
Presumably, anyone who regularly uses 4chan would register. Once you register and click the login link in your email, you just get the easy Cloudflare captcha and no countdown.
The horrible captcha + 300s countdown is for completely unauthed users. Most sites don't even allow unauthed users to post at all.
Compared to that. Or listening to any Youtube or podcast instead of listening to the radio station hosts prattle on instead of playing the next track.
Nostalgia for radio is like nostalgia for the winter I worked at a cozy cafe at age 17: I have some good memories and every once in a while when I'm stressed at work I yearn for those simpler times... but there's a reason why I will never go back. No need to glorify it just because of some fading attachment to the yesteryears.
reply