I self-host my blog on a server in my home. Instead of opening a port to my home network, I'm using Cloudflare Tunnel to expose the blog to the internet.
That's not really anonymity or privacy in all likelihood, though. Your residential IP is already anonymous. Knowing it tells me nothing other than your general region. The benefit there is that you don't need to have a static IP.
And besides, Cloudflare Tunnel is distinct from (though it integrates with) the cdn product.
It depends. The site is up, but now you're pumping 10x/100x the traffic. What are you scaling up?
Suddenly you're not blocking bots or malicious traffic. How many spam submissions or fake sales or other kinds of abuse are you dealing with? Is the rest of your organization ready to handle that?
Since sibling comments have pointed out the various ES5 methods and ES6 for-of loops, I'll note two things:
1. This isn't an effort to make all variables `const`. It's an effort to make all objects immutable. You can still reassign any variable, just not mutate objects on the heap (by default)
I don't think the benefits of immutability haven't been discovered in js. Immutable.js has existed for over a decade, and JavaScript itself has built in immutability features (seal, freeze). This is an effort to make vanilla Typescript have default immutable properties at compile time.
It doesn't make sense to say that. Other languages had it from the start, and it has been a success. Immutable.js is 10% as good as built-in immutability and 90% as painful. Seal/freeze,readonly, are tiny local fixes that again are good, but nothing like "default" immutability.
It's too late and you can't dismiss it as "been tried and didn't get traction".
That's not what I said, and that's not what my reply is about. The value of immutability is known. That's the point of this post. The author isn't a TC39 member (or at least I don't think they are). They're doing what they can with the tools they have.
Javascript DOES NOT in fact have built-in immutability similar to Clojure's immutable structures - those are shallow, runtime-enforced restrictions, while Clojure immutable structures provide deep, structural immutability. They are based on structural sharing and are very memory/performance efficient.
Default immutability in Clojure is pretty big deal idea. Rich Hickey spent around two years designing the language around them. They are not superficial runtime restrictions but are an essential part of the language's data model.
I didn't say that it does have exhaustive immutability support. I said the value of it is known. They wouldn't have added the (limited) support that they did if they didn't understand this. The community wouldn't have built innumerable tools for immutability if they didn't understand the benefits. And in any case, you can't just shove a whole different model of handling objects into a thirty year old language that didn't see any truly structural changes until ten years ago.
> I didn't say that it does have exhaustive immutability support
seal and freeze in js are not 'immutability'. You said what you said - "JavaScript itself has built in immutability features (seal, freeze)".
I corrected you, don't feel bad about it. It's totally fine to not to know some things and it's completely normal to be wrong on occasion. We are all here to learn, not to argue who's toy truck is better. Learning means going from state of not knowing to the state of TIL.
> you can't just shove a whole different model of handling objects into a thirty year old language
Clojurescript did. Like 14-15 years ago or so. And it's not so dramatically difficult to use. Far more simpler than Javascript, in fact.
I am not being pedantic, there's critical fundamental conceptual difference that has real implications for how people write and reason about code.
There's performance reasoning, different level of guarantees, and entirely different programming model.
When someone hears "JS has built-in immutability features", they might think, "great, why do I even need to look at Haskell, Elixir, Clojure, if I have all the FP features I need right here?". Conflating these concepts helps no one - it's like saying: "wearing a raincoat means you're waterproof". Okay, you're technically not 100% wrong, but it's so misleading that it becomes effectively wrong for anyone trying to understand the actual concept.
yeah, immutability.js is a solid engineering effort to retrofit immutability onto a mutable-first language. It works, but: it's never as ergonomic as language-native immutability and it just feels like you're swimming upstream against JS defaults. It's nowhere near Clojure's elegance. Clojure ecosystem assumes immutability everywhere and has more mature patterns built around it.
In Clojure, it just feels natural. In js - it feels like extra work. But for sure, if I'm not allowed to write in Clojurescript, immutability.js is a good compromise.
I meant to point out that of course there is value in immutability beyond shared datastructures.
I tried Immutability.js back in the day and hated it like any bolted-on solution.
Especially before Typescript, what happened is that you'd accidentally assign foo.bar = 42 when you should have set foo.set('bar', 42) and cause annoying bugs since it didn't update anything. You could never just use normal JS operations.
Really more trouble than it was worth.
And my issue with Clojure after using it five years is the immense amount of work it took to understand code without static typing. I remember following code with pencil and paper to figure out wtf was happening. And doing a bunch of research to see if it was intentional that, e.g. a user map might not have a :username key/val. Like does that represent a user in a certain state or is that a bug? Rinse and repeat.
> immense amount of work it took to understand code without static typing.
I've used it almost a decade - only felt that way briefly at the start. Idiomatic Clojure data passing is straightforward once you internalize the patterns. Data is transparent - a map is just a map - you can inspect it instantly, in place - no hidden state, no wrapping it in objects. When need some rigidity - Spec/Malli are great. A missing key in a map is such a rare problem for me, honestly, I think it's a design problem, you cannot blame dynamically-typed lang for it, and Clojure is dynamic for many good reasons. The language by default doesn't enforce rigor, so you must impose it yourself, and when you don't, you may get confused, but that's not the language flaw - it's the trade-off of dynamic typing. On the other hand, when I want to express something like "function must accept only prime numbers", I can't even do that in statically typed language without plucking my eyebrow. Static typing solves some problems but creates others. Dynamic typing eschews compile-time guarantees but grants you enormous runtime flexibility - trade-offs.
one thing that it's missing in JS to fully harness the benefits of immutability is some kind of equality semantics where two identical objects are treated the same
even when performance might not be an issue or an objective, there are other concerns about an user land implementation: lack of syntax is a bummer, and lack of support in the ecosystem is the other giant one - for example, can I use this as props for a React component?
yes, I'm aware of composites (and of the sad fate of Records and Tuples) and I'm hopeful they will improve things. One thing that I'm not getting from the spec is the behavior of the equality semantics in case a Date (or a Temporal object) is part of the object.
In other words, what is the result of Composite.equal(Composite({a: new Date(2025, 10, 19)}, Composite({a: new Date(2025, 10, 19)})? What is the result of Composite.equal(Composite({a: Temporal.PlainDate(2025, 10, 19)}, Composite({a: PlainDate(2025, 10, 19)})?
If I'm storing data on a NAS, and I keep backups on a tape, a simple hardware failure that causes zero downtime on S3 might take what, hours to recover? Days?
If my database server dies and I need to boot a new one, how long will that take? If I'm on RDS, maybe five minutes. If it's bare metal and I need to install software and load my data into it, perhaps an hour or more.
Being able to recover from failure isn't a premature optimization. "The site is down and customers are angry" is an inevitability. If you can't handle failure modes in a timely manner, you aren't handling failure modes. That's not an optimization, that's table stakes.
It's not about five nines, it's about four nines or even three nines.
Backups are point in time snapshots of data, often created daily and sometimes stored on tape.
It's primary usecase is giving admins the ability to e.g restore partial data via export and similar. It can theoretically also be used to restore after you had a full data loss, but that's beyond rare. Almost no company has had that issue.
This is generally not what's used in high availability contexts. Usually, companies have at least one replica DB which is in read only and only needs to be "activated" in case of crashes or other disasters.
With that setup you're already able to hit 5 nines, especially in the context of b2e companies that usually deduct scheduled downtimes via SLA
> With that setup you're already able to hit 5 nines
This is "five nines every year except that one year we had two freak hardware failures at the same time and the site was hard down for eighteen hours".
"Almost no company has this problem" well I must be one incredibly unlucky guy, because I've seen incidents of this shape at almost every company I've worked at.
It really cannot be understated how big of a deal this is. The tech here is impressive AND they're not trying to lock you in. Practically speaking it's the only VR headset that holds real-world appeal for the vast majority of gamers, because it plays the games they're already playing.
I agree the pricing is ridiculous, but to be fair, it's a different use case because automation tools like that are primarily geared for marketing teams and other non-technical users to connect different systems together. So you're mostly paying for the built-in integrations themselves rather than compute
I can imagine it doing fine on highways for a thousand miles. FSD has literally never managed to complete a trip involving city driving for me without disengaging or me having to stop it from doing something illegal. I'm not sure how many attempts I'm supposed to give it. Hell, autopilot doesn't even manage to consistently stay safely in a lane on I-40 between Durham and Asheville.
have you tried fsd 13/14 yet? I just upgraded to 13 from 12 and it's a massssive improvement. Not sure what 14 s like. It's definitely added a 9 in the last year.
I've heard this so many times it's starting to be a meme. The system was claimed to be very capable from the beginning, then every version was a massive improvement, and yet we're always still in very dangerous, and honestly underwhelming territory.
Teslas keep racking up straight line highway miles where every intervention probably counts at most as 1 mile deducted from the total in the stats. Have one cross a busy city without interventions or accidents like a normal human driver is expected to.
It was very capable, and each version has been a big improvement. The first time I rode in a Tesla with FSD back in 2017 I was shocked by how good it was. Self driving tech has advanced so fast that we forget it was considered next to impossible even 15 years ago. You are judging past tech by 2025 standards.
Novelty is enough to look like "shockingly good". You were comparing "no self driving" to "some self driving". A jump from 0 to something always seems big. Standard driver assists were also impressive when they appeared on cars. In the meantime Tesla still makes a lot of claims about safety but doesn't trust the FSD enough to publish transparent, verifiable stats. That speaks louder than any of our anecdotes.
> You are judging past tech by 2025 standards.
That's very presumptuous of you. Every single person I know driving a Tesla told me the FSD (not AP) is bad and they would never trust it to drive without very careful attention. I can tell Teslas on FSD in traffic by the erratic maneuvers that are corrected by the driver, and that's a bad thing.
> Every single person I know driving a Tesla told me the FSD (not AP) is bad
I really don't believe this because everyone I know who drives a Tesla tells me the opposite. I tend to think this is an artifact of people who just irrationally hate Tesla because IRL every negative thing I hear about Teslas comes from people who don't own the cars and hate Elon Musk.
> they would never trust it to drive without very careful attention
Of course, because the product is not designed to drive without human supervision.
> I can tell Teslas on FSD in traffic by the erratic maneuvers that are corrected by the driver, and that's a bad thing.
I don't believe you actually can because I don't notice any difference in the quality of driving between Tesla's or any other car on the road. (In fact the only difference I can notice between drivers of different cars is large trucks). So, again, I write off such statements as more of the same emotionally driven desire to see a pattern were there isn't one.
> this is an artifact of people who just irrationally hate Tesla
> more of the same emotionally driven desire to see a pattern
Don't you find it curious that every opinion you don't like must be from irrational people hating Tesla, but opinions you do like are all rational and objective? It's as if we didn't define the sunk cost fallacy for exactly this. You're a rational person, if Tesla was confident in the numbers wouldn't we have an avalanche of independently verifiable stats? Instead we're here playing this "nuh-uh" games with you pretending you're speaking with an authority nobody else has. Does any other company go to such lengths to bury the evidence of their success? The evidence that supports their claims?
And of course I can tell FSD drivers, literally nobody else on the street will so often brake hard with absolutely no reason, or veer abruptly then correct and straighten out so hard it wobbles, both on highways and in the city. If it's not the car then it must be the drivers but they wouldn't make such irrational moves.
P.S. The internet is full of video evidence of FSD making serious and unjustified mistakes. Every version brings new evidence. How do you explain those? Irrational haters inventing issues? Car misbehaving only for them? Because you see, even if you film 10 times and get the mistake only once it's still very serious.
Yeah, that's the type of feedback I absolutely do believe. Sounds like something someone would say about their car to me IRL. That's basically the standard I apply to internet comments.
For what it's worth, that was not my experience. 12 didn't fix all of the issues I'd heard about its predecessor. 13 didn't fix all the issues I experienced with 12. "Better" isn't enough, it needs to be so good that every issue with the previous generation is resolved. It's never been close to that.
I'm also sick of hearing "have you tried?" And also "it's really improving!"
Maybe the manufacturer should try the next version. And test it. And then try the next version. And test it. And then continue until they have something that actually works.
I tried 12 and 13. My car hasn't gotten 14 and I'm not interested in finding out if it'll get it, because at this point I'm simply not interested even if it's decent.
And there's no guarantee it'll be meaningfully better, if I'm being honest. Why would I believe that all the issues are fixed? For me to be interested, every single problem that I'd encountered needs to be resolved. Why would I even consider accepting anything less? It's not "partial" self driving. An incremental improvement is useless.
Meh. I do a lot of beta testing, and enjoy it. I think it's fun to watch the evolution of this tech over the last seven or eight years. But you don't have to feel that way.
Has everyone else you encounter on the road agreed to participate in your beta testing?
That's the crux of it, and where traffic education mostly fails in the USA: the lack of consideration that the road is about safety for all users involved, the notion you are operating dangerous machinery around other people.
The Tesla on fsd13 is considerably more courteous and safer than at least the bottom quintile of drivers. It’s much safer than my teenage drivers were in my family. Failure modes in city driving tend to be stopping, not plowing through pedestrians
I own six EVs (three cars, one of which is a Tesla, and three motorcycles). My first EV was my Tesla.
We're on the cusp of trading the Tesla in for a Rivian most likely. I should be Tesla's target customer, but instead I'm exactly who you described:
- I don't like the brand. I don't like Elon. I don't like the reputation that the car attaches to me.
- I don't trust the technology. I've gotten two FSD trials, both scared the shit out of me, and I'll never try it again.
- I don't see any compelling developments with Tesla that make me want to buy another. Almost nothing has changed or gotten better in any way that affects me in the last four years.
They should be panicking. The Cybertruck could have been cool, but they managed to turn it into an embarrassment. There are so many alternatives now that are really quite good, and Tesla has spent the last half a decade diddling around with nonsense like the robot and the semi and the Cybertruck and the vaporware roadster instead of making cars for real people that love cars.
The astonishing thing is that they haven't released a new car in six years and _do not appear to have one in the works_ (unless you count the Model Y facelift, but really that's pushing it). I think that's pretty much unheard of for an active car manufacturer over the last few decades.
Like, what are they _doing_? Do they still have R&D at all?
The other thing is various other companies built pretty much what Tesla was promising like the Rimac Nevera and the Yangwany U9, showing it was quite doable if Tesla had put some enthusiastic engineers on it and said go do it?
Their ~mission was cheap cars for masses. There are plenty of high end EVs out there. It's nuts when smart people compare 7 year old 35k Tesla to a brand new 80k Polestar or 100k Lucid.
> instead of making cars for real people that love cars.
Whoosh. They've been saying Tesla is an AI company for nearly a decade. AI has been propping up entire US economy for last few years. EV bandwagon has left long time ago.
Saying all that I wouldn't mind even cheaper Tesla - small screen, 1 camera instead of 11, fully offline, fully stainless steel, fully open source - basically minimally tech and maximally maintainable and maximum longevity.
They make cars that mostly do their job. They don't make AI that does its job. They're not an AI company, they're a car company pretending they're not a car company.
> Saying all that I wouldn't mind even cheaper Tesla - small screen, 1 camera instead of 11, fully offline, fully stainless steel, fully open source - basically minimally tech and maximally maintainable and maximum longevity.
What you describe would probably cost more money, not less. The market is small and analog tech is actually more expensive to produce with than digital tech.
> basically minimally tech and maximally maintainable and maximum longevity.
Kind of implies it.
Tech is used to lower prices, not raise them, if you want minimize tech, and you want to make it as maintainable by end user or relatively cheap mechanics, and you want it to last as long as possible, that is going to cost a lot. Or you basically want a Lada Laika, the old ones, that could be repaired super easily. Anything with microchips is going to suffer if those chips die, and they aren't going to be easy to repair.
> Anything with microchips is going to suffer if those chips die, and they aren't going to be easy to repair.
AFAIK Tesla is already moving towards that direction with unboxed manufacturing - it's where same chip can be either window controller or brake controller. Having single chip + open source firmware would eliminate this issue.
I'm sure they would be if the stock price had ever showed any signs of being based in reality.
But for now Elon can keep having SpaceX and xAI buy up all the unsold Teslas to make number go up.
If that ever stops working, just spin up a new company with a hyper-inflated valuation and have it acquire Tesla at some made up number. Worked for him once, why not try it again.
And at this point he can get even fraudier, with the worst possible realistic outcome being that he might get forced to pay a relatively small bribe and publicly humiliate himself for Trump a bit.
But there's really no more consequences to any sort of business fraud (for now) as long as you can afford the tribute.
The flashes signify actual changes. It's a secondary signal to resume paying attention to the page.
What I truly hate are animated skeleton boxes or element level spinners. Why are you trying to hold my attention on something that's not even loaded yet? We all understand the UI paradigm and implicitly understand network delay, you don't need "comfort animations" to keep me happy. I'd rather use the time to look at any of the other tabs or applications across my screens. Then the flash of content actually means something.
The point of skeleton loaders is to prevent the page from jumping around furiously, which would force the user to re-parse the layout (possibly) multiple times.
In my experience it's just amateur UI design that causes this. Your display areas shouldn't change size unless the browser changes size. There should be nothing that is "content fitted." That's a historical mistake of early HTML but it's something easily overcome. You really do have to get the HTML+CSS to work like a desktop app before you layout your SPA.
Worse still, applications like microsoft outlook on the web, use the skeleton boxes with comfort animations. What they don't do is pre layout their icons. And different icons will appear in different contexts. I often get the case where I aim for one icon, something will load in, create a new icon, and push my intended target out of the click.
Skeleton loaders are a bad kludge over an initially ignored problem.
The loading state is indistinguishable from the page crashing. Did the JavaScript fail, or is the connection just slow?
> animated skeleton boxes or element level spinners
Good news! Browsers have low motion settings. Any programmer worth their salt will respect this and the skeletons won't be animated.
> Then the flash of content actually means something.
On the contrary, if the content is loaded in multiple parts (in my own application, I split the loading into multiple requests: one is cacheable across multiple pages, one is cheap, one is expensive), you either need to not render anything until everything is loaded (bad: the user can't interact with the parts that loaded first), or the page jumps around as content loads in. Skeletons fix this. UI elements in the middle don't end up being 0px tall and moving the stuff below them around nearly as much. How annoying is it to nearly click on something and the page jumps violently and you mis-click?
It honestly sounds like you just don't like lazy programming. That's very fair. Skeletons done right just mean the page is the correct layout while they're partially loaded. Without that, the content is literally unusable (you can't read it interact with things that are jumping all over the place).
Which is fine. Nothingness, or a generic spinner actually don't lie to me.
Skeletons lie by making an impression that the data is just about ready. So there's this failure mode where data is NOT ready because of a slow app/network, and I end up staring at a fake. Even worse, sometimes skeletons also break scrolling, so you end up even more frustrated because your controls don't work.
Again, I don't see any upsides for me compared to a blank page. Skeletons in the best case just show a useless intermediate state, and in the worst case just force me to pay attention to a non-functional page for an indefinite amount of time.
A blank page does not try to keep grabbing my attention.
Skeletons also have a toxic effect on web developers by letting them get sloppier.
I have never heard this before. Anonymity from what? From people knowing your Hetzner ip? I don't know what you're keeping private.