emacsen

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'm in a similar boat of using HTMX and finding it's 85% there, but then being stuck with another 15% that's not fulfilled.

I'm looking at Alpine.js for that last 15%.

Let's break this down a bit.

> 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.

That's a good idea and actionable about the grid- I was going for "lowest effort, highest impact"

Can you say more about "info on how one can contribute"?

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.

I don't think it's the same error, but without a good error message I don't know.

I did manually download the models and associated them, which are great but then the audio didn't work. On the browser version, it never asks me for permission for an audio device, and on the native version, it makes a file of 0 length and then complains it can't read the contents.

My read is that the project looks very interesting, and I'd love a FLOSS replacement for Aqua Voice, but this software isn't ready for everyday use yet, at least not on Linux.

I'd love to help somehow, whether that's a donation or experimenting if you point me to somewhere.

Same with the deb. :(

Tried it with AppImage on Linux, attempted to download a model and "Failed to download model. An error occurred." but nothing that helps me track down the error :(

As a new boss who has recently started using Story Points and requiring the devs stick to tickets, I think this article points to problems that are valid, but unrelated to the issue of tickets.

> a factory that forgot what it’s building. Features ship, bugs creep back in, and the codebase becomes an archaeological dig of short-term fixes and forgotten context.

That's tangential to tickets.

We always had tickets to some extent, but our current process involves organized feature planning, design tickets, implementation tickets, and review.

That has imposed a lot more structure, but it's also resulted in a lot less work. Developers know what the priorities are, know what the scope of work is, they know they'll get reviewed.

Issues the article talks about such as short term technical debt being accepted are tangential. If a problem comes up, it's documented and then a decision is made on when to address it. If it's serious, that could be immediately, and if not, it may be put aside until it's encapsulated in other work, such as a refactor or redesign.

Tickets drastically improve context by telling the story of what they're about, connecting to commits, and connecting to merge requests. The code becomes a series of narratives.

> “Yeah, good thought, but just stick to the ticket for now.”

That's bad management. Good management will say "Good thought, make a new ticket for it so we can hear what's on your mind and evaluate it."

> Ask why the feature matters? You’re overstepping.

Ask why the feature matters and you're a good dev!

But before we had this level of structure at my organization, sometimes the devs would override the stakeholder's explicit wishes without informing them!

Now with tickets there's an opportunity for dialog and a paper trail on decisions.

> Suggest a refactor while in the code? Not in scope.

This one is tricky as I just told a dev not to do a refactor this week. The reason was the refactor was tangential to the feature, which was already late to deliver. Instead, a ticket was made and we'll evaluate the decision to refactor next week.

> Improve naming, extract duplication, or add a helpful comment? That’s gold plating now.

Those aren't gold plating, they're part of code quality checks that go into reviews.

The tickets aren't the issue here any more than one might complain about a specific programming language being the problem. The core issue is the environment, and specifically of management. Before I had tickets, developers worked on what they wanted to work on

I'm interested but I have more questions than answers.

It might make sense to provide some system for figuring out how to create the budget, and then how to track your expenses against it.

In my mind the simplest form of budgeting is so-called "Envelope Accounting", where you have physical envelopes full of money where you pull money out when you spend it.

There are electronic envelope accounting systems which retain the simplicity.

I'm a bit unsure of how this system works, where it differs, etc.

In summary, I'd love to see:

1. An explanation of how to construct a budget using your system.

2. An explanation of how to compare your spending to your budget? (bonus points if I can use my existing plain text accounting system, or at least a csv file)

3. An explanation of how to track my budget over time.

Did you read the statement they put out later that day about Musk, or the day after?

I agree this was a terrible move on the ADL's part, and there have been others, but you're essentially labeling the oldest anti-hate group "fascist" because you disagree with one statement they made.

This dismisses any concerns they raise, or if someone else says the same as them, then they too must be pro-facist.