It is a bit an "elitist" comment in the beginning of the thread. The original comment can easily be interpreted (whether it was intended like that or not ...) as "there's no problem, I'm not affected, easy to avoid" to which the GP reacted "well, yeah, good for you, but other less tach davy people won't do" to which I would append "and they shouldn't have to. We should try to get such traps out of the net. Joe Average should be able to use the net in a productive and safe way"
It's an ageist way of saying that this exploit is less critical for people who take proactive counter-measures, and more affects less technically inclined or security-minded people.
It’s very easy to be nice. For example by saying that you shouldn’t just think about yourself, but also your parents and grandparents.
What isn’t nice is then to say that that is an ageist thing to say. Even though it is a perfectly valid thing to point out real people who are affected by certain online threats.
You misunderstand: it's ageist to suggest that parents and grandparents are by definition not likely to be technical enough to use mitigations like containers and such.
The commenter said "your" parents and grandparents, who are by definition one and two generations older than "you", in age. I can't think of any other reason to invoke "your" parents and grandparents.
If the point is that it's unhelpful to make irrelevant assumptions about parents and grandparents, then this is in complete agreement with the parent's point and is not a critique of it.
I think you misunderstand. Ageism is about discriminating on the basis of someone’s age.
The original comment was about grandparents and parents neither of which you need to have a certain age to be one. Assuming that it IS about age is in turn actually ageist because you are signaling that people should be parents at a certain point in their life.
To be clear, I don’t think your intentions are wrong: you are just trying to right a perceived wrong. I am just asking you to grant others a more favourable interpretation of their intentions as well. I do this by pointing out that your well intended call out of ageism is in turn also interpretable as something unwoke.
Hence arms race. There is always someone who can be more politically correct.
What is the point of this conversation? We're sanitizing language to protect the egos of everyone, at the expense of derailing a conversation that actually could relate to a lot of people here.
My parents are NOT AT ALL technically savvy. My mother's web browser has a ton of bullshit addons all over it, or at least it did last time I looked at her computer in 2014-ish. I can't imagine she's gotten much better about this stuff. But we can't talk about this pattern because it could hurt the identity of older HN readers who are technically savvy, it's offensive.
Ageism is bad when it's preventing people from getting work or engaging in society in a meaningful way. I simply do not care if it's used to make casual remarks with the specific intent of getting people to relate to an idea, e.g. people who don't know any better about privacy are actually people you know, most likely your parents or grandparents or some of their friends. And taking part in shutting down that conversation because of "ageism" is, IMO, worse than the ageism itself.
> How do you think you get the sort of ageism that prevents older people from getting the job?
I think you get it from a multitude of reasons, including allowing interviewers to come up with bad faith assessments on culture fit and other un-quantifiable employment parameters that amount to nothing more than, "I liked or disliked the candidate." I'd even extend that logic to a larger cause, allowing coworkers (i.e. same level individual contributors) to interview candidates, as I don't think coworkers necessarily have the proper skills or incentives to neutrally evaluate future coworkers, especially not beyond, "I like this person because I can relate to them because we look the same, have the same interests, etc." This isn't strictly ageism either, it can affect people by class or race or other things that set them apart.
HN readers' parents are likely far more technically inclined than an average person.
(The commenter did not invoke their own parents, which might be a slightly more reasonable position)
Making a claim that HN's parents must be technically incompetent adds nothing to the thread, is likely to cause momentary confusion, and only contributes to the "bad" ageism that you are concerned about.
"We never thought it would happen, but in 2024, the year of our lord, it did. It seems that governments are requiring full access to iPhones and using features in ways we didn't think possible. People are now using infrared broadcasting, attached to weapons, government vehicles and buildings, to prevent taking photos near protests and riots. This is the first time it's happened that we know of, and we are scared of the precedent. Over 4,150 people died in a protest in the [redacted African country] at the hands of newly 'elected' military regime, and we have no digital evidence of it, except for the older analog cameras that some people still possessed."
"The software, which was created by Clearview Al, was criticized for its heavy reliance on billions of social media photos to identify criminal suspects."
So how exactly did they get access to all photos? It must have been trained on public networks like instagram, not facebook, right?!? If it was FB that would be interesting.
> "Facebook notably has not sent a formal cease-and-desist letter but claims to have sent other letters to Clearview to request more detail on its practices and then eventually “demanded” that it stop scraping user data. Peter Thiel, a venture capitalist and notable surveillance enthusiast who sits on Facebook’s board of directors, invested $200,000 in Clearview’s first round of funding."
What do you call it when you mistake "I know OF x" for "I understand X". I used to do it all the time; I think that because I have heard of something, I somehow know how it works or how to use it. For me, it's kind of like going "Oh, I've seen that meme before!" and somehow going meme++ in your head, so of course I am 'more familiar with it', but I am doing that for advanced topics I have no demonstrated practice in. I am much better now at realizing my incompetence, but I wish it could be studied in more detail, instead of people just looking at someone who is demonstrating confident incompetence and going "Dunning-Kruger?" "Dunning-Kruger!".
> How does Hotwire compare to Phoenix LiveView? It seems the same to me.
It's much different based on a preliminary reading of Hotwire's docs.
Live View uses websockets for everything. If you want to update a tiny text label in some HTML, it uses websockets to push the diff of the content that changed. However you could use LV in a way that replaces Hotwire Turbo Drive, which is aimed at page transitions, such as going from a blog index page to contact form. This way you get the benefits of not having to re-parse the <head> along with all of your CSS / JS. However LV will send those massive diffs over websockets.
Hotwire Turbo Drive replaces Tubolinks 5, and it uses HTTP to transfer the content. It also has new functionality (Hotwire Turbo Frames) to do partial page updates too instead of swapping the whole body like Turbolinks 5 used to do. Websockets is only used when you want to broadcast the changes to everyone connected and that's where Hotwire Turbo Streams comes in.
IMO that is a much better approach than Live View, because now only websockets get used for broadcast-like actions instead of using it to render your entire page of content if you're using LV to handle page transitions. IMO the trade off of throwing away everything we know and can leverage from HTTP to "websocket all the things" isn't one worth making. Websockets should be used when they need to, which is exactly what Hotwire does.
I could be wrong of course but after reading the docs I'm about 95% sure that is an accurate assessment. If I'm wrong please correct me!
> Fwiw, you can use long polling for LiveView if you wanted.
How does that work for page transitions? The docs don't mention anything about this or how to configure it.
With Turbolinks or Hotwire Turbo Drive, the user clicks the link to initiate a page transition and then the body of the page is swapped with the new content being served over HTTP. With Turbo Frames the same thing happens except it's only a designated area of the page. In both cases there's no need to poll because the user controls the manual trigger of that event.
How would LV do the same thing over HTTP? Everything about LV in the docs mentions it's pretty much all-in with websockets.
Then there's progressive enhancement too as another difference. Turbo is set up out of the box to use controllers which means you really only need to add a tiny amount of code (2-3 lines) to handle the enhanced experience alongside your non-enhanced experience. For example you could have a destroy action remove an item from the dom when enhanced using Turbo Stream or just redirect back to the index page (or whatever) for the non-enhanced version.
But with LV wouldn't you need to create both a LV and a regular controller? That's a huge amount of code duplication.
Although to be fair I would imagine most apps would require JavaScript to function so that one is kind of a non-issue for most apps, but it's still more true to the web to support progressive enhancement and the easier you can do this the better.
> But with LV wouldn't you need to create both a LV and a regular controller? That's a huge amount of code duplication.
You just do LiveView instead of a regular controller. No duplication.
When you request a page, it is render on the server and all of the HTML is returned over HTTP as usual.
After the client has received the HTML updates, live updates can go over a websocket. For instance you start typing in a search field, this is sent to the server over websockets. Then the server might have a template for that page that adds search suggestions in a list under that search field. The server basically automatically figures out how the page should be rendered on the server side with the suggestions showing. By "re-rendering" the template with changed data used with the server side template. Then it sends back a diff to the client over websockets. The diff adds/changes the search suggestions to the page. The diff is very small and it's all very fast.
> You just do LiveView instead of a regular controller. No duplication.
Yes but this is only in the happy case when the client is fully enhanced no?
What happens if you hook up a phx click event to increment a like counter.
After the page is loaded, if you click the + to increment it while having JavaScript disabled it's not going to do anything right?
But with Hotwire Turbo, if you have a degraded client with no JS, clicking the + would result in a full page reload and the increment would still happen. That's progressive enhancement. It works because it's a regular link and if no JS intercepts it, it continues through as a normal HTTP request.
Yes, the `phx-click` doesn't automatically get translated to a link or form submission. You can still design the page to work without javascript. For instance by having a "+" button be a normal form or link and then have phx-click intercept it when javascript is enabled. This can be done with one LiveView module without having to also have a separate regular controller.
One way to do it would be to in the `mount` function handle normal non-javascript params being sent and a `handle_event` function handle `phx-click`.
I don't know if there is already a way to have `phx-click` with fallback to HTTP in a less "manual" way. It should be possible to make.
I've found that the vast majority of clicky stuff I do leads to a URL change anyways, and these are just proper links to the new URL that LV then intercepts.
In your Counter example, it's true that for the 'degraded' version to work, the link would have to be a proper link and not a phx-click. But in the (IMO very unlikely) case where this fallback is necessary, solving it with a proper link/route does not require duplication, just a different approach.
What you would do is create a LiveView that handles both the initial page and the 'increment' route. If LV is 'on', it intercepts the click and patches the page. if LV is 'off', your browser would request the 'increment' route, and the same LV would handle all this server-side and still display the new, incremented counter.
The LV is both the server-side controller /and/ the client-side logic. That's part of what makes it so appealing, but, admittedly, also something that can take a while to wrap your head around.
I've more than once reflexively gone for phx-click solutions where the LV would receive the event and 'do' something, only to later realize that it would be much better to use a proper url/routing solution (where LV is still the 'controller'). In hindsight it's often a case of treating LiveView too much like just 'React on the server', basically.
It uses long polling over http. To be clear it's not restful http, but it's not websockets. I believe that Chris doesn't believe it's important for most people so there are no directions right now. Could be wrong there, I'm not Chris.
Page changes are still initiated by the client in LiveView (although can be server initiated)
LiveView is just channels under the hood. Once you consider that, long polling may seem more obvious
Since LiveView is built on phoenix channels, it's the same story. Simply pass the `transport: LongPoll` option to the LiveSocket constructor and you're now using long polling with LV :)
> LiveView is just channels under the hood. Once you consider that, long polling may seem more obvious
It's not obvious to me for user invoked page transitions because when I think of long polling, I think of an automated time based mechanism that's responsible for making the request, not the user. But a page transition is invoked by the user at an undetermined amount of time / interval (it might happen 2 seconds after they load the page or 10 minutes).
Your idea of "long polling" sounds more like periodic polling (repeated requests within a frequency), though that's not what long polling is or how it works.
> Your idea of "long polling" sounds more like periodic polling (repeated requests within a frequency), though that's not what long polling is or how it works.
Right isn't long polling keeping the connection open for every client on the server and then the server is doing interval based loops in the background until it gets a request from the client or times out?
It wouldn't be doing a separate HTTP request every N seconds with setInverval like the "other" type of polling but it's still doing quite a bit of work on the server.
In either case, LV's long polling is much different than keeping no connection open, no state on the server and only intercepting link clicks as they happen for Turbo Drive and Turbo Frames.
I don't think that's necessarily a big deal with Elixir (I wouldn't not pick it due to this alone, etc.), but this thread is more about the differences between Hotwire and LV, and no state being saved on the server for each connection is a pretty big difference for the Drive and Frames aspects of Turbo.
The only way to justify the valuation of Tesla is to assume that they do something that doesn't depend on individual customer sales, because those aren't ramping up at the right rate. I think they are about to launch an autonomous taxi service.
Here is a good example of Elon Musk talking about how robotaxis are going to push up the price[0]. So far nobody has talked about Tesla operating their own robotaxi service.
Anyone who thinks they are going to use their private car as a robotaxi doesn't understand how much they're going to spend on maintenance and insurance.
EVs may cost less to maintain their ICEs, but they still have moving parts that need to be replaced.
And taxi insurance is quite expensive; it's one of the reasons that driving for Uber/Lyft is a losing proposition for most of their drivers even before they take vehicle wear-and-tear into account. For autonomous driving, for a company with the worst safety record for AI-driving in the industry, that insurance may cost more than their combined insurance costs for everything else combined (i.e., house, healthcare, other cars, etc.).
Their strategy hasn't been L5 at all, and they can't have invested in it so secretly that even those in the AV space (like me) wouldn't know about it, through talent exchange at the very least. AV is a pretty small world at the moment.
