Worked well for me. I use the excellent stremio extensively and it shows.

In fact, I pay for netflix, and I use stremio to watch netflix shows because netflix UI sucks so much.

Tells you something about pirating and convenience, hey?

Got a few invites, DM me on twitter, substack or masto if you want them (listing on https://bitecode.dev)

Also they don't have to die.

That's why I have 2 bank accounts.

It happened to me once in Africa, and I said "never again".

I now have a backup plan for everything that is critical for my life.

I have several modes of transportation, several clients, 2 computers, 2 sources of internet, several ways of contacting my family, etc.

System always fail.

When something similar happened with an immigrant co-worker in the UK, I quickly picked up a second bank account.

He got stuck for about a week and a half with his money all locked up in an account he couldn't access. It was early enough in the month that rent and bills etc. wasn't an issue, we just ended up helping him out buying food for a few days while he sorted out another account and got an advance on his salary.

I remember the range of excuses and explanations for delays from the bank left us all gobsmacked.

I've considered doing this for some time now. Do you have any sort of link between the two accounts? Maybe not directly, but e.g. are both connected to the same brokerage or anything? Is one online-only or do both have physical locations somewhere?

One is online only (the one I use the most), the other one is a completely different bank with very different objectives and clients plus physical offices everywhere.

Each account can send money to the other via wiring, but that's it.

Saved my ass several times already when I lost my credit cards or other unpleasant situations.

If the AI is accessible to the rest of the world, it's not a problem: the model can query its knowledge and answer in any language since it already is very good at translating things.

The problem is rather than, given the economic war between the US and China, the chip ban, the taiwan issues and the GFC, we may not have access to this.

+1

And I mind that paying forces me to give my credit card to a companies that have proven to work against me.

I mind that google will take over my entire phone if I connect to any service with a google account because I paid for it and not just login to that single service.

I mind that it will collect all that data if I don't have an adblocker anyway, just not show me ad, and then give it to gov entities (see PRISM).

What I don't mind is paying. I pay for spotify, for neflix, for dynalist, for kagi, for chatgpt, for codepilot, for github...

But I do mind that many people like you on HN accuses us of being dishonest.

Now imagine nuitka and gcc bundled as a standalone cross plateform binary so you can basically compile a cross plaform python exe from any script.

If google could just take our money and give us videos in exchange yes.

But unfortunately, they still suck all your data and sell it to third parties.

It's even worse if you pay, because if you sign in into your youtube account on the offical app, your entire phone is now linked to your a account even if you didn't link it before, with all the data in it. If you are not careful, your entire agenda and calendar immediatly exfiltrate.

Plus google gets your credit card, which means it will now link orders and data from other services using the same card number with its partners and get even more data.

After paying of course, you still can get your accounts locked out for obscure reasons with no appeal, and despite being a customer, have zero service support.

Google is not a respectful company.

And given what we know about the PRISM program, centralizing all this data in there is not good for democracy either.

> But unfortunately, they still suck all your data and sell it to third parties.

They don't sell your data to third parties, they do advertising for third parties on their data.

I can't believe people on HN are still confused by this concept.

Thanks. This is exactly what I think every time someone says "just buy premium". There's a reason I don't have a Google account.

And even if you do have a Google account, you might not want to log into YouTube with it; for instance, I recall reading that logging into YouTube with your Google account required you to put your real name into it, and if for some reason Google decided that your real name isn't your real name, you could lose access to your whole Google account, including more important services like Gmail and Google Talk.

Something like this:

    <button
        hx-delete="/car/{{car['id']}}"
        hx-swap="delete"
        hx-target="closest .carcontainer"
    >Delete this car</button>

When you come to HTMX, it's normal to wonder about those kind of things, especially if you have being learning web dev post JSON era.

If this is your case, I'm writing a series of 5 tutorials on HTMX with this in mind:

https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1

This is approaching the code size of the vanilla js version. And it does not have the confirmation modal.

If there would be additional computational logic involved (say calculating how many rides this car has done this year so far to say "Really delete this car? It delivered 124 rides this year.") - would you also cram all of that into the button element?

What I am trying to say: I don't see which real world use cases are tackled by htmx. I usually don't have a use case as simple as "When element X is clicked, load url Y and replace element Z with it".

Sure, but you've gotten rid of a shit-ton of complexity from your stack. No REST+JSON api/graphql. No frontend SPA. The templating system you use can call your db layer directly (or go through an intermediary layer if that's your preference). You solve the "single language" problem, with the backend being favored (rather than the "use npm on the backend because the browser speaks js/ts" approach of the last 10 years). Performance is kept reasonable because you're swapping out elements mainly rather than rerendering the whole page (i.e. it's not a return to servlets/cgi).

The HTMX-oriented response would be, if you anticipate needing to know how many rides a car has completed, why not calculate that on the server or in the database, as opposed to in real-time on the client (in which case, presumably, you need to deliver a LOT more data to the client, such as a full list of all rides so you can calculate those which this one car was involved in).

> I don't see which real world use cases are tackled by htmx

Because you are prioritizing state on the client. Free yourself of that, and the use cases for HTMX start expanding enormously.

I would say, yes, in this case if you count your html for the button + the ajax request you would need to do to notify the server HTMX is shorter.

But, let's talk about the confirm. For a simple one, you would use hx-confirm and be done.

However, for a more complex confirm, you would make a delete request that would answer HTML.

The HTML would be showing the confirmation with the data calculated from the server (124 rides this year).

The response doesn't have to be a button, the server can answer a modal or a new subpage, which would contain a hx-delete with a "userconfirm=1" in qs and a cancel button to go back.

You don't have to limit yourself to replace the current element with the response, and the response is not limited to basic workflow.

Also HTMX is mostly about using hypermedia to communicate and favor the server to manage the state, but there is nothing saying you can't use JS.

You can even be naughty and have new HTML responses inject new JS in the page.

From an htmx perspective, you would probably calculate things like that on the server. So the row delete button might have an hx-get="<delete-confirm-url>" that returns an HTML snippet with your modal content ("Really delete this car?") and then the button in that modal would have hx-delete="<delete-url>".

Of course you can still add vanilla JS with htmx, and/or send the car.rides_delivered value from your model as part of the initial page load, etc. You don't have to do everything with the hx- attributes.

In my opinion htmx is excellent when you have a state that can be easily managed on the server, because it makes it simple to get an interactive SPA feel while still keeping state on the server. I think a lot of the htmx fan base would argue that most web apps don't need to manage their state client-side and therefore don't need all the overhead of React, etc. But of course htmx isn't a cure-all.

You can check out the writing on htmx.org if you're curious to hear more of the author's perspective and goals.

> This is approaching the code size of the vanilla js version.

Code size isn't everything. The htmx version is more restricted, consistent and declarative. Assuming you get familiar with htmx, if you come back to both code snippets in 6 months, which one will you able to figure out faster?

I would love that. Makes more money for us since we can now build competitive service more easily.