I think that is a very valid criticism. I wanted to keep the article concise, but I should have elaborated more on why Go+HTMX+Templ solves the dependency management fatigue.
As I said in the article, it is mainly anecdotal evidence, i.e. the experience from having to maintain projects with either React or Go+HTMX.
For example, in the Go+HTMX project I handle state management and routing solely with the Go stdlib (which is very very stable IMHO), I don't have to ever worry that a dependency update will force me to perform painful refactoring work.
Maybe in a future article I can expand on these points, thank you for the feedback :)
Hi, author here.
At least from my personal experience, there are still many jobs in which the main focus isn't frontend development, and per se React.
I do have to work with React from time to time. But it isn't my main focus. I usually work implementing backend systems (with Go, SQL [Postgres], Redis, etc.) and infrastructure as code with Terraform.
It is nonetheless extremely cheap (in comparison to rents in Augsburg and near-by Munich) and has life-changing consequences for the people living there, since they do not have to allocate a big amount of their income into housing.
Hi Fatih,
I just wanted to let you know that I am a very avid reader of your email newsletter. I really get happy every time an email with one of your new articles arrives at my inbox. Thanks to your reviews of keyboards I will hopefully soon be able to get one of them myself.
In summary, I just wanted to thank you for taking the time to write the articles. It's definitely more time consuming than tweeting (I don't have a twitter account at all, I dislike the atmosphere there and I also prefer to consume longer texts with more content), so I just wanted to let you know that there's a bunch of people out here reading your texts and enjoying them!
I am currently almost entirely developing in Go. And for that I have a highly customized Vim environment, which really took me a while to get to where it is right now (it works very well, thanks to the great 'vim-go' plugin). Nonetheless, I am starting to have to develop more stuff in other languages like js and Elixir, and I definitely do not want to invest all that time tweaking my vimrc to have all the IDE bare functionality that works so well in Go. I was starting to consider making the transition into neovim, but Helix sounds almost like a plug-and-play solution with sane defaults (which is exactly what I would like to have). Is it better that I go for Helix, or is LunarVim or AstroVim actually what I am looking for?
Do you work with Svelte and SvelteKit professionally or primarily on side project? How do you deal with the breaking changes that have taking place within SvelteKit, i. e. SvelteKit still not being on a major stable version yet?
Thanks a lot for the feedback. I am starting to get serious about learning the frontend side of things (coming from a backend/DevOps professional background). Especially the part of "React is a hot mess with so many ways to do all the things..." has made me prefer Svelte over React, and I really enjoy Svelte's idiomatic way of handling reactivity, I find it super intuitive. I guess I was just feeling insecure about putting so much time into Svelte, because I mostly only hear about people working with React.
I am trying to get a more than superficial level of knowledge on deploying services on relational databases with a lot of traffic. I don't know if it makes sense to grab any manual of a relational database, like PostgreSQL or MySQL, or if that is too specific and it makes more sense to start with a more general book.
[Please do not suggest Designing Data Intensive Applications, I am already reading it :) ]
Moreover, what are the best resources you know of that you used to learn SQL queries and their syntax properly? Thank you very much!
What's your opinion about Svelte? Has it made any big contributions to the ecosystem? Isn't the syntax and in general the way of creating components more intuitive with Svelte in comparison to for example React?
I think Vincent van Gogh, started seriously painting in his late 20s. Needless to say in his brief overall career as a painter he made some works which had a great impact in the art scene after his own death.
I am also a big Elm fan, especially due to the maintainability as you mentioned. But I have never worked with it in a production environment. Just in case you were working with a team on this project, how easy was it to convince the rest of the team to hop on the Elm train? Have you encountered any shortcomings while using Elm in production?
I also thought WhatsApp is a bad example. They not only hosted themselves, but they used solely FreeBSD (as far as I know) in their servers. (which don't get me wrong, I find great as a FreeBSD sysadmin myself).
I recently developed a command line chat app that I can self-host, to chat with my friends from the terminal and regain control over my chat data and metadata. I self host the back end in Linode and just for the lolz and "Unix portability" I wrote it entirely in C. I don't really expect this to be useful to anybody else than me and the couple of friends that also use it. I can now chat from the terminal during my working hours and my colleagues think that I am doing something mystical in the terminal or developing in Vim.
I would maybe start migrating repos away from GitHub, since they have proven to be quite unreliable. Nonetheless, I must say I do appreciate GitHub's UI and even their CLI is quite nice. Is there a service out there that basically provides the same good user experience, CI/CD and has no costs for public repos?
Apart from the unreliability I can't complain about GitHub.
The article might be quite old (I myself barely identify the microsoft tech stack he is referring to), but his description of the struggle with productivity is still spot on. I read this from time to time to not feel bad about myself for struggling with not being productive.
I think that is a very valid criticism. I wanted to keep the article concise, but I should have elaborated more on why Go+HTMX+Templ solves the dependency management fatigue.
As I said in the article, it is mainly anecdotal evidence, i.e. the experience from having to maintain projects with either React or Go+HTMX. For example, in the Go+HTMX project I handle state management and routing solely with the Go stdlib (which is very very stable IMHO), I don't have to ever worry that a dependency update will force me to perform painful refactoring work.
Maybe in a future article I can expand on these points, thank you for the feedback :)