LIVE ON TWITCH: / theprimeagen Get in on Discord: / discord Get in on Twitter: / theprimeagen Got Something For Me to Read or Watch??: / theprimeagenreact
The discussion is genuinely confusing to me. If you've been doing web long enough, you know that the "SPA everything" movement threw a bunch of babies out with the bathwater, and that sending HTML over the wire and doing no logic on the client is a superior UX and more productive for the developer for a large class of applications. HTMX is just one way to enable this. LiveView and Hotwire are two others. *Of course* sometimes you need the fine-grained interactivity that a frontend-framework gives you, nobody is arguing this, just that using it *everywhere* is a mistake. *Why is HTML over the wire better?* 1. The client has to do less work. It just shows HTML, which it is already good at, so it uses less browser CPU (not more server resources though, that would be a false dichotomy). 2. Less code running on the client = less memory used, another win for UX, especially on mobile. 3. We don't necessarily have to replace the entire browser navigation, which is - again - a big win for UX, since it doesn't replace something the browser is already good at. 4. Write business rules ONCE and they only run on the server. 5. No need to create an API or protocol for client and server to communicate. *What is the downside?* 1. It's clumsy for extremely complex UI's. 2. High latencies if you are waiting on a slow server. (Very solvable.) Sometimes I feel like people have genuinely never used a web browser to just visit web pages, and noticed that this was *good*.
Yeah almost an entire generation has now grown up with websites or "apps" that load MB's of UI-chrome before ever loading the actual content they visited an url for. Super weird.
Well react started out as library that was meant to deal with only those complex logic in a ssr. I remember when the recommended way to use react was a cdn. It became this beast because people just ran with it and replaced the site completely
It took me all of 5 days to realize rust wasn’t worth my time 😂 It’s simply too steep of a learning curve just to still struggle through the code despite seeing yourself as adept at the language. I haven’t looked at Zig much yet but it and Go seem like better overall packages in terms of complexity vs performance
The language you choose really hinges on the nature of the work you're doing. For instance, Go might not be my first choice for complex system-level programming due to the difficulties encountered when using cgo and the interference of the garbage collector. In Rust, the biggest challenge tends to be the ownership model, but once you grasp that, it becomes fairly intuitive. Understanding ownership in Rust is all about focusing on the types in use and the scoping rules. If you neglect copy/cloning, implicit lifetimes adhere to the scope they're defined in. Once you understand this, it's just a matter of distinguishing whether the type you're handling resides on the stack or the heap. Stack variables, which possess the copy trait, can give an impression of sidestepping ownership. Heap types, conversely, don't implement copy and essentially act as smart pointers (think of a string as a vector equipped with encoding - a simple pointer with a size and capacity on the stack and the string data on the heap). As a novice Rust developer, you might find yourself frequently employing the clone trait. This is usually okay unless you're striving for maximum performance from your program. Even after six years of using Rust in a business setting, I still often use clone during the early stages of app prototyping. I'll then go back and replace clone with appropriate lifetimes and mechanisms such as arcs and boxes to enhance performance. Explicit lifetimes or smart pointers can prolong the lifespan of heap variables, but this is not an essential concept for beginners. As someone who has introduced many people to Rust (via a RU-vid channel and corporate training), I can assure you that Rust's reputation for difficulty can be exaggerated if you tackle the language appropriately. However, if you approach it incorrectly, it can indeed be a challenge - just like any other language that employs unfamiliar paradigms. Suppose you're only acquainted with object-oriented programming and attempt to navigate a fully functional language. In that case, you'll encounter as much difficulty as you would when learning certain aspects of Rust. Rust is primarily an imperative language with object-oriented and functional attributes incorporated into it. Misconstruing it as an object-oriented or functional language can unnecessarily complicate the learning process. Macros and async form the other major challenging aspects of the language after ownership, but these are not usually necessary in most use cases especially when you are first starting out. Libraries like Tokio Make working with async so much easier because they abstract away a lot of the difficulties. And with macros, the main difficulty comes from building your own procedural macros. Just FYI, I'm not a rust evangelist; I'm more of a polyglot. I do use go, dart, rust, elixir, clojure, clisp, c/c++, kotlin, scala, ocaml etc and each of the languages has their own merits for specific use cases. For example I wouldn't build a web server in common lisp or c when I can just use something like go, elixir or clojure. Just as I wouldn't use JavaScript to build desktop or mobile apps when I can use dart or rust instead. For me, all of these technologies are essentially just tools in my programmer tool belt. You wouldn't use a hammer to try and put a screw into a frame etc.
depends where you come from and where you go. if you do backend, want a quick language, that is clean and easy to learn, go is really good. if you come from C, zig might be really good. Personally, I find zig harder to read, and I love rusts typing system
@@RogerValor I messed around with zig a bit and I can't say I'm all that fond of it at the moment. There are some compelling ideas in the language but I just don't see a good reason to use it right now over existing languages. I'm sure there's some good use cases with it, especially with its pluggable alligators but I can't really think of any that don't bleed into the territory of rust or go.
I made an ecommerce website that took an approach similar to HTMX about 10 years ago. The performance was great, esp. compared to the industry standards at the time. There was no established framework (no HTMX to use) though, so mine wasn't streamlined, but I'd say that HTMX is the way to go based on that experience
If I didn't know any better, I would compare this stream to an acid trip. But since I do, I'll instead point out that tuning in for such a stream while coincidentally on acid would likely be a peak experience.
I couldn't find the answer anywhere.. but why use htmx with leptos? What does htmx bring to the table that leptos didn't have? I'm confused.. why do I need htmx in leptos? Can anyone explain please 🙏
I agree, tabnine is so much better than co-pilot in my opinion. Co-pilot is very intrusive because it creates entire blocks; it really can get in the way, whereas tabnine has settings that allow you to make it much less intrusive but still just as useful. The funny thing to me, is that the dart virtual machine has its own AI auto completion built into it, it's more similar to tabnine than it is to co-pilot, it's something I hope to see in a lot of languages going forward.
This conversation is surprising to me, as I just tried both and came to the opposite conclusion. They are both prone to generating garbage code that just will never compile, the main difference is Tabnine was much *more* prone to this insanity. I would say at least twice as often as Copilot the output was just unusable gobbledygook, at least for Java. Neither fully replaces an IDE or LSP that just generates correct code. If I turn Tabnine down, it isn't any better than Intellij because it still doesn't have a clue what will compile, so I may as well just uninstall it.
@@LoneIgadzra suppose it depends on the language but I will say that the reason I find tabnine to be better is mainly because it doesn't try to suggest entire blocks of code. Or at the very least you can limit the size of the code that it suggests and therefore limit the hallucinations. Also, unlike copilot, tabnine doesn't override the completions from the LSP. With rust, go, dart, clojure, elixir, etc the tabnine completions show up in a list along with the LSP completions. At least, this is how it works in emacs.
you can make offline version too.. but all apps suck offline? when was the last time you used an app that you expected to work offline? i don't have a single one other than google docs (of which isn't a good htmx use case)
@@TheVimeagen Dude, I'm just giving you engagement. BUT, I would want a TODO app to work even if I'm on the subway (or out on the range). I think you are right about clients becoming thinner for most use cases, but there are certain apps that HAVE to work despite your connectivity. (Even RU-vid works offline with manual and smart downloads).
@@AnthonyBullard Copy trello example. (I actually want to do this aswell...) Change it enough to use Local session storage where it changes the key-value elements in a list... Add CRUD updates, and upload + refresh button and manage changes for database on the server. Now... never close that tab, use refresh if you use multiple PCs on the page and load latest changes. Now you can open and close server each day or smt and worry when your laptop battery dies. And I think it's kinda like a git in browser now... Make it create git branches/submodules with the cards!
@@AnthonyBullardI don’t think this is a prime official RU-vid channel. I think this is a person who watches and records primes videos and uploads them. So take his responses with that lens.
I'm sometimes surprised how little routine ThePrimagen has when writing Rust. He definitely knows enough about it to be good at it, but since he's not using it at work (unlike me), it's the little things that trip him up all the time. You can see it in this video when he doesn't even know what the tracing crate does, or that actix uses Arc underneath web::Data.
this video contains me writing rust for the first time in 1 month yeah, being rusty will always be a state of those not immersed in a language multiplied by its difficulty
@@TheVimeagen Your position as an internal tools developer at Netflix would be perfect to introduce Rust to the company though! That would stop all the rustyness.
@@aasquared8191 It might be internal to the crate, but it's a very leaky wrapper. You are inevitably confronted with that fact pretty soon if you use actix-web, just like Prime was in this video.
@@anlumo1 "oh you don't know the internals of a crate or what actix (a crate) uses underneath `web::Data`? you're so bad at Rust, lmao" what are you talking about FTFY
dont like ssr. i think htmx is just a collections of older ideas. while i was building my first website, years and years ago, i would appropriate htmx its basically tailwind for js and i dont like tailwind
