> Most of the time knives that are too sharp are much more dangerous than knives that are too blunt.
With a sharp knife, you cut through food very easily so you use very little force. You also use techniques that prevent you from getting hurt, such as the claw ( https://www.thekitchn.com/knife-skills-the-claw-75998 ).
But if someone has used a dull knife for most of their life, they may not have cultivated these skills and may hold their knife in an unsafe way and or use a lot of force when cutting.
For someone like that, a sharp knife could be a lot more dangerous, but if they're trained/using it properly, a sharp knife is a lot more safe as it reduces effort and chance of the knife slipping.
I'm a bit confused at the ways HTMX and Alpine AJAX differ and where they're the same. I know there are header difference, for example, and that HTMX may have some functionality Alpine is missing, etc.
For example, HTMX has websocket support, while it looks like Alpine doesn't. Alpine has Alpine AJAX, but also alpine-morph, etc.
I only saw one article specifically addressing combining the two, but also very little on server side transitioning from one to the other.
I wish there was an article on starting with HTMX and what Ajax looks like in p
> I don't think having the server render the table HTML and you injecting it is a good idea.
HTMX, Alpine AJAX and other similar progressive web frameworks work exactly this way, as do server side rendered React.js and friends.
> What if the server has downtime, and returns a 200 response but with a "maintenance mode" page
If the server is in maintence mode, it should not display the web application/web page, but instead show a "We're in maintenance mode" messages.
> Having it render only on a successful response and correct parsing of JSON data is more reliable.
You're comparing making a simple web page with either no secondary calls or a single secondary call using a few lines of code to writing a client side web application. It's a bit like comparing a car with a bicycle.
> You also start complicating things in terms of separation of concerns. You potentially have to adapt any styling considerations in your API, for instance if the table needs a class adding to it. Overall, not a good idea, imho.
This is certainly an opinion and that works for you, but HTMX and similar actually make much of my life easier, rather than harder since all that styling, etc. can live alongside my server logic, rather than being in an entirely separate second application.
The phone company would have been happy to sell you more phone lines. I knew people who had some.
But you're right that as dumb as it is, it's likely that ISPs would have charged per "device" (ie per IP address).
Before 1983 in the US, you could only rent a phone, not own one (at least not officially) and the phone company would charge a rental fee based on how many phones you had rented from them. Then, when people could buy their own phones, they still charged you per phone that you had connected! You could lie, but they charged you.
Like I said, I have mixed feelings about NATs, but you're right that the companies would have taken advantage of customers.
I'm not the OP or author, but the argument against private network addresses is that such addresses break the Internet in some fundamental ways. Before I elaborate on the argument, I want to say that I have mixed feelings on the topic myself.
Let's start with a simple assertion: Every computer on the Internet has an Internet address.
If it has an Internet Address, it should be able to send packets to any computer on the Internet, and any other computer on the Internet should be able to send packets to it.
Private networks break this assumption. Now we have machines which can send packets out, but can't receive packets, not without either making firewall rule exceptions or else doing other firewall tricks to try to make it work. Even then, about 10-25% of the time, it doesn't work.
But it goes beyond firewall rules... with IP addresses being tied to a device, every ISP would be giving every customer a block of addresses, both commercial and residential customers.
We'd also have seen fast adoption of IPv6 when IPv4 ran out. Instead we seem to be stuck in perpetual limbo.
On team anti-private networking addresses:
- Worse service from ISPs
- IPv4 still in use past when it should have been replaced
- Complex work around overcoming firewalls
I'm sure we all know the benefits of private networks, so I don't need to reiterate it.
If you look up Frank Karlitschek and "I forked my own project and my own company", he's given this talk many, many times.
As for it being the best of both worlds, it depends what best means.
A company that wants to make a lot of money won't do well with this model. It's a slow growth model requiring a lot of hands on work that requires customers who are paying for features and custom installations.
It's labor intensive work that's quite the opposite of the proprietary software model, which has traditionally had a lot in common with the publishing or entertainment industry. Write a book, get paid for it for years.
While it's absolutely true that businesses need to make money, the idea that this must therefore logically conclude with a FLOSS and non-FLOSS version is not correct.
If you look at companies like Red Hat, and Nextcloud, neither of these companies sold proprietary versions of their software. Red Hat sold licensed versions of their software, but they were always FLOSS.
Nextcloud's CEO talks about how selling a proprietary version of your code is bad for your customers and puts your company into a Catch 22 with itself. "Do we add this feature to the 'Community' or 'Enterprise' version?" or worse "What do we do when someone makes a FLOSS plugin that competes or is better than our internal version of the same functionality?"
There's a huge need for a good chat system to compete with the likes of Slack, but Matrix has bitten me several times and I don't trust it. In an alternate universe, they could have made Matrix work well for all levels of users and then sold customization and B2B deals with their customers leveraging the community, which has always wanted Matrix to succeed.
With a sharp knife, you cut through food very easily so you use very little force. You also use techniques that prevent you from getting hurt, such as the claw ( https://www.thekitchn.com/knife-skills-the-claw-75998 ).
But if someone has used a dull knife for most of their life, they may not have cultivated these skills and may hold their knife in an unsafe way and or use a lot of force when cutting.
For someone like that, a sharp knife could be a lot more dangerous, but if they're trained/using it properly, a sharp knife is a lot more safe as it reduces effort and chance of the knife slipping.