I honestly cannot comment on RabbitMQ or Kafka. I have not used them. I have also not used Redis other than learning.
However, a few years ago, I did use MSMQ (Microsoft Message Queue) and worked very well. However, at the time, I wanted something that didn't limit me to Windows.
In the end, I ended up learning ZeroMQ. Once I understood their "patterns" I created my own Broker software.
Originally, all requests (messages) sent to the Broker were being stored in files. Eventually, I moved over to Sqlite. As the broker is designed to process one thing at a time, was not worried multiple requests were going to sqlite. So now my Broker requires little dependencies.. except ZeroMQ and Sqlite.
(I did not need to worry about async processing as they get passed to the workers)
So, a broker is communicated with a client and a worker/consumer.
- client can ask for state (health of a queue, etc)
- client can send a message (to a queue, etc)
The worker communicates with the broker
- please connect me to this queue
- is there anything in this queue for me?
- here is the result of this message (success or failure)
etc.
I also made use of the pub-sub pattern. I made a GUI app that subscribes to these queues and feeds updates. If there are problems (failures) you can see them, here. I leave it to staff to re-send the message. If its already sent, maybe the subscriber missed that packet. pub-sub is not reliable, afterall.. but works 99% of time.
Overall it has been a great system for my needs -- again, it is lightweight, fast, and hardly costs anything. I do not need a beefy machine, either.
Honestly, I swear by this application (broker) i made. Now, am I comparing it to RabbitMQ or Kafka? No! I am sure these products are very good at what they do. However, especially for smaller companies I work for, this software has saved them a few pennies.
In all I found "Distributed computing" to be rewarding, and ZeroMQ+Sqlite have been a nice combination for my broker.
I have been experimenting with nanomsg-NG as a replacement for ZeroMQ but I just haven't spent proper time of it due to other commitments.
While it has been a number of years since I last used Pascal (Delphi 5 or Turbo Pascal before that) -- I do like the language but I find the code syntax to be bloated at times. Maybe better to say harder on the eye when looking at large source code compared to C.
Of course - modern Pascal (Free Pascal, Delphi, etc) might have evolved a lot since.
// C
void some_func(int a) {
int b = a + 10;
printf("hello %d\n", b);
}
{ Pascal - Going by memory, so might be a tad wrong }
procedure SomeFunc(a : Integer)
var
b : Integer;
begin
b := a + 10;
WriteLn('hello ', b);
end;
I have been playing around with Odin for a little while, now. It may have been inspired by Pascal in a number of ways but it certainly isn't as cumbersome to write. I am liking the syntax much more.
// Odin
some_func :: proc(a : i32) {
b := a + 10
fmt.println("hello ", b)
}
In this, they make a good point about refactoring more with Rust than other languages. In some cases, "fighting the compiler" is not always want you want to do, especially when mocking some code/game state.
In a nutshell, if you have a database that will have multiple instances talking to it - you are better off with a client-server database, like Postgres, MariaDB, SQL Server, Oracle, etc.
SQlite, generally speaking, is a FANTASTIC local database solution, like for use in an application.
I have become fond of Sqlite in the last few years.
I use it for client applications that need to store local data -- normally temporary data to send to the server, etc.
I am now using it for a Message Queue middle-man (broker) program I wrote, which uses sqlite to store the messages. They tell us the queue they belong to, if there is a delay before handing out to a Worker, the current status, etc. It has worked very well. The other reason why I was not concerned using sqlite was because the program would do one thing at a time.. so there would not be multiple requests trying to insert/update data at the same time. To me it was a win-win.
lol. Carson is obviously aware of the criticisms he faces.
The best one is the "Duplicating (Or More!) Your APIs"
How is this a problem?
The backend would be broken down into layers. Data layer, business layer, etc.
For the website, you have a layer to fetch the data to return html.
For another thing (ie rest api) - you fetch the SAME data, return in json.
How is this more work, again?
NOTE - Yes, my comment is not aimed at Carson, but those that genuinely use it as an excuse to attack htmx.
I am (mostly) a backend developer - so I deal with languages like C#, communicating with databases like MySQL, SQL Server, etc.. and sending data back (to things like) the frontend, such as HTML/Javascript.
Despite this - I can do frontend development as well - but I have reached a point where I cannot be asked to learn new Javascript framework or libraries. Personally I just think it has become bloated, so I leave that for those that do know/understand.. like full-time React developers. I cannot be bothered as I am sure some new toy will come out in the next few years and replaces it.
My opinion... and I understand it is apples and oranges... is web development could be much easier than it is today. Back in '00s we were using old school PHP or Classic ASP to return compiled HTML content and, mostly, full screen refreshes. Eventually, Javascript gained more responsibilities giving us JQuery. We had simple GET and POST functionalities, allowing us to refresh part of the page, etc.
By around the 2010's I remember KnockoutJS and, eventually, AngularJS. Web development was changing and I accepted this. While I saw some benefits with auto refreshing hooks or the like.. the end was a lot of bloat... more lines of code. Some of which is duplicated in the frontend as well as the backend.
Between 2016 to 2021 I stopped web development. I started a job as a GUI application developer. When I returned to web development I am now seeing Node being used... Grunt being used... with some websites sticking to JQuery while another is using React. I am in shock at how complicated things has gotten!
To me, with my years of experience, feel like I am going full circle back to the old methods of web development... just with modern tools! I leaned back to jQuery for personal projects. It is easy to follow (in my opinion) -- but I came across HTMX in 2023 and really enjoying it!
Using HTMX, With odd exceptions, my javascript code is mostly a compliment to my CSS. The amount of code is reduced by 60-80%!
Since then I have started using HTMX for web projects at work -- with positive feedback from the team. We are, one by one, moving our projects over to HTMX. It is just easier to deal with.
Our team only has half a dozen developers. We are mostly backend devs but OK with react. Some are better than others. We have agreed that with HTMX we are getting things done a lot easier. We no longer have to bother with the additional layer that is React. We also stopped using jQuery.
Now I am not suggesting HTMX replaces React for all cases. Its just, for our use cases, it has done the job remarkably well.. and we are doing complicated web sites.
Having a team of React devs may be needed in a number of scenarios - I, thinking of all websites I have built over the last 20 years, struggle to find one.
There is a saying that is going to offend, but I think those that dislike or hating on HTMX are those that have invested their time on (things like) React. I also hear that HTMX guys are like a cult. That might be true to a degree. I am sure some will suggest I am one of them with this comment.
Most apps are almost useless without an internet connection as well. Maybe if youre a content heavy site, it would be useful offline too but in that case, using static HtML is enough
As I mentioned, websites back in 2007 were entirely server side and worked very well. Its 2024 and our internet connections are better.
However, a client that has a reliable connection has more options available to them compared to an unstable one.
If their internet connection is poor, then I would argue it is not just an htmx issue -- it is an overall website one! Does not matter whether fetching json or html. In this case we do not want all interactions to be server ones.
Now we are entering the territory of understanding what the client wants. In this case, it might be easier to build a GUI application or Android/IOS app, with a SQLite local database, queue requests, etc. So when they do have a connection, even momentarily, the queued data can get sent out.
> As I mentioned, websites back in 2007 were entirely server side and worked very well
That's a terrible premise to start with. No, websites back in 2007 didn't work well otherwise we wouldn't have changed so much since then.
> If their internet connection is poor, then I would argue it is not just an htmx issue -- it is an overall website one! Does not matter whether fetching json or html. In this case we do not want all interactions to be server ones.
In 2024 if your webapp can't open a settings page without internet connection it means your architecture is lame. There is no way requesting a server to open a modal is a smart strategy, period.
> In 2024 if your webapp can't open a settings page without internet connection it means your architecture is lame
Depends what you mean by a Settings page. Generally speaking, when it comes to web applications... any requests need to come from the server... or changes a user makes needs to go back to the server. Period. It if doesn't... it doesn't. Spit a user friendly message.
I have webapps that need to update user requests there and then, so their changes are exposed on other media/platforms. So, for me, a "settings page that can be used without internet connection" is pointless for my projects.
Again - what you want from a Settings page may have merit in your projects but they are a waste of energy for mine. Again, as I stated earlier, it is all about the problem you are trying to solve. What is lame architecture to you is additional bloat in mine.
In a number of scenarios, using htmx might not be the right approach. I could also say the same thing for React.
I have nothing further to add to this. As you mentioned, there could be more work for frontend devs. I doubt it is because of htmx fad being over... more likely it is some "cool toy" choo-choo train that replaces React.
However, a few years ago, I did use MSMQ (Microsoft Message Queue) and worked very well. However, at the time, I wanted something that didn't limit me to Windows.
In the end, I ended up learning ZeroMQ. Once I understood their "patterns" I created my own Broker software.
Originally, all requests (messages) sent to the Broker were being stored in files. Eventually, I moved over to Sqlite. As the broker is designed to process one thing at a time, was not worried multiple requests were going to sqlite. So now my Broker requires little dependencies.. except ZeroMQ and Sqlite.
(I did not need to worry about async processing as they get passed to the workers)
So, a broker is communicated with a client and a worker/consumer.
- client can ask for state (health of a queue, etc)
- client can send a message (to a queue, etc)
The worker communicates with the broker
- please connect me to this queue
- is there anything in this queue for me?
- here is the result of this message (success or failure)
etc.
I also made use of the pub-sub pattern. I made a GUI app that subscribes to these queues and feeds updates. If there are problems (failures) you can see them, here. I leave it to staff to re-send the message. If its already sent, maybe the subscriber missed that packet. pub-sub is not reliable, afterall.. but works 99% of time.
Overall it has been a great system for my needs -- again, it is lightweight, fast, and hardly costs anything. I do not need a beefy machine, either.
Honestly, I swear by this application (broker) i made. Now, am I comparing it to RabbitMQ or Kafka? No! I am sure these products are very good at what they do. However, especially for smaller companies I work for, this software has saved them a few pennies.
In all I found "Distributed computing" to be rewarding, and ZeroMQ+Sqlite have been a nice combination for my broker.
I have been experimenting with nanomsg-NG as a replacement for ZeroMQ but I just haven't spent proper time of it due to other commitments.
reply