foxygen

> the most compelling reasons to use HTMX instead (for building dynamic/interactive web applications) are to reduce the amount of JavaScript sent to the client and make pages become interactive faster

Next.js and TanStack Start don't send any JavaScript to the client if you decide to server-render everything. The upside is that you can opt-in into client-side components, and have all the interactivity benefits of React. I understand using HTMX if you are building a backend in Go/Python/..., but if you are already using Node, I see no reason not to use TanStack Start instead.

I don't see how HTMX has anything to do with UX. Could you clarify what you mean?

What is the point of using HTMX if your backend is JavaScript(Hono)?

Can you show me some examples that are hard to implement in Tailwind? I've been using Tailwind for an app with a somewhat complex UI for the past ~2 years, and it works great most of the time. Sometimes it doesn't, but then I write some CSS. Tailwind doesn't stop me from doing so.

I don’t know about Shadcn, but how does Tailaind hampers your ability to do anything?

It could, right? But let me tell you a secret: Apple doesn't want PWAs/web apps and actively limits Safari to force developers to build apps.

Because they are not the same as Go-style green threads/coroutines?

Because you are have an existing app in Python. Because you need some library that is not available in Go. Because you prefer Python. All are valid reasons.

The US did not create a neutral global free market. It created and maintains a US-centered international order that is relatively open for trade when openness aligns with American strategic interests and becomes coercive when it does not.

> Providing a stable currency is legit

The US does not "provide" a stable currency, it outright forces everyone to use it.

> how enforcing your ideals often comes into conflict with the values of your ideals themselves

The US/NATO couldn't care less about enforcing their "ideals". This is all about economic gain. It is very odd how liberal ideals must be enforced upon Iran, but not upon Saudi Arabia, which is a US ally, no?

> but that is another conversation, not for this thread

So discussing the use of force in the global economy is not fit for a thread about free-trade?

Are we pretending the US/NATO hasn't been interfering with the world's economy for the past decades? Or free trade here means the US being the sheriff of the world, forcing everyone else to use their currency, and bringing "freedom and democracy" to whoever thinks of challenging that?

Your first comment assumed I was "speed-running to a conclusion and squinting too hard", and this was "similar to the weird childish name-calling". I think that is in the same area(or worse) than saying "Amazing how X didn't even cross your mind". And sorry, but invoking that you have experience with X, Y, Z and thus your opinion is informed after criticizing some technology IS an appeal to authority.

> If you don't intend to discuss out of position of curiosity

I'm not the one making sweeping statements on the superiority of one piece of technology. Reading your other response, I think you are the one who have little to no curiosity in understanding how you might be wrong.

> That being said, has Akka started making full use of JVM's new green threads? Has Java itself started introducing immutability and STM / share-nothing as first-class citizens?

Amazing how it doesn't even cross your mind that there are trade-offs to those choices. Green threads are awesome, but guess what, they come at a cost. Same for share-nothing semantics.

> Has anybody rolled up their sleeves and said "Alright, BEAM VM's reign is over, I am making the same or better runtime as them in Java / Clojure!"?

You are again presupposing the BEAM has an absolute superiority over the JVM. "Better runtime" makes no sense on its own. Better is always relative to something. Better for whom? For what?

I'd bet that you work on a traditional CRUD enterprise software, and that IO(the database) is the real bottleneck of your app. In that case, sure, the BEAM is a solid choice(so is Python, Ruby and PHP nowadays). But let's please not pretend that is all there is to software engineering.

I have used Clojure(JVM), Elixir(so Erlang) and a bit of Golang professionally too. So my opinion "is informed" too for that matter, but this kind of appeal to authority adds nothing to the discussion.

> I am not denying that the JVM might have almost caught up in the meantime. More than a decade ago it did not.

This presupposes that the JVM had something to catch up in the meantime. Again, this lacks nuance and brings nothing to the table. The JVM makes different trade-offs than the Erlang/Golang VM does, and has different strengths and weaknesses. Both of your comments completely ignores that.

> It's just that in my work I have found having to avoid them still worth it compared to the alternatives (global mutability and more primitive parallelism which was the case for the JVM for decades).

Clojure runs on the JVM and avoids mutability pretty well. It is amazing for writing concurrent software, and has been for many years(i.e more than a decade ago).

> Similar to the weird childish name-calling people do in Rust threads

I've seen people do similar things to the JVM.

The JVM is perfectly capable of Golang-style green threads now. As for Erlang, the creator of Clojure have commented in the past on why he dislikes the Actor model, and I think it is a fair criticism. Sometimes I see people praising Erlang VM as some panacea in which all the VMs should strive to be like. This is overly simplistic in my opinion, and ignores the huge trade-offs that the Erlang VM has.

And who will you hire if everyone decides to do that?

I believe it is more complicated than simply “throwing money at industries”. It seems to me that in China, the Government actually runs the country, while in the US, private capital does.

Who cares about Windows?

You are completely ignoring the impact that having billions of dollars at your disposal to spend on keeping users addicted to your platform can have. There is no way a free platform can compete with X/Instagram/TikTok, even if such platform had a better product(which they do btw). Just look at Whatsapp/iMessage, both are terrible apps, there are MANY better options, with way more features, and somehow they are still the most used messaging apps in the Western.

You know IRC isn't just one giant server serving every single user, right? Same for Mastodon. There were/are many different servers. Again, you are arguing against reality. IRCs/Forums have existed for decades, with hundreds of thousands of active users, with no problem whatsover. Scaling to billions is easy, since with more people using it, more people would be interested in hosting a server.

Moving the goalposts much? Of course there aren't any free services serving millions currently, how could they, when Facebook/X spends millions to make sure everyone stays on their platform? Which non tech savvy would want to move to a platform without all their friends? That's the gotcha with social networks, once you grow big enough, it is really hard for people to move off of it.

Still, funny how you ignored IRCs/forums that I mentioned. Those were used by MANY people, and could scale infinitely. You are literally arguing against something that has already happened.

Don't you realize that those with money are the ones who have the means to build a culture? How do you propose we compete with Jeffrey Epsteins who have a shit-ton of money to spend on pushing whatever narrative they want to? Just look around and see the "culture" we're in.

There are many Mastodon servers run by ordinary people simply because they want to. And before the shit-show the internet has become, there were many forums and IRC channels, absolutely free, and with 0 ads.

You can still have schema validation at the borders of the application(data in/out) without static typing.

I think there are many other factors that come into play when it comes to maintaniblity of large projects. I'd easily choose to maintain a large Elixir or Common Lisp codebase over a Java one, assuming they were all using the Best Practices™ of their respective languages.

There is research out there, and there is absolutely zero evidence that static typing catches more bugs than dynamic types. My experience is that immutability, functional programming, simplicity and testing pays a MUCH bigger role in maintainability than static typing.

Dynamic typing has trade-offs, and so does static typing, HUGE trade-offs by the way. But for some reason, no one seems to mention them... ever.

It has no Pro version, and I believe their plan is to monetize it through an optional Sync service, which is fair, since it actually costs money to keep it running.

> dynamic types become more of liability as a project gets larger

Why?

Why?

Add the East India Company's rule in India to the list, 40 million deaths on a conservative estimation.

Check Logseq for an open source alternative to Obsidian: https://github.com/logseq/logseq

> 1 Samuel said to Saul, “I am the one the Lord sent to anoint you king over his people Israel; so listen now to the message from the Lord. 2 This is what the Lord Almighty says: ‘I will punish the Amalekites for what they did to Israel when they waylaid them as they came up from Egypt. 3 Now go, attack the Amalekites and totally destroy all that belongs to them. Do not spare them; put to death men and women, children and infants, cattle and sheep, camels and donkeys.’”

What I agree or disagree with the bible is irrelevant. He is claiming moral is objective, unchanging and comes from God. God allowed slavery at some point, as that bible passage shows. So his options are to admit that either slavery is moral, or morality is not objective/unchanging. That's the point I was trying to make.