6 ms·

I have very similar feelings to the author. I think it was back in 2019ish that I gave up on React & co for good. Since then I have built a number of web apps o

by bsnnkv 2y ago

I have very similar feelings to the author. I think it was back in 2019ish that I gave up on React & co for good. Since then I have built a number of web apps on a relatively spartan stack of Actix, Tera and HTMX, and they have all stood the test of maintainability over time and have a core group of diehard users. Last week I shipped another new web app[1] I got an idea for in <24h to closed alpha testers and in <7d to a public beta with no issues or fanfare. Perhaps part of the increased velocity is my having gone deep and learned the ins and outs of this stack over multiple years and projects, but it is important to note that I probably would never have gained this level of mastery over these tools if I were constantly being hit with what the author calls "dependency management fatigue". [1]: https://blucerne.app https://blucerne.app

pdimitar 2y ago
I'd love to read some blog posts on your process. Actix never struck me as super easy, at least when I checked it some 2-3 years ago.
- bsnnkv 2y ago
  I'd highly recommend reading some articles by Luca Palmieri[1], or even buying his book[2]. Although I didn't learn this stack by working through his book, whenever I had questions through the years, my searches usually led me to his articles which are often excerpts from the larger book. The high level of API stability and lack of churn in the Actix ecosystem makes the book a particularly good investment for someone looking to settle on this stack in my opinion. In keeping with the topic of this submission, I doubt I'd be comfortable spending money on a similar book about building web apps with React. [1]: https://www.lpalmieri.com/posts/2020-08-09-zero-to-production-3-how-to-bootstrap-a-new-rust-web-api-from-scratch https://www.lpalmieri.com/posts/2020-08-09-zero-to-productio... [2]: https://www.zero2prod.com https://www.zero2prod.com
  - pdimitar 2y ago
    Super helpful, thank you. My finger is hovering on the "Buy" button but I have to ask: how up to date is the book to the current Actix version / API? EDIT: Frak it, I just bought it. :D
    - bsnnkv 2y ago
      For others reading this in the future: > Roughly every three months, the book is updated to keep up with the latest developments in the Rust ecosystem. In particular, we make sure to update all the crates we use in the book to their latest released version. If you bought a copy of the ebook, you can get the latest book revision at any time by redownloading the content from here.
      - WD-42 2y ago
        I bought the printed version as I find it easier to work through. I was expecting it to be relatively out of date, but I was OK with that since the libraries in this ecosystem are relatively stable. To my surprise and delight, in the first few pages I came across the sentence "As of October 2024" So I think the printed version is either print to order or printed in very small batches, considering the book itself is several years old at this point. I'm half way through it now, I can highly recommend it. And if you are like me and prefer a printed version, don't be afraid to spring for it.
      - pdimitar 2y ago
        And again for the future readers: do we the buyers get a notification that there's an update and we should re-download?
mock-possum 2y ago
How have you managed to find work consistently? It seems like everyone is looking for 3-5 years of react specifically as a minimum on most job postings near me. I would love to get away from React, it is really not my favorite to worn with.
- RapperWhoMadeIt 2y ago
  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.
- bsnnkv 2y ago
  I was laid off just before Thanksgiving 2023[1] from a Principal Engineer role on a Platform Engineering team. I was employed there since 2018. I was very lucky to get referrals from a few folks that I social dance with in Seattle after that layoff, and I ended up with a job offer in a product area I knew very little about (networking, routing, programmable packet processing middleware with eBPF etc.) Despite my lack of domain knowledge, I was told I received the offer largely because of my demonstrated proficiency in Rust (I did all the interview whiteboarding sessions in Rust), and although this isn't something that is measured "officially" in the interview process, because there are many hours of me live programming online[2] for people to feel confident that they're not hiring a dud who has hyper-specialized in passing interviews which are not representative of real-world workloads. I general advise people in your situation to start looking further down the world's dependency tree, where things churn less frequently, and where the skills you acquire will last longer. This can be easier said than done, but since my very first job was as a React developer, I can at least share my path down the dependency tree: Frontend (React etc.) -> Backend (web APIs) -> Infrastructure / Platform / DevOps (started with a cloud automation focus, moved gradually towards to bare metal) -> Networking (I'm in ur VPCs, directing ur packets) All of this being said, the job market right now is very tough. I doubt I could walk out of this job and into another within 3 months like I did this time last year. [1]: A lot of my technical blog posts on https://lgug2z.com/articles https://lgug2z.com/articles around that time refer to this layoff [2]: https://youtube.com/@LGUG2Z https://youtube.com/@LGUG2Z
mlsu 2y ago
I (a novice) have been toying with web apps for a little bit now with Axum, Tera/Askama, and HTMX. I'm doing something very similar. I find that it works well for my simple apps but then complexity gets tough when I start to have a lot of template logic. This is when I realize that frontend web dev is actually full of interesting complexity... Obviously managing complexity in templates is something I'm sure people solved years and years ago, but of course now with 99% of frontend resources (blog posting, video content, courses, etc) being SPA focused, resources on doing it "the old school way" are scant. Do you know of any resources for designing web-apps of intermediate complexity with SSR templates? Or even just good resources from the HTMX + SSR camp, aside from the HTMX fellas?
- bsnnkv 2y ago
  My longest running web app[1] is also my most complex. Although I do use HTMX, I use it very sparingly.[2] 90%+ of what you need for a web app that you're building as a one-person show can be handled by storing state in the URL - people these days can be quick to forget that this is how large and complex web apps like GitHub have run for many, many years. With regards to complexity in templates, I find that you can cut down on a lot of that complexity if you enforce type constraints in your templating engine's context object. Getting in a habit of doing this early gets you thinking about ways to shift things that require conditional logic to the pre-templating stage, and more often than not it leads you to breaking down bigger templates into smaller partials and using them to compose different template variations for different views. I like this and it makes a lot of sense to me, but I'm not sure how it would feel to people who have only ever written JS SPA web apps. [1]: https://notado.app https://notado.app [2]: Example of the only place I use HTMX in Notado (to show search results as you type): https://www.youtube.com/watch?v=KMxmf132-8k https://www.youtube.com/watch?v=KMxmf132-8k
  - em-bee 2y ago
    i think your approach is orthogonal to SPA. first of all, it is my understanding that react in particular favors small templates or partials. and second, with the traditional server side frameworks i have always used full page templates, and i tend to write SPA the same way. i would only break up a template if it contains selfcontained sections that could potentially be used in different places. my point is that this is not because all i ever did was SPA, but because i did things like that already for years before that.
mattrighetti 2y ago
I recently shipped a project [0] with a very similar tech stack: Axum + HTMX + Askama. It’s still in beta but it’s incredible how far you can get with just html, css and less than 20 lines of js. Also, can’t beat the beauty of putting a single binary in a systemd service and have your entire frontend + backend ready to go. The only downside that I see is that the binary gets big pretty fast, especially with Askama which basically is a templating engine like Tera but pulls templates at compile time in the binary so you don’t have to copy templates around on your server. I have not worked with SSR a lot before but it seems it’s harder to cache pages too. [0]: https://ulry.app https://ulry.app
- Cthulhu_ 2y ago
  I'd argue a fat binary isn't a major issue unless you're on a lambda or edge computing platform, especially if the application is fairly stable / does not get many re-releases. I'd say caching can go into a different layer entirely.
  - mattrighetti 2y ago
    Yeah for the moment I reached a 25MB binary and I see no issues in performance whatsoever. I'm curious about caching, do you have any tips or resources on that?

by bsnnkv 2y ago

pdimitar 2y ago

I'd love to read some blog posts on your process. Actix never struck me as super easy, at least when I checked it some 2-3 years ago.

bsnnkv 2y ago
I'd highly recommend reading some articles by Luca Palmieri[1], or even buying his book[2]. Although I didn't learn this stack by working through his book, whenever I had questions through the years, my searches usually led me to his articles which are often excerpts from the larger book. The high level of API stability and lack of churn in the Actix ecosystem makes the book a particularly good investment for someone looking to settle on this stack in my opinion. In keeping with the topic of this submission, I doubt I'd be comfortable spending money on a similar book about building web apps with React. [1]: https://www.lpalmieri.com/posts/2020-08-09-zero-to-production-3-how-to-bootstrap-a-new-rust-web-api-from-scratch https://www.lpalmieri.com/posts/2020-08-09-zero-to-productio... [2]: https://www.zero2prod.com https://www.zero2prod.com
- pdimitar 2y ago
  Super helpful, thank you. My finger is hovering on the "Buy" button but I have to ask: how up to date is the book to the current Actix version / API? EDIT: Frak it, I just bought it. :D
  - bsnnkv 2y ago
    For others reading this in the future: > Roughly every three months, the book is updated to keep up with the latest developments in the Rust ecosystem. In particular, we make sure to update all the crates we use in the book to their latest released version. If you bought a copy of the ebook, you can get the latest book revision at any time by redownloading the content from here.
    - WD-42 2y ago
      I bought the printed version as I find it easier to work through. I was expecting it to be relatively out of date, but I was OK with that since the libraries in this ecosystem are relatively stable. To my surprise and delight, in the first few pages I came across the sentence "As of October 2024" So I think the printed version is either print to order or printed in very small batches, considering the book itself is several years old at this point. I'm half way through it now, I can highly recommend it. And if you are like me and prefer a printed version, don't be afraid to spring for it.
    - pdimitar 2y ago
      And again for the future readers: do we the buyers get a notification that there's an update and we should re-download?

mock-possum 2y ago

How have you managed to find work consistently? It seems like everyone is looking for 3-5 years of react specifically as a minimum on most job postings near me. I would love to get away from React, it is really not my favorite to worn with.

RapperWhoMadeIt 2y ago
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.
bsnnkv 2y ago
I was laid off just before Thanksgiving 2023[1] from a Principal Engineer role on a Platform Engineering team. I was employed there since 2018. I was very lucky to get referrals from a few folks that I social dance with in Seattle after that layoff, and I ended up with a job offer in a product area I knew very little about (networking, routing, programmable packet processing middleware with eBPF etc.) Despite my lack of domain knowledge, I was told I received the offer largely because of my demonstrated proficiency in Rust (I did all the interview whiteboarding sessions in Rust), and although this isn't something that is measured "officially" in the interview process, because there are many hours of me live programming online[2] for people to feel confident that they're not hiring a dud who has hyper-specialized in passing interviews which are not representative of real-world workloads. I general advise people in your situation to start looking further down the world's dependency tree, where things churn less frequently, and where the skills you acquire will last longer. This can be easier said than done, but since my very first job was as a React developer, I can at least share my path down the dependency tree: Frontend (React etc.) -> Backend (web APIs) -> Infrastructure / Platform / DevOps (started with a cloud automation focus, moved gradually towards to bare metal) -> Networking (I'm in ur VPCs, directing ur packets) All of this being said, the job market right now is very tough. I doubt I could walk out of this job and into another within 3 months like I did this time last year. [1]: A lot of my technical blog posts on https://lgug2z.com/articles https://lgug2z.com/articles around that time refer to this layoff [2]: https://youtube.com/@LGUG2Z https://youtube.com/@LGUG2Z

mlsu 2y ago

I (a novice) have been toying with web apps for a little bit now with Axum, Tera/Askama, and HTMX. I'm doing something very similar. I find that it works well for my simple apps but then complexity gets tough when I start to have a lot of template logic. This is when I realize that frontend web dev is actually full of interesting complexity... Obviously managing complexity in templates is something I'm sure people solved years and years ago, but of course now with 99% of frontend resources (blog posting, video content, courses, etc) being SPA focused, resources on doing it "the old school way" are scant. Do you know of any resources for designing web-apps of intermediate complexity with SSR templates? Or even just good resources from the HTMX + SSR camp, aside from the HTMX fellas?

bsnnkv 2y ago
My longest running web app[1] is also my most complex. Although I do use HTMX, I use it very sparingly.[2] 90%+ of what you need for a web app that you're building as a one-person show can be handled by storing state in the URL - people these days can be quick to forget that this is how large and complex web apps like GitHub have run for many, many years. With regards to complexity in templates, I find that you can cut down on a lot of that complexity if you enforce type constraints in your templating engine's context object. Getting in a habit of doing this early gets you thinking about ways to shift things that require conditional logic to the pre-templating stage, and more often than not it leads you to breaking down bigger templates into smaller partials and using them to compose different template variations for different views. I like this and it makes a lot of sense to me, but I'm not sure how it would feel to people who have only ever written JS SPA web apps. [1]: https://notado.app https://notado.app [2]: Example of the only place I use HTMX in Notado (to show search results as you type): https://www.youtube.com/watch?v=KMxmf132-8k https://www.youtube.com/watch?v=KMxmf132-8k
- em-bee 2y ago
  i think your approach is orthogonal to SPA. first of all, it is my understanding that react in particular favors small templates or partials. and second, with the traditional server side frameworks i have always used full page templates, and i tend to write SPA the same way. i would only break up a template if it contains selfcontained sections that could potentially be used in different places. my point is that this is not because all i ever did was SPA, but because i did things like that already for years before that.

mattrighetti 2y ago

I recently shipped a project [0] with a very similar tech stack: Axum + HTMX + Askama. It’s still in beta but it’s incredible how far you can get with just html, css and less than 20 lines of js. Also, can’t beat the beauty of putting a single binary in a systemd service and have your entire frontend + backend ready to go. The only downside that I see is that the binary gets big pretty fast, especially with Askama which basically is a templating engine like Tera but pulls templates at compile time in the binary so you don’t have to copy templates around on your server. I have not worked with SSR a lot before but it seems it’s harder to cache pages too. [0]: https://ulry.app https://ulry.app

Cthulhu_ 2y ago
I'd argue a fat binary isn't a major issue unless you're on a lambda or edge computing platform, especially if the application is fairly stable / does not get many re-releases. I'd say caching can go into a different layer entirely.
- mattrighetti 2y ago
  Yeah for the moment I reached a 25MB binary and I see no issues in performance whatsoever. I'm curious about caching, do you have any tips or resources on that?